a simulink toolbox for flight dynamics and control analysis

FDC 1.4 – A SIMULINK Toolbox forFlight Dynamics and Control Analysis

DRAFT VERSION 7

Marc Rauw

May 25, 2005

The Flight Dynamics and Control Toolbox for MATLAB and SIMULINK is distributed via the Internet, together withthis FDC report, which is available in PostScript and PDF format. If you wish to make a hard-copy of the report, itis advised to download the PostScript version and send it to a PostScript printer or a software PostScript interpretersuch as GHOSTSCRIPT (see http://www.ghostscript.com for more information).

This document was created with MIKTEX in LATEX 2ε format. The vector figures were drawn in TEXCAD (part ofthe EMTEX package for MS-DOS), MATLAB, SIMULINK, and MAYURA DRAW. The screenshots were created withIRFANVIEW and the wonderful JPEG2PS tool. The Postscript graphics were prepared with the DVI-driver DVIPS,GHOSTSCRIPT and GSVIEW; the PDF version was created with GHOSTSCRIPT and ADOBE ACROBAT.

Copyright © 2004, M.O. Rauw. All rights reserved.

The Flight Dynamics and Control Toolbox has been released under and is subject to the terms of the Open Soft-ware License, version 2.0, a copy of which has been included in appendix F.

This report has been released under and is subject to the terms of the Common Documentation License, ver-sion 1.0, the terms of which are incorporated in appendix G. Please read it before using this material - your useof this material signifies your agreement to the terms of the License.

Instead of a list: All trademarks mentioned in this document are registered to whoever it is that owns them.

To contact the author, please send an e-mail to: [email protected]. For the most actual information about theFDC toolbox, see the Dutchroll homepage: http://www.dutchroll.org or http://www.dutchroll.com.

Contents

Preface vii

1 Flight control system development 11.1 Automatic flight control systems . . . . . . . . . . . . . . . . . . . . . . 11.2 The FCS design cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Taking a closer look at the FCS design cycle . . . . . . . . . . . . . . . . 41.4 FCS design environments . . . . . . . . . . . . . . . . . . . . . . . . . . 71.5 FCS design and the FDC toolbox . . . . . . . . . . . . . . . . . . . . . . 8

2 Rigid body equations of motion 112.1 General rigid-body equations of motion . . . . . . . . . . . . . . . . . . 11

2.1.1 General force equation for a rigid body . . . . . . . . . . . . . . 112.1.2 General moment equation for a rigid body . . . . . . . . . . . . 122.1.3 Angular momentum around the center of gravity . . . . . . . . 122.1.4 Resulting general equations of motion for a rigid body . . . . . 14

2.2 Expressing translational motions in flight-path axes . . . . . . . . . . . 182.2.1 Advantages of relating translations to flight-path axes . . . . . 182.2.2 Expressing forces and velocities in terms of flight-path axes . . 192.2.3 Derivation of the V-equation . . . . . . . . . . . . . . . . . . . . 202.2.4 Derivation of the α-equation . . . . . . . . . . . . . . . . . . . . 202.2.5 Derivation of the β-equation . . . . . . . . . . . . . . . . . . . . 21

2.3 Equations of motion in nonsteady atmosphere . . . . . . . . . . . . . . 212.4 Kinematic relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.5 Assembling the state equations . . . . . . . . . . . . . . . . . . . . . . . 25

3 The aircraft model 273.1 General structure of the flight simulation model . . . . . . . . . . . . . 273.2 The nonlinear aircraft dynamics . . . . . . . . . . . . . . . . . . . . . . . 273.3 External forces and moments . . . . . . . . . . . . . . . . . . . . . . . . 28

3.3.1 Aerodynamic Forces & Moments . . . . . . . . . . . . . . . . . . 283.3.2 Engine Forces & Moments . . . . . . . . . . . . . . . . . . . . . . 313.3.3 Gravitational forces . . . . . . . . . . . . . . . . . . . . . . . . . . 323.3.4 Forces and moments due to nonsteady atmosphere . . . . . . . 32

3.4 Converting the implicit state equations to explicit equations . . . . . . 333.5 Atmosphere and airdata variables . . . . . . . . . . . . . . . . . . . . . 343.6 Additional observation variables . . . . . . . . . . . . . . . . . . . . . . 38

3.6.1 Body-axes velocity rates . . . . . . . . . . . . . . . . . . . . . . . 38

ii CONTENTS

3.6.2 Kinematic accelerations and specific forces . . . . . . . . . . . . 393.6.3 Flight-path related variables . . . . . . . . . . . . . . . . . . . . 40

3.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4 External atmospheric disturbances 434.1 Deterministic disturbances . . . . . . . . . . . . . . . . . . . . . . . . . . 434.2 Stochastic disturbances . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.2.1 Stochastic properties of atmospheric turbulence . . . . . . . . . 464.2.2 Power spectra of atmospheric turbulence . . . . . . . . . . . . . 484.2.3 Filter design for atmospheric turbulence . . . . . . . . . . . . . 494.2.4 Turbulence intensity and scale . . . . . . . . . . . . . . . . . . . 51

5 Radio-navigation, sensors, actuators 555.1 The Instrument Landing System . . . . . . . . . . . . . . . . . . . . . . 55

5.1.1 Nominal ILS signals . . . . . . . . . . . . . . . . . . . . . . . . . 565.1.2 Steady-state ILS offset errors and ILS noise . . . . . . . . . . . . 63

5.2 The VOR navigation system . . . . . . . . . . . . . . . . . . . . . . . . . 665.2.1 Nominal VOR signals . . . . . . . . . . . . . . . . . . . . . . . . 665.2.2 VOR coverage and the Cone of Silence . . . . . . . . . . . . . . 685.2.3 VOR accuracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.3 Other flight navigation systems . . . . . . . . . . . . . . . . . . . . . . . 705.4 Sensors, Actuators, Flight Control Computer . . . . . . . . . . . . . . . 71

6 Analytical tools 736.1 Numerical integration methods . . . . . . . . . . . . . . . . . . . . . . . 73

6.1.1 The type of problems considered . . . . . . . . . . . . . . . . . . 746.1.2 Stability, errors, and order of a numerical integration method . 756.1.3 Main categories of numerical integration methods . . . . . . . . 776.1.4 Stiff differential equations . . . . . . . . . . . . . . . . . . . . . . 83

6.2 System linearisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 846.3 Steady-state trimmed flight . . . . . . . . . . . . . . . . . . . . . . . . . 87

6.3.1 Definition of steady-state flight . . . . . . . . . . . . . . . . . . . 876.3.2 Specification of the flight condition . . . . . . . . . . . . . . . . . 886.3.3 Remaining control and state variables . . . . . . . . . . . . . . . 896.3.4 The rate-of-climb constraint . . . . . . . . . . . . . . . . . . . . . 906.3.5 The coordinated turn constraint . . . . . . . . . . . . . . . . . . 916.3.6 Combined constraints . . . . . . . . . . . . . . . . . . . . . . . . 916.3.7 The resulting steady-state trimmed-flight algorithm . . . . . . . 92

6.4 Miscellaneous simulation issues . . . . . . . . . . . . . . . . . . . . . . . 936.4.1 Algebraic loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . 936.4.2 Obtaining state-models from transfer functions . . . . . . . . . 96

7 Getting started with the FDC toolbox 997.1 Objectives of the FDC toolbox . . . . . . . . . . . . . . . . . . . . . . . . 997.2 System requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1007.3 License Agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1007.4 Installation and initialisation of FDC 1.4 . . . . . . . . . . . . . . . . . . 101

CONTENTS iii

7.5 Uninstalling FDC 1.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1057.6 The FDC directory structure . . . . . . . . . . . . . . . . . . . . . . . . . 1067.7 The FDC model libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . 1067.8 Taking a closer look at the aircraft model . . . . . . . . . . . . . . . . . 1087.9 Linking to SIMULINK libraries . . . . . . . . . . . . . . . . . . . . . . . . 1097.10 Summary of the model and library structure . . . . . . . . . . . . . . . 1137.11 Colour conventions for the FDC models . . . . . . . . . . . . . . . . . . 1137.12 Some cautions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1147.13 About the block and function reference chapters . . . . . . . . . . . . . 115

8 Aircraft model block reference 1178.1 The aircraft model and its subsystem equivalents . . . . . . . . . . . . . 1178.2 The aircraft model block libraries . . . . . . . . . . . . . . . . . . . . . . 120

9 Wind and turbulence block reference 1659.1 The wind and turbulence blocklibrary . . . . . . . . . . . . . . . . . . . 165

10 Radio-navigation block reference 17910.1 The radio-navigation blocklibrary . . . . . . . . . . . . . . . . . . . . . 179

11 FDC implementation of the analytical tools 19511.1 The trimming facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

11.1.1 Program structure of ACTRIM . . . . . . . . . . . . . . . . . . . . 19611.1.2 Using ACTRIM in practice . . . . . . . . . . . . . . . . . . . . . . 198

11.2 The linearization facility . . . . . . . . . . . . . . . . . . . . . . . . . . . 20111.2.1 Program structure of ACLIN . . . . . . . . . . . . . . . . . . . . . 20111.2.2 Using ACLIN in practice . . . . . . . . . . . . . . . . . . . . . . . 202

11.3 The routine SYSTPROP to compute linear system-properties . . . . . . 20311.4 Programs for post-processing simulation results . . . . . . . . . . . . . 204

11.4.1 The routine RESULTS . . . . . . . . . . . . . . . . . . . . . . . . 20411.4.2 The routine RESPLOT . . . . . . . . . . . . . . . . . . . . . . . . 205

12 Support functions reference 20712.1 A brief overview of the support utilities . . . . . . . . . . . . . . . . . . 20712.2 Toolbox initialisation functions . . . . . . . . . . . . . . . . . . . . . . . 208

12.2.1 FDC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20812.2.2 FDCINIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20912.2.3 FDC_SPLASH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

12.3 Directory functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21012.3.1 FDCDIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21012.3.2 DATADIR, HELPDIR . . . . . . . . . . . . . . . . . . . . . . . . . . 211

12.4 Data load functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21112.4.1 FDCLOAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21212.4.2 DATLOAD, LINLOAD, MATLOAD, and TRILOAD . . . . . . . . . . 212

12.5 Generic helper functions . . . . . . . . . . . . . . . . . . . . . . . . . . . 21412.5.1 BROWSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21412.5.2 NEWMSGBOX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21512.5.3 NUM2STR2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

iv CONTENTS

12.5.4 SCREENSIZE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21612.5.5 TXTMENU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216

12.6 Model-specific helper functions . . . . . . . . . . . . . . . . . . . . . . . 21712.6.1 MODBUILD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21712.6.2 FIXSTATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21912.6.3 RESULTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22112.6.4 RESPLOT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

13 Using the FDC toolbox for open-loop analysis 22113.1 Non-linear responses to deterministic inputs – OLOOP1 . . . . . . . . . 221

13.1.1 Structure of the system OLOOP1 . . . . . . . . . . . . . . . . . . 22113.1.2 Performing simulations with OLOOP1 . . . . . . . . . . . . . . . 22413.1.3 Analyzing simulation results . . . . . . . . . . . . . . . . . . . . 225

13.2 Non-linear responses to stochastic inputs – OLOOP2 . . . . . . . . . . . 22513.2.1 Structure of the system OLOOP2 . . . . . . . . . . . . . . . . . . 22513.2.2 Performing simulations with OLOOP2 and analyzing the results 226

13.3 Linear responses to deterministic inputs – OLOOP3 . . . . . . . . . . . 22713.3.1 Structure of the system OLOOP3 . . . . . . . . . . . . . . . . . . 22713.3.2 Performing simulations with OLOOP3 and analyzing the results 228

13.4 Trim-demo: trimmed-flight elevator deflection curve . . . . . . . . . . 231

14 Beaver autopilot – Theory 23914.1 Basic autopilot functions . . . . . . . . . . . . . . . . . . . . . . . . . . . 23914.2 The longitudinal autopilot modes . . . . . . . . . . . . . . . . . . . . . . 241

14.2.1 Pitch Attitude Hold mode . . . . . . . . . . . . . . . . . . . . . . 24114.2.2 Altitude Hold mode . . . . . . . . . . . . . . . . . . . . . . . . . 24214.2.3 Altitude Select mode . . . . . . . . . . . . . . . . . . . . . . . . . 24314.2.4 Longitudinal part of the Approach mode: Glideslope . . . . . . 24314.2.5 Longitudinal part of the Go Around mode . . . . . . . . . . . . 245

14.3 The lateral autopilot modes . . . . . . . . . . . . . . . . . . . . . . . . . 24614.3.1 Roll Attitude Hold mode with turn-coordinator . . . . . . . . . 24614.3.2 Heading Hold/Heading Select mode . . . . . . . . . . . . . . . 24714.3.3 Lateral part of the Approach mode: Localizer . . . . . . . . . . 24914.3.4 VOR navigation mode . . . . . . . . . . . . . . . . . . . . . . . . 25014.3.5 Lateral part of the Go Around mode . . . . . . . . . . . . . . . . 251

14.4 Turn-compensation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25314.4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25314.4.2 Correction of the pitch rate in turns . . . . . . . . . . . . . . . . 25314.4.3 Correction for the loss of lift in turns . . . . . . . . . . . . . . . . 25314.4.4 Total turn-compensation . . . . . . . . . . . . . . . . . . . . . . . 254

14.5 The signal limiters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

15 Beaver autopilot – Simulation models 26115.1 Implementing separate control laws in SIMULINK . . . . . . . . . . . . 261

15.1.1 Structure of the control-law simulation models . . . . . . . . . . 26115.1.2 SIMULINK implementation of the Pitch Attitude Hold mode . . 26215.1.3 SIMULINK implementation of the Roll Attitude Hold mode . . . 263

CONTENTS v

15.1.4 Using the PAH and RAH simulation models in practice . . . . . 26615.2 Integral autopilot simulation model . . . . . . . . . . . . . . . . . . . . 268

15.2.1 General structure of the autopilot simulation model . . . . . . . 26815.2.2 Implementation of the symmetrical autopilot modes . . . . . . 27115.2.3 Implementation of the asymmetrical autopilot modes . . . . . . 27215.2.4 Implementation of the Mode Controller . . . . . . . . . . . . . . 27315.2.5 Implementation of atmospheric disturbances . . . . . . . . . . . 27515.2.6 Blocks to obtain small-deviation signals from the aircraft model 27515.2.7 Additional blocks on the input side of the aircraft model . . . . 27615.2.8 Additional blocks on the output side of the aircraft model . . . 278

15.3 Performing simulations with the autopilot models . . . . . . . . . . . . 27915.3.1 Autopilot model initialization . . . . . . . . . . . . . . . . . . . . 27915.3.2 Examples of non-linear autopilot simulations . . . . . . . . . . . 281

A Symbols and definitions 285A.1 List of symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285A.2 Vectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289A.3 Matrices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289A.4 Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289A.5 Indices and subscripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289A.6 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290A.7 Reference frames and sign conventions . . . . . . . . . . . . . . . . . . 291

A.7.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291A.7.2 Summary of the application of the reference systems . . . . . . 292A.7.3 Relationships between the reference frames . . . . . . . . . . . . 293A.7.4 Sign conventions for deflections of control surfaces . . . . . . . 297

B Beaver model parameters 299B.1 General aircraft data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299B.2 Flight envelope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299B.3 Aerodynamic and engine model parameters . . . . . . . . . . . . . . . 300

C Data structure of the FDC model parameters 305C.1 Defining the model parameters in the MATLAB workspace . . . . . . . 305C.2 Definition of the parameter matrices for the Beaver model . . . . . . . 306

D Data structure of the FDC model output signals 309D.1 Aircraft model signal logging . . . . . . . . . . . . . . . . . . . . . . . . 309D.2 Radio navigation signal logging . . . . . . . . . . . . . . . . . . . . . . . 310

E Definitions of variables and acronyms from FDC 1.4 313E.1 Variables and acronyms from the graphical models . . . . . . . . . . . 313

E.1.1 Aircraft model (system Beaver) . . . . . . . . . . . . . . . . . . . 313E.1.2 Autopilot models (systems APILOT1 to APILOT3) . . . . . . . . 316E.1.3 Radio-navigation models (library NAVLIB) . . . . . . . . . . . . 318E.1.4 Wind and turbulence models (library WINDLIB) . . . . . . . . . 319

F The Open Software License v. 2.1 321

vi CONTENTS

G Common Documentation License 325

Bibliography 329

Chapter 1

Flight control system development

During the last decades, active flight control technology has dramatically changedthe way aircraft are designed and flown. Flight control systems with mechanicallinkages have been replaced by full authority, ‘fly-by-wire’, digital control systems.As a consequence, the flying qualities of modern aircraft are largely determined by aset of control laws in the heart of a computer system.

Modern computer assisted control system design (CACSD) software provides awide variety of user-friendly analytical tools that can assist in flight control system(FCS) design and analysis. A typical example is the MATLAB / SIMULINK softwareenvironment from The Mathworks, which offers advanced modelling and simula-tion capabilities and easy access to control system design tools. The Mathworks andother vendors offer several specialized toolboxes for a wide range of control systemdesign methods.

A prerequisite for successful FCS design is the availability of sophisticated math-ematical models of the airplane, the environment it has to operate in, and elementsfrom the control system itself. The FDC toolbox tries to offer such models for theMATLAB / SIMULINK environment, and several tools and utilities to access thosemodels. This chapter provides an overview of flight control systems in general, andoffers some insight in the FCS design process, in order to put the objectives behindthe FDC toolbox into the right perspective.

1.1 Automatic flight control systems

A major factor in Wright brothers’ success in achieving the first powered flight in De-cember 1903 has been the emphasis they placed on making their aircraft controllableby the pilot, rather than inherently stable. However, the difficulties of controllingearly aircraft and the progress toward longer flight times, expanded flight-envelopes,and bigger aircraft created a need for the development of power-driven aerodynamiccontrol surfaces, stability augmentation systems, and ‘automatic pilot systems’. Thisevolution of flight control systems has been parallelled by the development of closed-loop control theories and major achievements in computer technologies [33].

Since the term ‘automatic flight control systems’ can be used to describe a widevariety of controllers, categorizing them into different categories can be beneficial.The first class of automatic controllers are the Stability Augmentation Systems (SAS).

2 Chapter 1. Flight control system development

These systems are used to damp and stabilize high-frequency rotational modes ofthe aircraft, making it easier for pilots to control the aircraft. Common types of SASare roll dampers, pitch dampers, and yaw dampers.

If an augmentation system is intended to control a rotational mode and to pro-vide the pilot with a particular type of response to the control inputs, it is known asa Control Augmentation System (CAS) [33]. Examples are controllers for the roll rate,pitch rate, and normal acceleration of an aircraft. CAS systems that are coupled toa conventional control system with a direct mechanical linkage between the controlactuators and the control column, are often called ‘control wheel steering systems’(CWS). If the connection is achieved by means of electrical (or optical) wires, suchcontrollers are usually called ‘fly-by-wire systems’.

Although the slow modes of an aircraft (phugoid and spiral) are more easily con-trollable by a pilot, it still is undesirable for a pilot to have to pay continuous atten-tion to controlling these modes, especially during longer flights. Therefore, an auto-matic controller is often needed to provide ‘pilot relief’. An autopilot is an automaticcontrol system that provides both pilot relief functions and special functions such asautomatic landing. Typical autopilot functions are attitude hold, altitude hold, turn-coordination, heading select, automatic approach, and VOR navigation. Modernaircraft also allow the autopilot to be coupled to a flight management system (FMS),which offers flight path optimisation and wide-area navigation through the use ofinertial reference system and global positioning system guidance and navigation.

In summary, we can conclude that the main function of an FCS is to contributeto the safe, comfortable, and economic operation of the aircraft, such that the in-tended flight missions can be accomplished and unexpected events can be handled.A modern FCS consists of three main components [24]: (i) sensors, which providethe flight control computers information on air data, inertial data, and cockpit data,(ii) the flight control computers themselves, which are used to evaluate the flight con-trol laws, and (iii) the actuation systems of the aircraft control surfaces and throttles.Feedback control is used to provide tight pilot command tracking, to attenuate ex-ternal disturbances such as gusts and turbulence, and to provide robustness againstmodelling errors.

Fly-by-wire systems allow the pilot to control aircraft states, in contrast to the con-ventional direct control of aerodynamic control surfaces and engines. This offersenhanced flexibility for the control laws, which provides new opportunities to in-crease the overall safety level. For example, error-tolerant control laws can provideflight envelope protection, and help the pilot to successfully achieve critical flightmanoeuvres and to recover from unusual attitudes. The use of a modern FCS canalso be beneficial from an economic point of view: fuel consumption can sometimesbe reduced by relaxing static stability, counteracted by the application of active con-trol, and the weight of fly-by-wire systems is often lower than that of conventionalcontrol systems. Furthermore, fly-by-wire systems make it possible to give differ-ent aircraft of different sizes almost the same ‘feel’, allowing the creation of a largeaircraft family that will significantly reduce pilot training costs.

Most importantly, modern flight control systems have contributed to improveddynamical behaviour. Certain military aircraft cannot be flown without a stabilityaugmentation system; they use the open-loop instability, which is related to the

1.2. The FCS design cycle 3

agility of the aircraft, to obtain better performance and improved manoeuvrabilityof the closed-loop system. For civil aircraft, active flight control systems can providegust suppression and auto-trimming, in order to achieve improved ride quality.

A disadvantage of these techniques is that the costs and efforts involved to de-velop an advanced FCS have escalated over the years. The danger exists that theeconomical benefits described above are nullified by higher design and maintenancecosts, while the increasing complexity of modern flight control systems can poten-tially have a negative effect on safety. Clever use of modern FCS design techniquesand optimisation of the design tools will be necessary to counteract these disadvan-tages [24].

1.2 The FCS design cycle

Regardless of the level of complexity, it is always possible to divide the control sys-tem design process into a number of distinct phases. A practical division is given inref.[26] (a reference, which, albeit somewhat outdated with respect to the availablecomputer hardware and software tools, is still valuable for this discussion):

1. Establish the system purpose and overall system requirements. System pur-pose can be equated with mission or task definitions, while the system require-ments can be separated in (i) operational requirements, derived from the func-tions needed to accomplish the mission phases and (ii) implied requirements, de-rived from the characteristics of the interconnected components of the controlsystem and the environment in which they operate.

2. Determine the characteristics of unalterable elements, command-signals, andexternal disturbances. The characteristics of some parts of the system cannoteasily be changed by the designer. Often the vehicle itself, its control surfaceactuators and sometimes also its sensors are ‘unalterable’.1 Moreover, the struc-ture of the commands and disturbances is a direct consequence of the missionrequirements and the environment in which the control system has to operate.

3. Evolve competing feasible systems, i.e. determine the basic block diagrams.Usually, there are more ways to achieve the requirements, e.g. with differentsensed motion quantities and/or the application of different control theories.Then it is possible to evolve competing candidate systems for selection on thebasis of certain desirable properties.

4. Select the ‘best’ system. The competing designs can be compared on the basisof (i) design qualities, which include dynamic performance (speed of response,bandwidth, etc.) and physical characteristics (volume, weight, power consump-tion, etc.), and (ii) design quantities, which include safety, reliability, maintain-ability, cost, etc. An optimum system is one that has some ‘best’ combinationof these features.

1If the FCS is designed for an all-new aircraft, the selection of the hardware (sensors, actuators,computers, etc.) must be included in the FCS design and analysis instead of taking the hardware asbeing unalterable. In this report, all hardware is considered to be given, so we will concentrate on issueof developing appropriate control laws to make a given aircraft fly a certain mission.


5. Study the selected system in detail. The selected system must be evaluated forall normal and abnormal operating conditions. At each step in the FCS valida-tion the assumptions made earlier in the FCS design process must be checkedfor validity. If necessary, a new iteration of the design should be started fromthe point where the wrong assumption was made.

This scheme reflects the FCS design process within a manufacturing environment.In a research context, the design process may have to be modified somewhat, as theresearch and manufacturing tasks are clearly different: whereas the task of researchis to determine what is required and to produce a clear and comprehensive defini-tion of the requirements, the manufacturing task is to make and deliver a reliableand effective product [35]. Consequently, the first FCS design phase in particularwill often be different in a research environment, because the system requirementsare often poorly understood or may even be the objective of the research itself. Inaddition, the design tools may still be immature, and their development may itselfbe an objective of the research. See for instance the development of the FDC toolboxin the context of the Beaver autopilot studies.

The design, simulation, and implementation of control laws within a researchcontext will be similar to the manufacturing task, although more flexibility of thetools will sometimes be required. For instance, it should be possible to rapidly alterthe control laws within the flight control computers of the aircraft in order to evaluatedifferent solutions to typical control system design problems with a minimum ofprogramming efforts. In the research environment, step 4 does not necessarily needto include the selection of a ‘best’ system since it may be useful to evaluate competingcontrol solutions, if necessary even all the way up to evaluation in real flight, just togain more knowledge about their advantages and disadvantages. A typical exampleof this can be found in ref.[24], which treats a GARTEUR design challenge of robustflight control systems.

Finally, the requirements with respect to fail-safety of the FCS may be less restric-tive in a research context than for manufacturing. For instance, during the autopi-lot design project for the DHC-2 Beaver laboratory aircraft, a single flight controlcomputer (a ‘luggable’ 80286 Compaq PC, coupled to a 16-bit ROLM-1603 general-purpose computer that handled the I/O functions; see refs.[6], [28], [37], and [38])was used, whereas production aircraft normally apply multiple FCCs that constantlymonitor eachother’s command signals.

1.3 Taking a closer look at the FCS design cycle

Let’s explore the individual design phases a little further. Figure 1.1 visualizes thefirst step in the FCS design process: the definition of the mission, which imposes re-quirements upon the shape of the flight-path and the velocity along this flight-path.This translates into the control problem depicted in figure 1.2: how to generate ap-propriate deflections of aerodynamic control surfaces or changes in engine power orthrust such that this mission can be fulfilled.

The classical approach to the FCS design problem is to start with the complete setof non-linear equations of motion, and then make assumptions which enable theseequations to be linearized about some local equilibrium point. Getting familiar with

1.3. Taking a closer look at the FCS design cycle 5

Mission

Flight-path ( )t

Control SurfaceDeflections ( )δ t

Figure 1.1: Definition of the aircraft’s mission

Specify ControlProblem

Design ControlLaws

Achieve SpecifiedBehaviour

Model

Real World

Figure 1.2: The general flight control problem

the dynamical behaviour by means of trimming, stability and control analysis, andnonlinear open-loop simulations (for stable aircraft), and understanding the influ-ences of the modelling assumptions is very important, and linear simulation of theaircraft model may also be required at this stage [24].

The next step is to define the controller architecture. In the initial phase of the FCSdesign, control system design tools based upon linear system theory can be appliedto linearized models of the aircraft and its subsystems; modern CACSD softwareprovides the required computer support. Although the linear control system designand analysis techniques will provide insight in the essential behavior of the FCS,only relatively small deviations from the equilibrium state are permitted before theresults start to deviate from those of the real aircraft.

Luckily the main purpose of many FCS control laws is to keep the deviationsfrom the equilibrium state as small as possible, e.g. in order to maintain a certain alti-tude or heading, but there are other control laws which require large deviations fromnominal values, e.g. selecting a new reference heading or altitude which differs con-


siderably from the original value. For this reason, detailed nonlinear simulations willbe required, in order to validate (and possibly enhance) the results from the linearanalysis and design phase. Gain scheduling functions need to be implemented, toensure that the FCS will work well over the compete range of the flight-envelopefor which it is designed, taking into account a suitable safety margin. Also, sig-nal limiters will be required to deal with certain physical limitations (e.g. the max-imum deflection of control surfaces) and for safety reasons. If a robust design is tobe achieved, much attention should be given to understanding nonlinearities andmodel uncertainties.

This off-line analysis, which should cover a wide range of velocities and altitudesand all possible aircraft configurations, can be performed on a single PC or work-station, using an integrated design and simulation environment such as MATLAB /SIMULINK. ‘Off-line’ in this context means that the analysis does not have to be per-formed in real-time and does not yet include piloted flight-simulation. In a laterstage the control system will have to be evaluated in a real-time pilot-in-the-loopsimulation environment, to enable test-pilots to assess the handling qualities of theautomatically controlled aircraft. In particular, the pilot–aircraft interaction shouldbe examined thoroughly, especially if the pilot will be actively involved in the air-craft control loop (e.g. for fly-by-wire systems).

Based upon these results it is possible to select the best solution if there are morefeasible methods to fulfill the mission requirements. If the results of the on-line andoff-line analysis are completely satisfactory the next step in the design process willbe the implementation of the control laws in the flight control computer(s) of theaircraft. The actuators and sensors in the aircraft must be installed (if that hasn’t beendone already), thoroughly tested, and calibrated. For some purposes, e.g. aircraftcertification, it may even be useful to test the complete control system in an ‘IronBird’ test-stand arrangement with hardware-in-the-loop simulation capabilities.

Special care has to be taken to prevent errors due to the conversion of controllaws when moving from one design phase to the next. In particular, the transfer ofcontrol laws from the simulation environment to the flight control computers of theaircraft needs to be carefully verified, to ensure that the control laws used in flightmatch those analyzed on the ground.1 In order to reduce the risks of such conversionerrors, it would be beneficial to be able to couple at least the complete FCC software,but preferably also its hardware, to the real-time flight-simulator and/or off-line de-sign environment.

After successfully concluding the simulations and ground tests of the hardware andFCC software, the FCS can be evaluated in real flight. In an ideal world this phasewould only be a straightforward verification of the previous results, but in practiceit will often be necessary to return to a previous stage in the FCS development forfixing errors or fine-tuning the control laws. It also may be necessary to update themathematical models if deficiencies in these models are found during the in-flight

1During the Beaver autopilot studies some dramatic examples of conversion errors were encoun-tered, luckily for a large part before the flight-tests were started. Still, some minor errors remained undis-covered until the actual flight-tests! References [28], [37], and [38] provide ample food for thought forfuture FCS projects.

1.4. FCS design environments 7

evaluations. Quantitative results from the flight tests need to evaluated on-groundto confirm the correct control behavior. Obviously, the off-line CACSD environmentthat was used for the FDC design can also provide the required computer supportfor this post-flight analysis.

The iterative nature of this FCS development cycle should be acknowledged: atany stage in the process, the discovery of a fault, design error, or previously unrecog-nized uncertainty might require the return to a previous design stage. Figure 1.3summarizes the FCS design process. It illustrates the different design stages fromref.[26] and the more detailed divisions presented in refs.[12], [31] and [35], and itclearly acknowledge the iterative nature of the whole process. On the left-hand sideof the figure the models and tools (software and hardware environments) are shown,while the right-hand side shows the design stages themselves.

1.4 FCS design environments

It is obviously very important to make the transitions between the different develop-ment phases as straightforward as possible, in order to reduce the number of tran-sition errors which inevitably will arise if the tools for the different phases are notcompatible (Murphy’s Law), and also to reduce the time needed for the FCS develop-ment.

For this reason, there is a need for an integrated software environment that pro-vides full access to all required mathematical models, as well as a large range oflinear and nonlinear control system design and simulation tools, preferably from asingle PC or workstation. The software tools for the off-line analysis should be ableto effectively communicate with eachother, the tools for real-time pilot-in-the-loopsimulations, and with the flight control computers of the actual aircraft. Access tothe mathematical models and the control systems should be made as easy as possible,using a modern (graphical) user-interface.

Refs.[12] and [31] present some practical examples of integrated FCS design envi-ronments. These papers particularly emphasize the need for multidisciplinary designin which aerodynamic, structural, propulsive, and control functions are consideredall together. This is important, because modern flight controllers may excite struc-tural modes of the aircraft and interact with the control-actuator dynamics, and be-cause of the increasing need to integrate flight controls with engine controls andload-alleviation functions. Interactions between the aerodynamic, propulsive, andstructural models must be taken into account, especially for modern aircraft that em-ploy extensive use of composite materials (resulting in greater aero-elastic coupling)and relaxed static stability.

The Flight Dynamics and Control toolbox that is presented in this report attemptsto bring the required tools and models together in the MATLAB / SIMULINK envi-ronment. It basically provides easy access to the flight dynamics models and otherrelevant dynamic models, allowing the FCS designer to use MATLAB (if necessaryincluding a selection of the available control system design tools) for the initial FCSdevelopment, and use SIMULINK for the subsequent nonlinear off-line simulations.The toolbox itself provides an analytical software tool to trim aircraft models forsteady-state flight. It applies SIMULINK functions to extract linear state-space de-


M

S

F

A

A

M

S

F

Linearizedmodels

SIMULINKmodel-librarywith nonlinearaircraft model

Flightsimulatormodel-librarywith nonlinearaircraft model

LinearFCS design

Nonlinear FCSvalidation &fine-tuning

Evaluation in real-time

piloted flight-simulation

ImplementingFCS hardwareand software

Evaluation inreal flight

Trimming &

Linearization

Future: automatic

transfer of models?

Update sensor/actuator models

Update aero/engine models

Current

scope of the

FDC envi-

ronment

Future

enhance-

ments

M

S

F

A

====

MATLAB

SIMULINK

Real-time flightsimulator

Actual aircraft

Figure 1.3: FCS design cycle using MATLAB and SIMULINK

scriptions of aircraft models and perform digital flight simulation. Several otherMATLAB toolboxes, from The Mathworks and others, can be used to perform a mul-titude of analytical operations on the linear equations.

1.5 FCS design and the FDC toolbox

The current scope of the FDC toolbox is shown in figure 1.3, above the dashed line onthe right. Starting from the SIMULINK model library, it is possible to obtain linearizedmodels. Using designated control system design tools from other MATLAB toolboxes,controllers can be developed for the resulting linear systems. The resulting controllaws can be evaluated in SIMULINK, by means of nonlinear simulations; the requiredmodels are again obtained from the FDC model library.

However, the FDC toolbox does not (yet) offer any help to simplify the subse-quent design steps, being evaluation in a real-time piloted flight simulator and eval-

1.5. FCS design and the FDC toolbox 9

Off-line

Real-time

Graphical SIMULINK system Graphical SIMULINK system

Flight Control Computer

Flight Simulator

Control Laws(block-diagram)

Control Laws(C-code)

Control Laws(C-code) Control Laws

(C-code)

C-code

generator

Figure 1.4: ‘Portable’ control laws

uation in real flight. If the designer wants to move his control laws to these nextlevels, he or she will still have to convert the control laws and the dynamic modelsmanually to the flightsimulator and/or the flight control computers of the airplane;the FDC toolbox does not provide any assistance for that task. This is obviously stilla major obstacle in the FCS development process, because it increases the chance ofencountering conversion errors, as explained earlier.

The figure suggests that automatic transfer of complete simulation models fromthe SIMULINK environment to a flightsimulator might be feasible. However, it wouldprobably not be easy to ensure the integrity of such automatically converted models.A less ambitious, but perhaps more realistic proposal would be to focus on auto-matic conversion of the control laws only, using e.g. automatic code-generation soft-ware to translate SIMULINK models into a high-level programming language like C.Dedicated interface-subroutines that will optimize communications between the off-line SIMULINK-environment and the on-line flightsimulator environment could helpstreamline these conversions. This concept of ‘portable’ flight control laws has beenillustrated in figure 1.4, assuming that the language C is used to implement the flightcontrol laws in the flightsimulator and FCCs.

The Mathworks offers several solutions which could be helpful for this purpose,such as the REALTIME WORKSHOP and the REALTIME WORKSHOP EMBEDDED CO-DER, the latter of which targets real-time embedded processors, DSP boards, real-time operating systems, and PCs. Other useful third-party tools that could be ap-plied to interface with the FDC models are STATEFLOW, which can e.g. be used to cre-ate very complex mode-controller systems, the DIALS & GAUGES BLOCKSET, whichallows a.o. graphical display of cockpit instruments during SIMULINK simulations,


and the VIRTUAL REALITY TOOLBOX, which provides three-dimensional animationfacilities for SIMULINK models. There are also several third-party products availablethat allow SIMULINK models to be coupled to specific experimental hardware se-tups. By integrating MATLAB, SIMULINK, and other tools that allow easy interfacingwith external simulation devices or FCC’s, quick prototyping of flight control lawsbecomes feasible, and the transitions between off-line simulations, real-time simula-tions, and actual flight could be streamlined enormously.

It is not likely that these functions will soon be integrated in future versions of theFDC toolbox, no matter how exciting those prospects may be. Any future work onthis software will probably mainly be concentrated on optimizing and improving theexisting tools and models, and widening the application areas of the toolbox withinits current scope. However, it is hoped that this far-reaching vision of FDC’s futurewill inspire others to develop their own add-ons or variants of the software, so thatmaybe one day some parts of this vision will be realized.

Chapter 2

Rigid body equations of motion

Before we can start building the mathematical model of the aircraft, some fundamen-tal knowledge about the equations of motion is needed. In this chapter, the equationsof motion of a rigid aircraft will be derived and expressed in the state-space form; asummary of these state equations will be given in section 2.5. The next chapter willbuild upon these equations to construct the nonlinear six-degree-of-freedom aircraftmodel. 1

2.1 General rigid-body equations of motion

The aircraft equations of motion will be derived from Newton’s laws, which statethe connection between force and motion. We start by deriving the general force andmoments equations for a rigid body and defining the relations for the angular mo-mentum. This results in six ordinary differential equations, representing the linearand angular accelerations in the body-fixed reference frame.

2.1.1 General force equation for a rigid body

Consider a mass point δm that moves with time-varying velocity V under the influ-ence of a force F. Both V and F are measured relatively to a right-handed orthogonalreference frame OXYZ. This reference frame may be moving with a constant linearvelocity, relative to the fixed position of the stars (a.k.a. ‘inertial space’), but it maynot accelerate or rotate. Applying Newton’s second law yields:

δF = δm · V (2.1)

Applying this equation to all mass points of a rigid body and summing all contribu-tions across this body yields:

∑ δF = ∑ δmdVdt

=ddt ∑ Vδm (2.2)

Let the center of gravity of the rigid body have a velocity Vc.g. with componentsu, v, and w along the X, Y, and Z-axes of the right-handed reference frame. Thevelocity of each mass point within the rigid body then equals the sum of Vc.g. and

1The derivation of the rigid-body equations has been extensively discussed in literature. This chap-ter has been inspired by refs.[11, 14, 15, 16, 19, 20, 25, 25, 26], and [33] (to name just a few).

12 Chapter 2. Rigid body equations of motion

the velocity of the mass point with respect to this center of gravity. If the position ofthe mass point with respect to the c.g. is denoted by the vector r, the following vectorequation is found:

V = Vc.g. + r (2.3)

therefore:

∑ Vδm = ∑(Vc.g. + r)δm = mVc.g. +ddt ∑ rδm (2.4)

In this equation, m denotes the total mass of the rigid body. In the center of gravitywe can write:

∑ r δm = 0 (2.5)

so the equation for the total force F acting upon the rigid body, becomes:

F = mVc.g. (2.6)

2.1.2 General moment equation for a rigid body

The moment δM, which is measured around the center of gravity, is equal to thetime-derivative of the angular momentum of the mass point relative to the c.g.:

δM =ddt

(r×V)δm = (r×V)δm + (r× V)δm (2.7)

where:

r = V−Vc.g. (2.8)

and:

(r× V)δm = r× δF = δMc.g. (2.9)

In this equation δMc.g. denotes the moment of the force δF about the center of gravity.The angular momentum of the mass point relative to the c.g. will be denoted by δh,which is defined as: δh ≡ (r×V)δm. Writing this out yields:

δMc.g. = δh− (V−Vc.g.)×Vδm = δh + Vc.g. ×Vδm (2.10)

The contributions of all mass points are once again summed across the whole rigidbody, yielding:

∑ δMc.g. = ∑ δh + Vc.g. ×∑ Vδm (2.11)

The equation for the resulting moment Mc.g. about the c.g. then becomes:

Mc.g. = h (2.12)

where h denotes the resulting angular momentum of the body about the center ofgravity.

2.1.3 Angular momentum around the center of gravity

Consider a rigid body with angular velocity Ω, with components p, q, and r aboutthe X, Y, and Z axes of the right-handed reference frame respectively:

Ω = i p + j q + k r (2.13)

2.1. General rigid-body equations of motion 13

symbol definition

Ixx ∑(y2 + z2) δmIyy ∑(x2 + z2) δmIzz ∑(x2 + y2) δmJxy ∑ xy δmJxz ∑ xz δmJyz ∑ yz δm

Table 2.1: Moments and products of inertia

where i, j, and k are unity vectors along the X, Y, and Z-axes. The total velocityvector of a mass point of a rigid body that both translates and rotates becomes:

V = Vc.g. + Ω× r (2.14)

hence, the angular momentum of the rigid body about the c.g. can be written as:

h ≡ ∑ δh = ∑ r× (Vc.g. + Ω× r)δm = ∑ r×Vc.g.δm + ∑ r× (Ω× r)δm(2.15)

The first term of the right hand side of equation (2.15) is equal to zero:(∑ rδm

)×Vc.g. = 0 (2.16)

and for the second term we can write:

∑ r× (Ω× r)δm = ∑

Ω(r · r)− r(Ω · r)

δm = ∑

Ω‖ r‖2 − r (Ω · r)

δm(2.17)

Substitution of r = i x + j y + k z, (2.16), and (2.17) in equation (2.15) yields:

h = Ω ∑(x2 + y2 + z2)δm−∑ r (px + qy + rz)δm (2.18)

The components of h along the X, Y, and Z axes will be denoted as hx, hy, and hzrespectively, yielding:

hx = p ∑(y2 + z2)δm− q ∑ xy δm− r ∑ xz δmhy = −p ∑ xy δm + q ∑(x2 + z2)δm− r ∑ yz δmhz = −p ∑ xz δm− q ∑ yz δm + r ∑(x2 + y2)δm

(2.19)

The summations appearing in these equations are defined as the inertial momentsand products about the X, Y, and Z axes respectively; see table 2.1.1 Using thesedefinitions, equations (2.19) can be written in vector notation as a product of theinertia tensor I with the angular velocity vector Ω:

h = I ·Ω (2.20)

where I is defined as:

I =

Ixx −Jxy −Jxz−Jyx Iyy −Jyz−Jzx −Jzy Izz

(2.21)

1The summations across the body actually have to be written as integrals, but that further refine-ment has been omitted here.


If the airplane is symmetrical, Jxy and Jyz are both identically zero, which would fur-ther simplify the inertia tensor. Although this assumption is often made in literature,this report will consider the more general case where the aircraft does not necessarilyhave to be symmetrical.

So far, in this analysis of angular motion we have neglected the angular momentumof any spinning rotors, assuming that the airplane is a single rigid body. However,these effects can actually be quite significant in practice. For example, a number ofWorld War I aircraft had a single ‘rotary’ engine that had a fixed crankshaft and rotat-ing cylinders; the gyroscopic effects caused by the angular momentum of the enginegave these aircraft tricky handling characteristics. The effects are also noticeable inmaneuvering flight of a small jet with a single turbofan engine on the longitudinalaxis [33].

Each rotor has an angular momentum relative to the body axes. This can becomputed from equation (2.20) by interpreting the moments and products of inertiatherein as those of the rotor with respect to the axes parallel to the airplane body-axes and origin at the rotor mass center. The angular velocities in equation (2.20)are interpreted as those of the rotor relative to the airplane body axes [15]. If theresultant relative angular momentum of all rotors is called h′, with components h′x,h′y, and h′z in FB, which are assumed to be constant, the total angular momentum ofan airplane with spinning rotors can be obtained by simply adding h′ to the angularmomentum of the airframe:

h = I ·Ω + h′ (2.22)

The additional terms in the angular momentum cause certain extra terms, known asgyroscopic couples, to appear in the moment equations, as we will see later.

2.1.4 Resulting general equations of motion for a rigid body

When we choose a reference frame fixed to the body (OXYZ = OXBYBZB) the inertialmoments and products from the equations (2.19) become constants. The referenceframe itself then rotates with angular velocity Ω. For an arbitrary position vector rwith respect to the body reference frame we can then write:

r =∂r∂t

+ Ω× r (2.23)

Applying equation (2.23) to the general force and moment equations for a rigid body,(2.6) and (2.12), we find:

F = m(

∂Vc.g.

∂t+ Ω×Vc.g.

)(2.24)

and:

Mc.g. =∂h∂t

+ Ω× h =∂

∂t(I ·Ω + h′

)+ Ω×

(I ·Ω + h′

)=

=∂

∂t(I ·Ω) + Ω× (I ·Ω) + Ω× h′ (2.25)

The last term in this equation, Ω × h′, contains the gyroscopic couples, which takeinto account the effect of spinning rotors. Notice that this derivation assumes theresulting angular momentum of the rotors to be constant.


symbol definition

|I| Ixx Iyy Izz − 2Jxy Jxz Jyz − Ixx Jyz2 − Iyy Jxz

2 − Izz Jxy2

I1 Iyy Izz − Jyz2

I2 Jxy Izz + Jyz Jxz

I3 Jxy Jyz + Iyy Jxz

I4 Ixx Izz − Jxz2

I5 Ixx Jyz + Jxy Jxz

I6 Ixx Iyy − Jxy2

Pl I1 / |I|Pm I2 / |I|Pn I3 / |I|Ppp −(Jxz I2 − Jxy I3) / |I|Ppq (Jxz I1 − Jyz I2 − (Iyy − Ixx)I3) / |I|Ppr −(Jxy I1 + (Ixx − Izz)I2 − Jyz I3) / |I|Pqq (Jyz I1 − Jxy I3) / |I|Pqr −((Izz − Iyy)I1 − Jxy I2 + Jxz I3) / |I|Prr −(Jyz I1 − Jxz I2) / |I|

Ql I2 / |I|Qm I4 / |I|Qn I5 / |I|Qpp −(Jxz I4 − Jxy I5) / |I|Qpq (Jxz I2 − Jyz I4 − (Iyy − Ixx)I5) / |I|Qpr −(Jxy I2 + (Ixx − Izz)I4 − Jyz I5) / |I|Qqq (Jyz I2 − Jxy I5) / |I|Qqr −((Izz − Iyy)I2 − Jxy I4 + Jxz I5) / |I|Qrr −(Jyz I2 − Jxz I4) / |I|

Rl I3 / |I|Rm I5 / |I|Rn I6 / |I|Rpp −(Jxz I5 − Jxy I6) / |I|Rpq (Jxz I3 − Jyz I5 − (Iyy − Ixx)I6) / |I|Rpr −(Jxy I3 + (Ixx − Izz)I5 − Jyz I6) / |I|Rqq (Jyz I3 − Jxy I6) / |I|Rqr −((Izz − Iyy)I3 − Jxy I5 + Jxz I6) / |I|Rrr −(Jyz I3 − Jxz I5) / |I|

Table 2.2: Definition of inertia coefficients


The vector-equations (2.24) and (2.25) form the basis for the development of the gen-eral rigid-body dynamic model. In order to make these equations usable for controlsystem design and analysis, flight simulation, system identification, and other ana-lytical tasks, they need to be rewritten in nonlinear state-space format. This can beachieved by moving the time-derivatives of the linear and angular velocities to theleft-hand side of these equations:

∂Vc.g.

∂t=

Fm−Ω×Vc.g. (2.26)

∂Ω

∂t= I−1 (Mc.g. −Ω× I ·Ω−Ω× h′

)(2.27)

These equations can be written-out into their components along the body-axes, usingthe following definitions for Vc.g., Ω, F, and Mc.g.:

Vc.g. = i u + j v + k wΩ = i p + j q + k rF = iFx + jFy + kFzMc.g. = iL + jM + kN

This yields:

u =Fx

m− qw + rv

v =Fy

m+ pw− ru (2.28)

w =Fz

m− pv + qu

and:

p = Ppp p2 + Ppq pq + Ppr pr + Pqqq2 + Pqrqr + Prrr2 + Pl L + Pm M + PnN + p′

q = Qpp p2 + Qpq pq + Qpr pr + Qqqq2 + Qqrqr + Qrrr2 + Ql L + Qm M + QnN + q′

r = Rpp p2 + Rpq pq + Rpr pr + Rqqq2 + Rqrqr + Rrrr2 + Rl L + Rm M + RnN + r′

(2.29)

The last terms in equations (2.29) express the effects of the gyroscopic couples:

p′ = qh′z − rh′yq′ = rh′x − ph′z (2.30)r′ = ph′y − qh′x

Ppp, Ppq, . . . , Rn are inertia coefficients, which are derived from the matrix multipli-cations involving the inertia tensor I; they have been listed in table 2.2.

Equations (2.28) and (2.29) describe the motions of any rigid body relatively to theEarth if the following four restrictive assumptions are made:

1. the body is assumed to be rigid during the motions considered (attached spin-ning rotors are allowed, provided these are accounted for in the moment equa-tions),

2. the mass of the body is assumed to be constant during the time-interval inwhich its motions are studied,


3. the Earth is assumed to be fixed in space, i.e. its rotation is neglected, and

4. the curvature of the Earth is neglected.

The latter two assumptions allow us to assume that the inertial reference frame inwhich the motions of the rigid body are considered is fixed to the Earth. If the equa-tions are to be applied to a moving vehicle, the description of the vehicle motion un-der assumptions 3 and 4 are accurate for relatively short-term guidance and controlanalysis purposes only. The assumptions do have practical limitations when verylong term navigation or extra-atmospheric operations are of interest [26]. Ref.[33]contains a more elaborate model for around-the-Earth navigation.

In order to simplify the notations for the remainder this report, the velocity vectorVc.g. will from this point onwards shortly be denoted as V. The body-axes compo-nents of this vector are u, v, and w, respectively, and the length of this vector isdenoted as V. Likewise, the subscript c.g. will be omitted from the moment vectorMc.g. in the remainder of this report.

In the next chapter, the dynamics of airplanes will be described in terms of therigid-body equations of motion which we just derived. Figure 2.1 gives a graphicalrepresentation of the external forces and moments (Fx, Fy, Fz, L, M, and N), andthe linear and rotational velocity components of the airplane (u, v, w, p, q, and r)in relation to its body-fixed reference frame. The orientation of the body-axes inthis figure conforms to the definition from section A.7.1 of appendix A. The figurealso shows the graphical representation of the airspeed vector V, the angle of attackα, and the sideslip angle β, which define the orientation of the flight-path axes inrelation to the aircraft’s body-axes.

M, q

N, p

F , w

F , v

F , uL, r

Y -axis

c.g.

X -axis

Z -axis

x

y

z

B

B

B

α

β

V

Figure 2.1: Orientation of the linear and angular velocity components, external forces andmoments, angle of attack, and sideslip angle in relation to the body-fixed refer-ence frame of the aircraft.


2.2 Expressing translational motions in flight-path axes

Although it seems logical to express translational velocities in terms of the body-axesvelocity components u, v, and w, it is often more convenient to use the true airspeedV, angle of attack α, and sideslip angle β instead when considering aerodynamicproblems. The latter variables express the translational motions in relation to theflight-path axes (the airspeed vector V coincides with the flight-path or wind-axisXW , while α and β define the orientation of the flight-path reference frame FW inrelation to the body-fixed reference frame FB; see section A.7.1 of appendix A).

2.2.1 Advantages of relating translations to flight-path axes

Since V, α, and β can be expressed in terms of u, v, and w, and vice-versa, it is possibleto use either set of variables for the solution of the equations of motion. However, V,α, and β are usually better suited for simulation tasks, for two reasons:

1. From a physical point of view it is logical to express the aerodynamic forcesand moments in terms of V, α, and β. For simulation purposes, we want thelinear force equations to be re-written as a set of explicit ordinary differentialequations (ODEs), moving all time-derivatives to one side of the equations andall other terms to the other side. This may be difficult to achieve, since the aero-dynamic forces and moments may depend on the time-derivatives of the angleof attack and sideslip angle, while α and β themselves will not not available un-til after the force equations have been evaluated. In practice it is often possibleto assume a linear relationship between these time-derivatives and the aerody-namic forces, which makes it relatively easy to convert the force equations toexplicit ODEs (this has been demonstrated in section 3.4 for the Beaver model),provided the translational equations are written in terms of α and β instead ofv and w.

2. A higher accuracy of the numerical computations can be achieved by relatingthe translational motions to the flight-path axes. For agile aircraft having an up-per limit of the pitch rate q of about 2 rad s−1, and flying at high airspeeds (e.g.V = 600 m s−1), the term u q in equation (2.28) may become as large as 120 g!On the other hand, the factor Fz/m, which represents the normal accelerationdue to the external force along the ZB-axis (primarily gravity and aerodynamiclift) has an upper-limit of only a few g’s. Hence, ‘artificial’ accelerations ofmuch greater magnitude than the actual physical accelerations of the aircraftare introduced in the equations for u, v, and w, because of the high rotationrates of the body-axes. In practice this means less favourable computer scal-ing and hence poorer accuracy for a given computer precision if the simulationmodel is based upon body-axes velocity components [16].

Because of said advantages, we will later treat V, α, and β as state variables in theresulting nonlinear state-space model of the aircraft, while u, v, and w (and theirtime-derivatives) will be treated as output variables. The first three variables are re-quired to solve the equations of motion; the other ones provide useful additionalinformation, that allows us to determine e.g. airplane drift due to wind and atmos-pheric turbulence.

2.2. Expressing translational motions in flight-path axes 19

V-X

D

L

-Za

a

α

Figure 2.2: Relationship between the aerodynamic forces in flight-path and body-axes

2.2.2 Expressing forces and velocities in terms of flight-path axes

Transforming the forces and velocities from body to flight-path axes is quite straight-forward (see ref.[14] for a detailed description). From figure 2.1, we can observe thatthe body-axes velocity components are equal to: u

vw

= V

cos α cos βsin β

sin α cos β

(2.31)

Hence:

V =√

u2 + v2 + w2 (2.32)

α = arctan(w

u

)(2.33)

β = arctan(

v√u2 + w2

)(2.34)


Aerodynamic forces and moments are commonly expressed in terms of aerodynamiclift L, drag D, and sideforce Y, which are aligned along the flight-path axes ZW (innegative direction, i.e. upwards), XW , and YW , respectively. However, for simulationpurposes, it is more convenient to use the body-axes force-components Xa, Ya, andZa instead. The relationship between these variables has been shown in figure 2.2.The body-axes components can be derived from the flight-path axes components bymeans of the following axis-transformation: Xa

Ya−Za

=

− cos α 0 sin α0 1 0

sin α 0 cos α

· D

YL

(2.35)

Notice the minus sign for the aerodynamic force component along the ZB-axis, whichis due to the fact that the positive ZB-axis points downwards.

2.2.3 Derivation of the V-equation

From equation (2.32) we can deduce that:

V =uu + vv + ww

V(2.36)

Substituting the definitions (2.31) for u, v, and w, and cancelling terms yields:

V = u cos α cos β + v sin β + w sin α cos β (2.37)

If we substitute equations (2.28) for u, v, and w, the terms involving the vehicle rota-tional rates p, q, and r turn out to be identically zero, which becomes obvious afteragain substituting equation (2.31) for u, v, and w. The resulting equation becomes:

V =1m(

Fx cos α cos β + Fy sin β + Fz sin α cos β)

(2.38)

2.2.4 Derivation of the α-equation

Differentiating equation (2.33) with respect to the time yields:

α =uw− uwu2 + w2 (2.39)

Using equation (2.31) we can re-write the denominator of this equation:

u2 + w2 = V2 − v2 = V2(1− sin2 β) = V2 cos2 β (2.40)

Substituting the u and w-relations from equation (2.31) and equation (2.40) into equa-tion (2.39) yields:

α =w cos α− u sin α

V cos β(2.41)

Substituting equations (2.28) for u and w, and rewriting terms yields:

α =1

V cos β

1m

(−Fx sin α + Fz cos α) + pv cos α + qu cos α + qw sin α− rv sin α

(2.42)

Using equations (2.31) for u, v, and w, we find:

α =1

V cos β

1m

(−Fx sin α + Fz cos α)

+ q− (p cos α + r sin α) tan β (2.43)

2.3. Equations of motion in nonsteady atmosphere 21

2.2.5 Derivation of the β-equation

Differentiating equation (2.34) with respect to the time yields:

β =v(u2 + v2)− v(uu + ww)

V2√

u2 + w2(2.44)

From equations (2.31) the following relations can be derived:

u2 + w2 = V2 cos2 β

uv = V2 sin β cos β cos α

vw = V2 sin β cos β sin α (2.45)

These values substituted in equation (2.44) yield:

β =1V

(−u cos α sin β + v cos β− w sin α sin β) (2.46)

Substituting equations (2.28) for u and w yields:

β =1V

1m

(−Fx cos α sin β + Fy cos β− Fz sin α sin β) + qw cos α sin β +

− rv cos α sin β + pw cos β− ru cos β + pv sin α sin β− qu sin α sin β

(2.47)

If we substitute equations (2.31), many terms can be cancelled and we find:

β =1V

1m

(−Fx cos α sin β + Fy cos β− Fz sin α sin β)

+ p sin α− r cos α (2.48)

2.3 Equations of motion in nonsteady atmosphere

The equations of motion are valid only if the body-axes velocity components are mea-sured with respect to a non-rotating system of reference axes having a constant trans-lational speed in inertial space. Under the assumptions 3 and 4 from section 2.1.4,it is possible to select a reference frame that is fixed to the surrounding atmosphereas long as the wind velocity vector Vw is constant. In that case, the components u,v, and w of the velocity vector V express the aircraft’s velocity with respect to thesurrounding atmosphere.

If the wind velocity vector Vw is not constant during the time-interval over whichthe motions of the aircraft are studied it is not possible to fix the reference frame tothe surrounding atmosphere. This happens for instance during the approach andlanding of an aircraft, because the wind velocity changes with altitude. Again usingassumptions 3 and 4 of section 2.1.4, the most obvious choice of the reference framein this case turns out to be the Earth-fixed reference frame FE [19].

Let Ve be the velocity with respect to the Earth, Va the velocity with respect to thesurrounding atmosphere, and Vw the wind velocity with respect to the Earth. Thenwe can write:

Ve = Va + Vw (2.49)


or:

ue = ua + uw

ve = va + vw (2.50)we = wa + ww

where ue, ve, and we are the components of V, ua, va, and wa are the components ofVa, and uw, vw, and ww are the components of Vw, all measured along the body-axesof the aircraft. The force equations now become:

F = m(

∂Ve

∂t+ Ω×Ve

)(2.51)

Rewriting equation (2.51) yields:

∂Ve

∂t=

Fm−Ω×Ve (2.52)

For the individual components along the body-axes we thus find:

ue =Fx

m− qwe + rve

ve =Fy

m+ pwe − rue (2.53)

we =Fz

m− pve + que

In order to compute the aerodynamic forces and moments, it is necessary to know thevalues of Va (the true airspeed), α, and β.1 In a manner analogous to the derivationof V, α, and β in section 2.2, we can find expressions for the time-derivatives of Va,αa, and βa:

Va =1m(

Fx cos α cos β + Fy sin β + Fz sin α cos β)+

− (qww − rvw + uw) cos α cos β + (pww − ruw − vw) sin β +

− (pvw − quw + ww) sin α cos β (2.54)

αa =1

V cos β

1m

(−Fx sin α + Fz cos α) +

− (pvw − quw + ww) cos α + (qww − rvw − uw) sin α

+

+ q− (p cos α + r sin α) tan β (2.55)

βa =1V

1m

(−Fx cos α sin β + Fy cos β− Fz sin α sin β) +

+ (qww − rvw + uw) cos α sin β + (pww − ruw − vw) cos β +

+ (pvw − quw + ww) sin α sin β


The subscript a has been used here for reasons of clarity only, allowing us to makea clear distinction between the equations for a steady atmosphere and the equations

1Notice that expressions (2.31) to (2.34) remain valid if Va is substituted for V!

2.4. Kinematic relations 23

for a nonsteady atmosphere. Since V, α, and β are always determined relatively tothe surrounding atmosphere, these subscripts will be omitted again in the remainderof this section.

These expressions differ from equations (2.38), (2.43), and (2.48) in that they in-clude additional terms that depend on the wind velocity components and their time-derivatives. These terms can be expressed in terms of corrections of the external forcecomponents along the aircraft’s body-axes, Fx, Fy, and Fz, This means that we can ap-ply equations (2.38), (2.43), and (2.48) for steady as well as nonsteady atmosphere, aslong as the force components are properly corrected for the wind, if necessary. Thesecorrections will be summarized later in section 3.3.4.

2.4 Kinematic relations

So far we have derived differential equations for the true airspeed, angle of attack,sideslip angle, and the rotational velocity components. However, to solve the equa-tions of motion it is also necessary to know the attitude of the aircraft relatively tothe Earth, because some contributions to the external forces and moments dependupon those quantities. We also need to know the altitude of the aircraft, becausethe air pressure, temperature, and density change with altitude, affecting both theaerodynamic and propulsive forces and moments. And finally, we want to be able totrack the flight path relative to the Earth, e.g. for simulations of navigational tasks.

The orientation of the airplane relative to the Earth is given by a series of three con-secutive rotations, the Euler angles ψ, θ, and ϕ, see figure A.2 from appendix A. Asshown in section A.7.3, the rotations can be expressed by three transformation matri-ces TΨ, TΘ, and TΦ. It is possible to express the total angular velocity of the aircraftexpressed in terms of the derivatives with respect to time of the Euler angles:

pqr

=

ϕ00

+

TΦ︷︸︸︷ 1 0 00 cos ϕ sin ϕ0 − sin ϕ cos ϕ

0θ0

+

+

1 0 00 cos ϕ sin ϕ0 − sin ϕ cos ϕ

︸︷︷︸

TΦ

cos θ 0 − sin θ0 1 0

sin θ 0 cos θ

︸︷︷︸

TΘ

00ψ

(2.57)

This can be written as: pqr

=

1 0 − sin θ0 cos ϕ sin ϕ cos θ0 − sin ϕ cos ϕ cos θ

ϕθψ

= TR

ϕθψ

(2.58)

where TR is the matrix that transforms angular velocities in the Earth-fixed axis sys-tem into body-axes angular velocities. Consequently, the time-derivatives of theEuler angles can be found by pre-multiplying equation (2.58) with TR

−1. This yields


the following kinematic relations:

ψ =q sin ϕ + r cos ϕ

cos θθ = q cos ϕ− r sin ϕ (2.59)

ϕ = p + (q sin ϕ + r cos ϕ) tan θ = p + ψ sin θ

The position of the aircraft with respect to the Earth-fixed reference frame is givenby the coordinates xe, ye, and ze. To find these coordinates, we need to resolve thebody-axis velocity vector in the Earth-bound reference system FE: xe

yeze

= TB→E ·

uevewe

(2.60)

where TB→E = TB→V = TV→B−1 is the transformation matrix from FB to FE, see the

definition in section A.7.3 of appendix A. This results in the following equations:

xe = ue cos θ + (ve sin ϕ + we cos ϕ) sin θ cos ψ− (ve cos ϕ− we sin ϕ) sin ψ

ye = ue cos θ + (ve sin ϕ + we cos ϕ) sin θ sin ψ + (ve cos ϕ− we sin ϕ) cos ψ

ze = −ue sin θ + (ve sin ϕ + we cos ϕ) cos θ (2.61)

In practice, the altitude of the aircraft is a more useful property than the coordinateze. The relationship between the time-derivatives of H and ze is simple:

H = −ze (2.62)

Notice that the positive ZE-axis points downwards.

The state equations (2.59) have the advantage of using physically meaningful varia-bles, and they express the airplane’s attitude using the minimum number of threefirst-order differential equations. However, it should be noted that these equationsalso have some significant disadvantages.

First of all, a division by zero occurs if the pitch angle reaches plus or minus 90.Although in digital simulations, this exact number has an almost zero probability ofoccurrence, this may still cause significant computational errors in the vicinity of thissingularity. Second, the Euler angles may integrate up to values outside the normal±90 range of pitch and the normal ±180 range of roll and yaw angles, which maymake it difficult to determine the attitude uniquely. And finally, the equations arelinear in p, q, and r, but nonlinear in terms of the Euler angles themselves [33].

There are several other ways besides the Euler angles to represent the orientationof a rotated coordinate frame. These methods, which involve four, five, or even sixvariables instead of the three Euler angles, aim to avoid the singularity of the Eulerangle representation, and maximize the speed of computer processing in navigationapplications. The most common of these methods is the so-called quaternion represen-tation, which uses four variables. For a detailed discussion about this method, referto ref.[33]. In this report, we will limit ourselves to the Euler angle representation,because it is still the most commonly used method for aircraft simulations.

2.5. Assembling the state equations 25

2.5 Assembling the state equations

To build the nonlinear state-space model we start with the six differential equationsthat were derived from the basic force and moment equations:

V =1m(

Fx cos α cos β + Fy sin β + Fz sin α cos β)

α =1

V cos β

1m


+ q− (p cos α + r sin α) tan β

β =1V

1m


+ p sin α− r cos α

p = Ppp p2 + Ppq pq + Ppr pr + Pqqq2 + Pqrqr + Prrr2 + Pl L + Pm M + PnN + p′

q = Qpp p2 + Qpq pq + Qpr pr + Qqqq2 + Qqrqr + Qrrr2 + Ql L + Qm M + QnN + q′

r = Rpp p2 + Rpq pq + Rpr pr + Rqqq2 + Rqrqr + Rrrr2 + Rl L + Rm M + RnN + r′

(2.63)

The variables V, α, β, p, q, and r, which represent the linear and angular velocitiesof the aircraft can be regarded as the state variables from this model. The state-spacemodel would already be complete if the body-axes components of the external forcesand moments could be treated as independent input variables, but unfortunately,the external forces and moments themselves depend on the motion variables of theaircraft. Because of this, the state variables need to be coupled back into the forceand moments equations.

As explained in section 2.4, the attitude of the airplane and its altitude are neededto determine the gravitational, aerodynamical, and propulsive forces and moments.This means that the model needs to be extended with the equations for the Eulerangles and the altitude. The aircraft’s horizontal coordinates relative to the surfaceof the Earth are not needed to solve the equations of motion, but they are includedfor practical purposes. This yields an additional six state equations:


cos θθ = q cos ϕ− r sin ϕ

ϕ = p + (q sin ϕ + r cos ϕ) tan θ = p + ψ sin θ



H = ue sin θ − (ve sin ϕ + we cos ϕ) cos θ

(2.64)

with new state variables ψ, θ, ϕ, xe, ye, and H. These twelve state variables arecombined in the state vector x:

x = [ V α β p q r ψ θ ϕ xe ye H ] T (2.65)

and the resulting equations are combined in a single vector equation:

x = f′ (x, Ftot(t), Mtot(t)) (2.66)


If we also collect any external control inputs in the input vector u, and any externaldisturbances in the vector v, we can express the external forces and moments asnonlinear functions of x(t), u(t), and v(t). In addition, the forces and moments maypossibly depend directly on time itself (e.g. the fuel-burn decreases the weight of theairplane in time). Hence:

Ftot(t) = g1 (x(t), u(t), v(t), t)Mtot(t) = g2 (x(t), u(t), v(t), t) (2.67)

Substituting in equation (2.66) yields the nonlinear state-space system:

x(t) = f (x(t), u(t), v(t), t) (2.68)

In some cases, the forces and/or moments not only depend on the state vector x butalso on its time-derivative x, which causes equation (2.68) to become implicit, as xnow appears on both sides of the equation:

x(t) = f(x(t), x(t), u(t), v(t), t) (2.69)

Luckily, this implicit relation can often be written as:

x(t) = f1(x(t), u(t), v(t), t) + f2(x(t), t) (2.70)

which makes it somewhat easier to find a numerical solution for this system, espe-cially if f2 is a linear function. The practical consequences of this will be outlined forthe dynamic model of the Beaver aircraft in section 3.4.The resulting state-space model can be used for any rigid body, and in particularany rigid vehicle. Based on this model, we can develop dynamic simulation modelsof aircraft, missiles, spacecraft, road-vehicles, or ships, by identifying the relevantcontrol inputs and disturbances, and by further developing the equations (2.67) forthe forces and moments. In the next chapter, a dynamic model of the DeHavillandBeaver airplane will be built on this foundation.

Chapter 3

The aircraft model

Having determined the basic equations of motion, we can now develop a simulationmodel of the complete aircraft. This chapter will first outline the general structure ofthe overall simulation model, then focus on building the aircraft dynamics model byidentifying the individual contributions to the forces and moments and by buildingthe necessary airdata equations. Also, several additional observation variables willbe included, in order to make the model suitable for a wide range of applications inflight simulation, flight dynamics analysis, and flight control system design.

3.1 General structure of the flight simulation model

Figure 3.1 shows the general closed-loop model of an automatically controlled air-craft that is affected by external disturbances. Most elements in this model are hard-ware related: the airframe and powerplant determine the aircraft dynamics, the flightcontrol computer setup determines the discretization effects and computational de-lays, the actuator and sensor hardware determine which signals can be observed andwhat control inputs are physically possible, and the pilot interface limits the ways inwhich the pilot can interact with the control of the airplane and the autopilot. Themode-controller logic and the control laws of the flight control system are typicallydefined in software.

This chapter will focus on building the aircraft dynamics model, which obviouslyforms the core of figure 3.1. The next chapter deals with external atmospheric distur-bances, chapter 5 will include some relevant sensor and actuator models (focusingon the simulation of radio-navigation signals in particular), and chapter 14 will pro-vide a detailed example of an automatic flight control system and its mode-controllerfor the Beaver aircraft.

3.2 The nonlinear aircraft dynamics

Figure 3.2 gives a graphical overview of the nonlinear rigid body dynamics of anaircraft. Together, all elements from this figure represent the nonlinear state-spacesystem from equation (2.66). The state variables are obtained by integrating theirtime-derivatives with respect to time, taking into account the initial value of the state

28 Chapter 3. The aircraft model

Actuatordynamics

Aircraftdynamics

Sensordynamics

AFCScontrollaws

Discretizationeffects, compu-tational delay

Modecontroller h

hReference signals

External disturbances

Pilot-

interface

Figure 3.1: Block-diagram of an automatically controlled aircraft

vector, x0. In order to obtain the time-derivatives of the state variables the state va-riables are coupled back into the force and moment equations and the equations ofmotion themselves. All forces and moments must be expressed in components alongthe body-axes of the vehicle (denoted by the superscript B). Forces and momentswhich are expressed with respect to other reference frames must be transformed tobody-axes components by pre-multiplying the force and moment vectors with theappropriate transformation matrix. In the figure, this is illustrated for the aerody-namic forces and moments, which are transferred from flight-path axes (superscriptW) to body-axes, and for the gravitational forces, which are transferred from Earthaxes (superscript E) to body-axes. Figure 3.2 forms the basis for the development ofthe modular structure of the rigid body equations for the FDC toolbox.

3.3 External forces and moments

The next step in the development of the dynamic model is to identify the differentcontributions to the external forces and moments acting upon the rigid body. Obvi-ously these contributions are dependent of the type of vehicle under consideration.For the Beaver model we will consider forces and moments due to gravitational,propulsive, and aerodynamic effects, plus the influence of nonsteady atmosphere.This comprises an in-flight model of a conventional aircraft. Other contributions caneasily be included to the model, e.g. ground forces during taxiing, or a ground-effectmodel for aircraft that fly close to the ground. Figure 3.2 shows the individual con-tributions to the total external forces and moments; the dashed box represents addi-tional factors that are not taken into account in this report.

3.3.1 Aerodynamic Forces & Moments

The aerodynamic forces and moments depend upon the flight condition, defined bythe state vector x and the aircraft configuration (i.e. the position of movable elements

3.3. External forces and moments 29

Aer

odyn

amic

s

Pro

puls

ion

Gra

vity

Win

dC

orre

ctio

ns

Atm

osph

ere/

Aird

ata

-

6

- - ---j j

- --j

TW→

B

TE→

B

∑- -

Equ

atio

nsof

Mot

ion

x=

f(x

,F

tot,

Mto

t)

∫dt

-x

x

FB to

t

MB to

t

FB ae

ro

MB ae

ro

FW ae

ro

MW ae

ro

FB p

rop

MB p

rop

FE g

rav

FB g

rav

FB w

ind

uae

ro

up

rop

uw

ind

q dy

n,

M,..

.

--

--

-

-

--

Figure 3.2: Block-diagram of the general rigid body dynamics


on the airplane). For the DHC-2 Beaver aircraft, a sophisticated aerodynamic modelhas been determined from flight tests in 1988 [34]. This model expresses the aero-dynamic forces and moments along the aircraft’s body-axes in terms of polynomialfunctions of the aircraft states, the time-derivative of the state vector, and the flightcontrol inputs:

Faero = d · p1 (x, x, uaero) (3.1)

where Faero is a vector of aerodynamic forces and moments, and p1 is a polynomialvector-function that yields non-dimensional force and moment coefficients. The in-put vector uaero gathers the positions of the elevator, ailerons, and rudder (the pri-mary flight controls for the Beaver), and flaps (the secondary flight controls). For theBeaver model, the x-term is linear and only takes into account the direct contribu-tion of β to the aerodynamic side-force Ya. The pre-multiplication with the diagonal-matrix d converts these non-dimensional coefficients to dimensional forces and mo-ments; d equals:

d = qdynS · diag ([ 1 1 1 b c b ]) (3.2)

S is the wing-area of the aircraft, b is the wing-span, c is the mean aerodynamic chord,and qdyn is the dynamic pressure (qdyn = 1

2 ρV2, see section 3.5).

The polynomial functions from p1, describing the aerodynamic force and momentcoefficients in the body-fixed reference frame are:

CXa = CX0 + CXα α + CXα2 α2 + CX

α3 α3 + CXq

qcV

+ CXδrδr + CXδ f

δ f + CXαδ fαδ f

CYa = CY0 + CYββ + CYp

p b2V

+ CYr

rb2V

+ CYδaδa + CYδr

δr + CYδrαδrα + CYβ

βb2V

CZa = CZ0 + CZα α + CZα3 α3 + CZq

qcV

+ CZδeδe + CZ

δe β2 δeβ2 + CZδ fδ f + CZαδ f

αδ f

Cla = Cl0 + Clββ + Clp

p b2V

+ Clrrb2V

+ Clδaδa + Clδr

δr + Clδaαδaα

Cma = Cm0 + Cmα α + Cmα2 α2 + Cmq

qcV

+ Cmδeδe + Cm

β2 β2 + Cmr

rb2V

+ Cmδ fδ f

Cna = Cn0 + Cnββ + Cnp

p b2V

+ Cnr

rb2V

+ Cnδaδa + Cnδr

δr + Cnq

qcV

+ Cnβ3 β3

(3.3)

The stability and control coefficients from these polynomial equations are constantfor the entire flight-envelope of the Beaver; table B.3 in appendix B lists their values.

Notice the cross-coupling between lateral motions and longitudinal forces and mo-ments. For example, the gyroscopical effect of the propeller can be recognized inthe factors Cmr

rb2V and Cnq

qcV . According to table B.3, Cmr is negative, which means

that positive yawing (i.e. to the right) also causes a pitch-down moment due to thegyroscopical precession of the propeller; Cnq is positive, which means that pitching-up also causes the aircraft to yaw to the right. This is consistent with a clockwise-rotating propeller, which indeed corresponds to the lay-out of the Beaver engine.

Also notice the contribution of β to the aerodynamic side-force Ya, which explainswhy the time-derivative x appears on the right-hand side of the general polynomialequation (3.1). Due to this phenomenon the state equation (2.66) becomes implicit.

3.3. External forces and moments 31

In general such relationships are assumed to be linear, similar to the Beaver modelshown here, which makes it easy to re-write the state equations as a set of explicitODEs. This will be outlined for the Beaver aircraft in section 3.4. Table B.5 in ap-pendix B presents the inertia data on which the aerodynamic model was been based;corrections to the body-axes moments will be necessary if a different position of thecenter of gravity is used, see ref.[34].

3.3.2 Engine Forces & Moments

The propulsive forces and moments also strongly depend upon the type of aircraftunder consideration. For a piston-engined aircraft like the Beaver, the primary en-gine control inputs are the engine speed n, and the manifold pressure pz, whichdirectly affect the engine power P. The engine power also varies with altitude dueto changes in air-density. If the propeller is represented as an ideal pulling disc, it ispossible to express changes in engine power and airspeed in terms of variations ofthe non-dimensional pressure increase in the propeller slipstream dpt [34]:

dpt ≡ ∆pt12 ρV2

= C1 + C2

(P

12 ρV3

)(3.4)

The constants C1 and C2 have been given in ref [34]: C1 = 0.08696, and C2 = 191.18.P

12 ρV3 is measured in [kW kg−1 s3]. For the Beaver aircraft, the engine power in [kW]

can be calculated with the following expression1:

P = 0.7355− 326.5 + (0.00412 (pz + 7.4)(n + 2010) +

+ (n + 2010) + (408.0− 0.0965 n)(

1.0− ρ

ρ0

))(3.5)

where:

pz = manifold pressure [′′Hg],n = engine speed [RPM],ρ = air-density [kg m−3],ρ0 = air-density at sea level = 1.225 [kg m−3].

The engine forces and moments, which include propeller slipstream effects, are writ-ten as polynomial functions of x and dpt in a similar way as the aerodynamic mo-del [34]:

Fprop = d · p2 (x, dpt) (3.6)

where the subscript prop denotes propulsive effects. The vector function p2 containsthe polynomials for the non-dimensional propulsive force and moment coefficients;

1The factor 0.7355 converts from continental horse-power to kilowatt; this factor was used in severalother software packages from the Faculty of Aerospace Engineering of Delft University of Technology(DUT), including the software that was used to control the engineering flight simulator of the Facultyduring the 1980’s and early 1990’s. However, according to ref.[34], the conversion should be frombrake horse power to kilowatt, which would require a factor of 0.7457 instead. Since it is not knownwhether ref.[34] or the software is correct, it was decided not to correct the discrepancy, in order toensure that simulations created with the FDC toolbox could be directly compared to those obtained byother programs at DUT. If the conversion factor in equation (3.5) is incorrect, the engine power is infact underestimated by 1.4%, which is deemed acceptable.


the actual forces and moments are again obtained by pre-multiplication with thevector d, see equation (3.2). The polynomial functions gathered in p2, which describethe propulsive force and moment coefficients in the body-fixed reference frame are:

CXp = CXdptdpt + CXα dpt2

α dpt2

CYp = 0

CZp = CZdptdpt

Clp = Clα2dpt

α2dpt

Cmp = Cmdptdpt

Cnp = Cndpt3dpt3 (3.7)

Table B.4 in appendix B lists the values of the stability and control coefficients fromthese polynomial equations. These coefficients are constant over the entire flightenvelope of the Beaver.

3.3.3 Gravitational forces

The weight of the aircraft equals the aircraft’s mass m times the local acceleration ofgravity g. It is directed along the positive ZV axis (see the definition of the vehicle-centered vertical reference system FV in section A.7.1 of appendix A):

FVgrav = WV = mgV = mg ·

001

V

(3.8)

In this equation, the superscript V has been used to denote the applied referenceframe FV . Using the transformation:

FBgrav = TV→B FV

grav (3.9)

where the transformation matrix is TV→B defined according to equation (A.4) fromappendix A, we find the following equation for the gravity force components alongthe aircraft’s body-axes:

Fgrav =

XgrYgrZgr

= mg ·

− sin θcos θ sin ϕcos θ cos ϕ

(3.10)

In this equation, g is the magnitude of the local acceleration of gravity, θ is the pitchangle of the vehicle, and ϕ is the roll angle of the vehicle. The superscript B has beenomitted here for reasons of brevity. Obviously, the attitude of the vehicle, expressedin terms of the Euler angles θ and ϕ needs to be known to be able to determine theweight components along the body-axes; see section A.7.3 for the relevant defini-tions.

3.3.4 Forces and moments due to nonsteady atmosphere

In section 2.3 it was shown that corrections to the external force components alongthe aircraft’s body-axes are needed whenever the aircraft is flying in nonsteady at-

3.4. Converting the implicit state equations to explicit equations 33

mosphere. These corrections are equal to:

Fwind =

XwYwZw

= −m ·

uw + qww − rvwvw − pww + ruwww + pvw − quw

(3.11)

3.4 Converting the implicit state equations to explicit equations

As explained in section 2.5, it is possible that the external forces and moments de-pend upon time-derivatives of state variables. This causes the general state equa-tions (2.66) to become implicit, which results in the equation (2.69). In the case ofthe Beaver model, the aerodynamic sideforce was shown to be dependent on thetime-derivative of the sideslip angle:


p b2V

+ CYr

rb2V

+ CYδaδa + CYδr

δr + CYδrαδrα + CYβ

βb2V

(3.12)

Notice the last term in this equation. The time-derivative of the sideslip angle wasgiven by equation (2.48):

β =1

Vm(−Fx cos α sin β + Fy cos β− Fz sin α sin β

)+ p sin α− r cos α (3.13)

which shows that β depends on the sideforce Fy, which includes the aerodynamiccontribution Ya = 1

2 ρV2S CYa . As a consequence, the time-derivative β appears onboth sides of equation (3.13).

Using these raw relations in a simulation model would result in a so-called algebraicloop. Although such loops can be solved numerically by means of an iterative process,as illustrated in section 6.4.1, this is not desirable in practice, because the increasednumber of computations would severely slow down simulations. A better solutionis to search for an algebraic solution instead.

In this particular case, it is easy to re-write the β-equation such that it becomesexplicit. First of all, the contribution of β to the side-force Fy can be written as aseparate term:

β =1

Vm

(− Fx cos α sin β + Fy

∗ cos β− Fz sin α sin β + 12 ρV2S CYβ

βb2V cos β

)+


where Fy∗ is the side-force without the contribution of β. The β-term on the right hand

side of this equation can easily be moved to the left-hand side:

β∗ ≡ β

(1− ρSb

4mCYβ

cos β

)=

=1

Vm(−Fx cos α sin β + Fy

∗ cos β− Fz sin α sin β)+ p sin α− r cos α (3.15)

Based upon these equations the following calculation sequence can be used in thesimulation model:

1. compute the external forces and moments as usual, but neglect the contributionof β to the aerodynamic side-force for the time being,


2. substitute the thus obtained forces and moments into the general β equation,to obtain the value β∗, and

3. compute the true value of β with the expression β = β∗(

1− ρSb4m CYβ

cos β)−1

.

Since the last step ‘corrects’ the originally computed value β∗ to obtain the actualvalue of β, the multiplication factor from step 3 represents a correction term. Thecorrection is aircraft-dependent because it contains CYβ

, whereas the equation for β∗

itself is applicable to all aircraft. Thus, the computation scheme allows us to sepa-rate the aircraft-dependent from the aircraft-independent terms, which is desirablein view of the intended standardization of aircraft models.

3.5 Atmosphere and airdata variables

So far, the aerodynamic and propulsive forces and moments were expressed in termsof non-dimensional force coefficients, but to solve the equations of motion, we needto know their actual values. For the Beaver aircraft, this requires knowledge of thedynamic pressure. Other aircraft models often also take into account compressibi-lity effects, which would require additional knowledge of the Mach number, andsometimes it may be necessary to account for scale-effects (e.g. in case of windtunnel-derived models) which would require knowledge of the Reynolds number as well.

These variables are closely related to the properties of the atmosphere, and theairspeed and altitude of the aircraft. Several related variables are needed to comparesimulations with flight test measurements or windtunnel experiments; these varia-bles also play an important role for aircraft instrumentation. In this report, thesevariables are referred to as ‘atmosphere and airdata variables’, or shortly ‘airdata va-riables’. Several airdata equations have been included in the aircraft model to allowthe model to be used for a wide range of applications.

The airdata variables depend upon atmospheric properties such as the air pressure,density, and temperature. Here we use the ICAO Standard Atmosphere model (seefor instance refs.[5] or [30]) to determine these properties. According to this model,the air temperature T decreases linearly with increasing altitude in the troposphere,i.e. at altitudes from zero to 11,000 meters above sea level:

T = T0 + λh (3.16)

where:

h = altitude above sea level [m],T0 = air temperature at sea level = 288.15 [K],λ = temperature gradient in troposphere = −0.0065 [Km−1].

The air pressure depends upon the altitude, according the basic hydrostatic equation:

dps = −ρ g dh (3.17)

We assume that the ideal gas law can be applied to the air in the atmosphere:ps

ρ=

Ra

MaT (3.18)

3.5. Atmosphere and airdata variables 35

where:

Ra = molar gas constant = 8314.32 [JK−1kmol−1],Ma = molecular weight of the air [kg kmol−1].

Combining these equations and neglecting the altitude-dependency of the gravita-tional acceleration g yields:

dps

ps= − Ma g0

RaTdh (3.19)

where:

ps = static air pressure, [Nm−2],g0 = gravitational acceleration at sea level = 9.80665 [ms−2].

To find ps, equation (3.19) needs to be integrated, yielding:

ln(

ps

p0

)= − g

λRln(

T0 + λhT0

)(3.20)

This equation can be written as:

ps

p0=(

1 +λhT0

)− gλR

=(

T0

T

) gλR

(3.21)

R is the specific gas constant, which is defined as:

R ≡ Ra

M0

(3.18)=

p0

ρ0T0= 287.05 [JK−1kg−1] (3.22)

and:

p0 = air pressure at sea level = 101325 [Nm−2],ρ0 = air density at sea level = 1.225 [kg m−3],M0 = molecular weight of the air at sea level = 28.9644 [kg kmol−1].

Since the gravitational acceleration g was held constant during the integration ofequation (3.19), this actually means that the geometrical altitude h in this equationmust be replaced by the geopotential altitude H.1 In this report the slight distinctionbetween h and H will be neglected, in view of the relatively low altitudes considered.In order to remind us of this small inaccuracy, the symbol H will be used in theremainder of the report to denote the altitude.

Contrary to the pressure equation (3.21), where the acceleration g was assumedto be equal to g0 for all altitudes, the model does take into account changes in gwith altitude for the computation of the aircraft’s weight. The actual gravitationalacceleration is then computed with the following equation, which is valid for a roundEarth:

g = g0

(REarth

REarth + h

)2

(3.23)

where:

REarth = radius of the Earth = 6371020 [m]

1

The geopotential altitude H is defined as: H ≡∫ h

0

gg0

dh


The air density ρ (in [kgm−3]) is calculated from ps and T by means of the ideal gaslaw (3.18), which yields:

ρ =ps Ma

RaT=

ps

RT(3.24)

The aerodynamic and propulsive forces and moments that act upon the aircraft arefunctions of the dynamic pressure qdyn, which takes into account changes in airspeedand changes in air density:

qdyn ≡ 12 ρV2 (3.25)

This term originates from Bernoulli’s law, which states that the sum of the staticpressure ps and the dynamic pressure qdyn is constant:

pt ≡ ps + qdyn = constant (3.26)

where pt is the ‘total pressure’, which is the pressure in a point where the air isbrought to a complete standstill (this pressure can be measured in the so-called ‘stag-nation point’ of a pitot tube). However, this only applies for incompressible currents,which in practice means that this law can only be applied for slow aircraft, like theBeaver. As a guideline, Bernoulli’s law is usually applied only for airspeeds up to100 ms−1.

For aircraft flying at higher airspeeds it is necessary to take into account the com-pressibility of the air, which causes the air density to vary from one location to thenext. In this case, the energy law for adiabatic flow of an ideal gas is used [5]:

γ

γ− 1pρ

+ 12 V2 = constant (3.27)

where γ = CpCv

is the ratio of the specific heats of a gas with constant pressure (Cp)and constant volume (Cv), respectively. For air, γ equals 1.4. It can be shown that thepressure and density of an isentropic flow are related as follows:

ps

ργ= constant (3.28)

If we now define the ‘total conditions’ to be the pressure and density where the flowis brought to rest isentropically1, we find:

pt

ps=(

ρt

ρ

)γ

=(

Tt

T

) γγ−1

(3.29)

Applying equation (3.27), the total pressure for a compressible airflow is thus foundto be:

pt = ps

(1 +

γ− 12γ

ρ

psV2) γ

γ−1

(3.30)

It is possible to re-write this relation using the Mach number M, which is defined asthe ratio of the speed of the airflow to the speed of sound:

M =Va

(3.31)

1In an isentropic process, a gas is compressed and/or expanded gradually enough for the processto be reversible, which implies that its entropy does not change.

3.5. Atmosphere and airdata variables 37

where V is the (local) airspeed and a is the speed of sound (in [ms−1]):

a =√

γRT (3.32)

The Mach number is an important property that appears in many of the isentropicflow equations; it is also used as main control variable for the velocity of jet aircraftat high altitudes. Substituting these relations in equation (3.30) yields:

pt = ps

(1 +

γ− 12

M2) γ

γ−1

(3.33)

Notice that equations (3.30) and (3.33) are only valid for Mach numbers smaller thanone, as they are based on the assumption of isentropic behaviour. If the aircraft fliesat supersonic speeds, shockwaves appear over which the air pressure, temperature,and density rise abruptly, causing the process to become irreversible. In that case,the isentropic relations are no longer valid and the flow is governed by supersonicshock relations, which go beyond the scope of this report.

For the Beaver aircraft it is not necessary to take into account these compressibi-lity effects, although it can still be quite useful to know the value of the Mach number.For instance, if one wants to compare flight-test results with the simulations it is use-ful to compute the Mach-dependent ‘impact pressure’ qc and total temperature Ttsince those quantities can be measured in flight. The impact pressure is defined asthe total pressure minus the static pressure:

qc = pt − ps (3.34)

where pt is determined by equation (3.30) or (3.33), whichever is more convenient.The impact pressure is the equivalent of the dynamic pressure from Bernoulli’s equa-tion (3.26), except in this case the compressibility of the flow is taken into account.It can be measured using a pitot static system that subtracts the static pressure fromthe total pressure that is measured in the stagnation point of the pitot tube.

The total air temperature Tt is the temperature that is measured when air isbrought to rest isentropically. This measured temperature is higher than the tem-perature that would be measured when the air is completely in rest (relative to thetemperature sensor):

Tt = T(

1 +γ− 1

2M2)

(3.35)

Other important variables are the calibrated and equivalent airspeeds Vc and Ve, whichare determined by the equations:

Vc =

√√√√ 2γ

γ− 1p0

ρ0

(1 +

qc

p0

) γ−1γ

− 1

(3.36)

Ve = V√

ρ

ρ0=

√2qdyn

ρ0(3.37)

Equation (3.36) can be derived easily from equations (3.34) and (3.30), by substitut-ing the conditions at sea level for ρ and ps. This relation is often used to calibratethe airspeed indicators in the cockpit; the true airspeed differs from the indicatedairspeed due to the calibration for sea level conditions, hence the terminology. The


‘equivalent airspeed’ does the same assuming that the airflow is incompressible. Ex-pression (3.37) is used to calibrate less sophisticated flight instruments that can befound in light aircraft that operate in airspeed regions where compressibility of theair is negligible.

As explained earlier, it may also be necessary sometimes to take into account scaleeffects, e.g. if the aerodynamic model is determined by windtunnel measurements,using a scale model. In that case, the Reynolds number needs to be known. Oftenthe Reynolds number is related to the mean aerodynamic chord c, which yields thenon-dimensional value:

Rc =ρVc

µ(3.38)

It is also possible to use the Reynolds number per unit length (in [m−1]), whichequals:

Re =ρVµ

(3.39)

In equations (3.38) and (3.39), µ is the coefficient of the dynamic viscosity, which canbe calculated with the equation of Sutherland:

µ =1.458 · 10−6 T

32

T + 110.4(3.40)

From all variables mentioned in this paragraph, only p, T, ρ, and qdyn really mustbe calculated in order to be able to solve the equations of motion for the Beaverairplane. However, the other airdata (-related) variables may be useful for manyanalytical purposes and some of them will be needed to solve equations of motionwhen a different aerodynamic model that takes into account compressibility and/orscale effects would be used instead.

Although the current list of atmosphere and airdata equations is quite compre-hensive, it is by no means complete: expanding the flight-envelope beyond the tro-posphere (i.e. to altitudes above 11,000 meters) and beyond the speed of sound willrequire additional modifications to the equations for pressure, density, and tempera-ture. For more information, refer to ref. [5] or other books about aircraft instrumen-tation.

3.6 Additional observation variables

In the previous paragraph we have obtained a list of state variables, time-derivativesof the state variables, forces and moments, atmospheric variables, and airdata varia-bles. It is possible to enhance this list with a large number of additional output va-riables. Here we will include additional normalized kinematic accelerations, specificforces, body-axes velocity rates and some flight-path (-related) variables, but the listcan easily be expanded if required.

3.6.1 Body-axes velocity rates

For educational purposes, it may be useful to take a closer look at the components ofthe aircraft’s acceleration along its body-axes. These body-axes ‘velocity rates’ u, v,

3.6. Additional observation variables 39

and w are equal to:

u =Fx

m− qw + rv

v =Fy

m+ pw− ru (3.41)

w =Fz

m− pv + qu

In section 2.2 it was explained that the true airspeed V, angle of attack α, and sideslipangle β were better suitable as state variables than the body-axes velocity compo-nents u, v, and w. This is why equations (3.41) have been implemented as additionaloutput equations, rather than state equations.

3.6.2 Kinematic accelerations and specific forces

It is possible to calculate accelerations and outputs from accelerometers, which maybe useful for post-flight analysis or required for certain flight control tasks. A typicalexample of the latter is a turn-coordination system that is based on a feedback-loop ofthe acceleration along the YB axis. Also, these signals may be useful for applicationsin the field of manoeuvre load limiting. The aircraft model from the FDC-toolboxconsiders accelerations in the vehicle’s center of gravity only, but equations for posi-tions outside the center of gravity can easily be included if necessary. See ref.[14] forthe required transformations.

The body-axis acceleration vector a can be expressed as:

a = V =∂V∂t

+ Ω×V (3.42)

where Ω is the rotational velocity vector of the aircraft. Expanding this equationinto its components along the body-axes and substituting for u, v, and w – see equa-tion (3.41) – yields:

ax,k =1g0

(u + qw− rv) =Fx

W

ay,k =1g0

(v + ru− pw) =Fy

W(3.43)

az,k =1g0

(w + pv− qu) =Fz

W

The difference between the kinematic accelerations and u, v, and w is the inclusion ofadditional angular and translational velocity cross-product terms. In addition, con-trary to equations (3.41), the kinematic accelerations have been measured in unitsof g, which explains the division by g0. W = m g is the total weight of the aircraft,measured in N. The index k denotes that these variables represent kinematic accelera-tions in the body-fixed reference frame.

The outputs of accelerometers which are oriented along the body-axes, and lo-cated in the vehicle’s center of gravity are equal to the kinematic body accelerations


minus the gravity terms:

Ax = ax,k + sin θ = (Fx − Xgr) / WAy = ay,k − cos θ sin ϕ = (Fy −Ygr) / WAz = az,k + cos θ cos ϕ = (Fz − Zgr) / W

(3.44)

Ax, Ay, and Az are measured in units of g. These accelerations represent what wouldactually be felt by a pilot when he would be located at the aircraft’s center of gravity;they are usually called specific forces.

3.6.3 Flight-path related variables

To determine the flight-path of the aircraft, it is useful to introduce some additionalobservation variables. First of all, the flight-path angle γ is computed, using thefollowing expression:

γ = arcsin(

HV

)(3.45)

This angle is, for instance, useful during approach simulations where it determineshow much the aircraft deviates from the standard glide-path. The acceleration in thedirection of the velocity vector V, measured in units of [g], is called the flight-pathacceleration fpa. It is equal to:

fpa =√

u2 + v2 + w2

g0=

Vg0

(3.46)

Other flight-path related variables are the azimuth angle χ and the bank angle Φ,which are obtained with the following equations [30]:

χ = β + ψ (3.47)Φ = arcsin

(sin ϕ sin(90 − θ)

)= arcsin

(sin ϕ cos θ

)(3.48)

See also the description of the flight-path or wind reference frame FW in appendix A,section A.7.3.

3.7 Summary

To recapitulate: we have completed the state-space model of the rigid body dynam-ics, described in section 2.5, by developing models for the aerodynamic, propulsive,and gravitational forces and moments, correcting the force factors for nonsteady at-mosphere, and determining some atmosphere and airdata variables that are requiredto compute these forces and moments.

All elements combined result in the mathematical model from figure 3.2. This mo-del was enhanced with several useful output equations, including additional airdataparameters, acceleration quantities, and flight-path variables. The resulting systemof equations completes the block ‘Aircraft dynamics’ from figure 3.1; the other ele-ments from that figure will be explored in the next chapters.

The model comprises twelve states and 77 additional output variables (includingsome interim results from the computations, such as force and moment coefficients,and time-derivatives of the states). These variables have been listed in table D.2,

3.7. Summary 41

which can be found appendix E. The input variables to this model are the controlsurface deflections, which affect the aerodynamic forces and moments, and the en-gine inputs, which affect the propulsive forces and moments. In addition, wind ve-locity components and rates enter the model as external disturbances; these signalsare used to determine the force-corrections for nonsteady atmosphere. An overviewof these input variables can be found in table D.3 in appendix E.

Chapter 4

External atmospheric disturbances

In this chapter, we will take a closer look at the unsteady nature of the atmosphere,which affects the motions of the airplane and its flight-path in relation to the ground.Some basic models of wind and turbulence will be presented in a format that willallow easy adaptation in the SIMULINK environment. The wind velocity will be rep-resented by deterministic functions, while the atmospheric turbulence will be mod-elled by means of stochastic functions.

It is not intended to provide a comprehensive description of the entire atmos-phere here, nor will this report provide complete and detailed derivations of thewind and turbulence models. Instead, the focus of this chapter is to present someuseful models aimed at practical applications, such as the analysis and fine-tuningof flight control system performance under nonsteady atmospheric conditions. Ex-amples of such tasks are the simulation of automatic approaches under varying windconditions, the assessment of attitude controllers in turbulent weather, and the devel-opment of gust alleviation control laws to improve the ride quality or reduce struc-tural loads in the airframe.

4.1 Deterministic disturbances

The velocity and direction of the mean wind with respect to the ground usually is notconstant along the flight-path. This variation of the mean wind along the flight-pathis called windshear.1 The influence of windshear upon the motions of the aircraft isof particular importance during the final approach and landing, and during take-offand initial climb.

An idealized profile of the mean wind as a function of height above the groundhas been shown in figure 4.1. Much more extreme wind profiles in lower atmospherehave been recorded; some data from actual measurements in lower atmosphere canbe found in ref.[1]. A very dangerous type of windshear is encountered in so-calledmicrobursts: large pockets of air moving rapidly downwards to the ground in thun-derstorms. An aircraft flying through a microburst can be faced with a sudden in-crease in headwind, followed by a severe downdraft that is immediately followedby a sudden increase in tailwind, all within a matter of seconds. Such conditions

1In some textbooks the term ‘windshear’ is used to denote the local variations of the wind andturbulence with respect to the ground. In this report turbulence will be considered separately.

44 Chapter 4. External atmospheric disturbances

0 0.5 1 1.5 2 2.5 30

50

100

150

200

250

300

350

400

450

500

Vw

m/s[ ]

H [

]

m

Figure 4.1: Wind profile for λ = −0.0065 Km−1 and Vw 9.15 = 1 ms−1

may exceed the aerodynamic and propulsive performance of airplanes, causing theaircraft to loose lift and altitude, which can be very hazardous at low altitudes.

One of the best researched accidents involving a microburst was the June 24, 1975crash of Eastern Air Lines Flight 66 during final approach to John F. Kennedy airportin New York. Figure 4.2 shows the reconstructed wind profile and the recorded flight-path of this airplane. Based on this data, numerical models of two-dimensional flow-patterns for thunderstorms have been developed [11]; such models are often used forflight crew training in flightsimulators. Although this subject will not be explored infurther detail in this report, it is useful to acknowledge the hazards of such extremeweather conditions, and to realize that the idealized wind model that will be pre-sented next will not always be sufficient; for some purposes, it may be necessaryto apply additional models, or even measurements of actual wind velocities duringextreme weather conditions. However, that goes beyond the current scope of thisreport.

The atmosphere model used in section 3.5 was based on the ICAO standard atmos-phere model, which is characterized by a standard temperature lapse-rate λ = dT/dH =−0.0065 Km−1; see for instance ref.[30] for more details. The following equations rep-resent a typical idealized windspeed profile that is valid for this particular value ofthe temperature lapse-rate [1]:

Vw = Vw 9.15

H0.2545 − 0.40971.3470

(0 < h < 300m)

Vw = 2.86585 Vw9.15 (h ≥ 300m)(4.1)

Vw 9.15 is the windspeed at an altitude of 9.15 m (approximately 30 ft, which is a com-monly used reference height for meteorological experiments). The wind profile in

4.1. Deterministic disturbances 45

Downburst

Outburst

Runway

25 sec

30

35

40

50

20:05 UTC 00 sec

10 11.4 sec: firstground contact

05

55

Sea

win

d fr

ont

Glideslope

250

200

150

100

50

0

-3000 -2000 -1000

Hei

gh

t [

]

Distance from threshold [ ]

m

m

Figure 4.2: Microburst wind pattern that caused the crash of Eastern flight 66

figure 4.1 is based upon a value Vw 9.15 = 1 ms−1. Ref.[1] presents some alternativewind profiles, which are typical for other values of the temperature lapse rate.

In sections 2.3 and 3.3.4, we described how the influence of the wind on the motionsof the airplane can be expressed in terms of correction terms for the external forcecomponents in the body-fixed reference frame. If we know the wind velocity relativeto the Earth, we can obtain the components of the wind along the aircraft’s body-axesusing the following axes transformation:

VBw = TE→B ·VE

w (4.2)

where Vw represents the wind vector, the superscript B represents the aircraft’s bodyaxes, and the superscript E represents the Earth axes. TE→B is the transformationmatrix from Earth to body axes, which involves the three consecutive Euler rotationsshown in figure A.2 in appendix A:

TE→B ≡ TV→B = TΦ · TΘ · TΨ (4.3)

This transformation has been written out in more detail in equation (A.4) of appen-dix A.

In practice, wind is usually not given in terms of velocity component along the Earthaxes, but rather in terms of windspeed and wind direction. The first represents themagnitude of the windspeed vector, and the latter represents the direction on thecompass rose from where the wind emanates; for instance, ‘northerly wind’ meansthat the wind is blowing from the north. This notation does not take into accountvertical wind components, because such vertical windspeeds are often short-lived,whereas the horizontal wind pattern is usually much more steady.


If Vwhor is the horizontal wind velocity and ψw is the wind direction, the horizontalwind velocity components in the Earth axes are equal to:

uEw = Vwhor · cos(ψw − π)

vEw = Vwhor · sin(ψw − π) (4.4)

For sake of completeness, we will also introduce the ‘vertical wind direction’ angleγw, for cases where the wind also has a vertical component; this angle is positivewhen the wind is blowing upwards. Using that angle, the horizontal wind velocityis found to be:

Vwhor = Vw · cos γw (4.5)

In this generalized situation, the vertical wind velocity component can be non-zero:

wEw = −Vw · sin γw (4.6)

where the minus sign reflects the fact that the ZE points downwards.Equations (4.3) to (4.6) can be used to model a steady wind pattern, while equa-

tion (4.1) can be used to describe the changing wind velocity in the Earth’s boundarylayer. Notice however, that the horizontal wind direction ψw will normally also varywith height. The above given representation of the vertical wind component may bepracticable for modelling microburst wind patterns like the one shown in figure 4.2,but for most other purposes the vertical windspeed can simply be neglected (i.e. γwcan be kept identical zero).

4.2 Stochastic disturbances

Atmospheric turbulence is often regarded to be a ‘random’ process. This is actually abit misleading, because the evolution of turbulent flows are governed by the generalNavier-Stokes equations (a set of deterministic, nonlinear, coupled partial differen-tial equations), even when the creation of an eddy out of an instability somewhere inthe flow field is a matter of ‘chance’ [27]. However, the theory of stochastic processesdoes provide a convenient means to describe the atmospheric turbulence velocitiesfor the types of simulation problems considered in this report (e.g. the assessment ofhandling characteristics of the airplane or the performance of automatic flight con-trol systems).

4.2.1 Stochastic properties of atmospheric turbulence

Auto power density spectra form the basic elements of the stochastic turbulence mo-del. In the literature, several sets of these spectra can be found. They all require theselection of intensity levels and scale lengths before they can be applied in simula-tions. In order to simplify the statistical equations as far as practicable, the stochas-tical processes describing atmospheric turbulence are usually assumed to have thefollowing six restrictive characteristics [1, 27]:

1. Normality, which means that the probability density function of each turbu-lence velocity component is Gaussian. As a consequence of this assumption,the covariance matrix alone provides sufficient information for a complete sta-tistical description of the atmospheric turbulence.

4.2. Stochastic disturbances 47

2. Stationarity, which deals with temporal properties of turbulence. If the statis-tical properties of a process are not affected by a shift in the time origin, thisprocess is called stationary.

3. Taylor’s hypothesis of a ‘frozen atmosphere’, which implies that gust veloci-ties are functions of the position in the atmosphere only. This hypothesis al-lows spatial correlation functions and frequencies to be related to correlationfunctions and frequencies in the time-domain.

4. Homogeneity, which deals with the spatial properties of turbulence. Turbu-lence may be called homogeneous if its statistical properties are not affected bya spatial translation of the reference frame.

5. Ergodicity, which means that time averages in the process are equal to cor-responding ensemble averages. This condition follows from the previous as-sumptions of the turbulence being stationary and homogeneous. As a conse-quence, all required statistical properties related to a given set of atmosphericconditions can be determined from a single time history of sufficient length.

6. Isotropy, which means that the statistical properties are not changed by a rota-tion or a deflection of the frame of reference. Complete isotropy implies homo-geneity. Because of isotropy, the three mean-square velocity components andtheir scale lengths are equal:

σu2 = σv

2 = σw2 ≡ σ2

Lu = Lv = Lw ≡ Lg(4.7)

Experimental data on atmospheric turbulence shows that these assumptions are notalways satisfied [1, 27]. There is some evidence that atmospheric turbulence is notnecessarily normal, and while the observed departures from a normal amplitudedistribution are small, pilots seem to be quite sensitive to these effects. Actual atmos-pheric turbulence possesses what is sometimes called a ‘patchy’ structure [1].

Taylor’s hypothesis seems to be valid as long as the aircraft’s velocity is large rel-ative to the encountered turbulence velocity. For this reason it is somewhat doubtfulthat the hypothesis is fully valid when simulating the final approach and landingof S/VTOL aircraft, i.e. aircraft which can fly at very low airspeeds, and which areable to take off and land vertically (Vertical Take-Off and Landing) or using only avery short runway (Short Take-Off and Landing). This includes the DeHavillandDHC-2 Beaver aircraft, which served as the example vehicle for the aircraft modelfrom chapter 3.

The assumptions of homogeneity and isotropy appear not to be very valid inthe vicinity of the ground (i.e. within the Earth’s boundary layer). Near the ground,there are fairly rapid changes in turbulence velocity with altitude, induced by verti-cal windshear, which is closely related to the shape and roughness of the terrain. Theassumption of stationarity is satisfied only over short periods of time during whichthe meteorological conditions remain reasonably constant, and is also affected by theshape and roughness of the ground surface.

However, for many practical applications these six assumptions seem to be quite rea-sonable, which is why these simplifications will all be maintained for the derivationsin the next sections. It is always possible to enhance these models in the future, if


Dryden

Von Kármán

AΩS( )

S(0)

ΩLg

1

.1

.01

Dryden

Von Kármán

BΩS( )

S(0)

ΩLg

1

.1

.01

1.1 10 1.1 10

Figure 4.3: Von Kármán and Dryden spectra (A: longitudinal, B: lateral/vertical)

a more accurate description of the atmospheric turbulence is required, e.g. for de-tailed analysis of the final approach and landing. Alternatively, it is also possible toinsert actual measurements of atmospheric turbulence velocities into the simulationmodels.

4.2.2 Power spectra of atmospheric turbulence

Due to the simplifications we have made in the previous section, it is possible todistinguish between two fundamental correlation functions: the correlation betweenvelocities parallel to a connecting line between two points in space, and the correla-tion between velocities normal to this connecting line. The first function is termed‘longitudinal correlation’, the second ‘lateral correlation’.

Several authors have obtained analytical power spectral density functions forthe turbulence velocities, using measured data. The Von Kármán spectral densityfunctions seem to best fit the available theoretical and experimental data on atmos-pheric turbulence, particularly at higher spatial frequencies [27]. Analogous to thecorrelation functions, these spectra can also be divided in ‘longitudinal’ and ‘lateral’functions. Applying those functions to the turbulence velocity components in theaircraft’s body-axes yields:

Sugug(Ω) = 2σu2Lu

1

(1 + (1.339 LuΩ)2)56

(4.8)

Svgvg(Ω) = σv2Lv

1 + 83 (1.339LvΩ)2

(1 + (1.339 LvΩ)2)116

(4.9)

Swgwg(Ω) = σw2Lw

1 + 83 (1.339LwΩ)2

(1 + (1.339 LwΩ)2)116

(4.10)

where Sugug represents the longitudinal Von Kármán spectrum, while Svgvg and Swgwg

are both instances of the lateral Von Kármán spectrum.1 The cross spectral density

1Some textbooks may use a scaled version of these spectra, due to the application of a different def-inition for the Fourier transform (the partition of the constant 1

2π may differ). However, an agreementon the correlation functions exists, because they originate from measured wind velocities.


functions are zero in isotropic turbulence at any point in space. Although this ap-proximation is not very valid at low altitudes, the cross covariances – and hence, thecross power spectral densities – are usually neglected [19].

The von Kármán spectra yield an asymptotic behaviour of S(Ω) ∼ Ω−5/3 as Ω ap-proaches infinity. This condition is imposed by the rate at which the most energeticeddies of turbulence loose their kinetic energy: this energy is not immediately lost toviscosity, but instead it is transferred to smaller eddies, which in turn transfer theirenergy to yet smaller eddies, and so on.

A major drawback of the von Kármán spectral densities is that they are not ra-tional functions of Ω, which greatly complicates analysis and computations for anyapplication. To overcome this problem, the simplified Dryden spectral density func-tions were introduced:

Sugug(Ω) = 2σu2Lu

11 + (ΩLu)2 (4.11)

Svgvg(Ω) = σv2Lv

1 + 3(ΩLv)2

(1 + (ΩLv)2)2 (4.12)

Swgwg(Ω) = σw2Lw

1 + 3(ΩLw)2

(1 + (ΩLw)2)2 (4.13)

In figure 4.3 typical Dryden spectral density values have been compared with theVon Kármán functions. The most obvious difference is the asymptotic behaviourat large values of the spatial frequency, the former having a slope of − 5

3 and thelatter a slope of −2. Although the Von Kármán form seems to fit the experimentaldata somewhat better, both representations yield much the same results for aircraftresponses.

4.2.3 Filter design for atmospheric turbulence

For simulation purposes it would be practical to model atmospheric turbulence aswhite noise passing through a linear, rational ‘forming filter’, as shown in figure 4.4.The relationship between the auto-spectral density of the output signal y and theauto-spectral density of the input signal u of a linear filter can be written as:

Syy(ω) = |Hyu(ω)|2Suu(ω) (4.14)

where |Hyu(ω)| denotes the amplitude response of the filter. If the input signal u iswhite noise, its spectral density satisfies:

Suu(ω) = 1 (4.15)

so for white noise, relation (4.14) simplifies to:

Syy(ω) = |Hyu(ω)|2 (4.16)

Unfiltered white noise

Turbulence velocity (‘coloured noise') Linear Filter

(Dryden)

Figure 4.4: Modelling atmospheric turbulence as filtered white noise


To apply these relations, the spatial spectral density functions of the turbulence ve-locities must be transformed to functions of the circular frequency ω. This can bedone, because Taylor’s hypothesis implies that the circular frequency ω [rad s−1] en-countered at the aircraft’s center of gravity is related directly to the spatial frequencyΩ [rad m−1]:

ω = ΩV (4.17)

The resulting transformation is given by:

S(ω) =1V

S (Ω) (4.18)

The extra term 1/V in the spectral density function is due to the fact that we nowintegrate over the time instead of over the distance in the Fourier transform.

The Dryden spectra were developed to approximate the von Kármán turbulencespectra by means of rational functions. This makes it possible to apply relation (4.18)for the generation of turbulence velocity components from white noise inputs. Fromthe definitions of the Dryden spectra in equations (4.11) to (4.13) and relation (4.18)the following expressions are found:

|Hugw1(ω)|2 = 2σu2 Lu

V1

1 +(

LuωV

)2 (4.19)

|Hvgw2(ω)|2 = σv2 Lv

V1 + 3

(Lv

ωV

)2(1 +

(Lv

ωV

)2)2 (4.20)

|Hwgw3(ω)|2 = σw2 Lw

V1 + 3

(Lw

ωV

)2(1 +

(Lw

ωV

)2)2 (4.21)

Solving equations (4.19) to (4.21) yields the following candidate functions for thefrequency responses of the forming filters:

Hugw1(ω) = σu

√2Lu

V1

1± LuV jω

(4.22)

Hvgw2(ω) = σv

√Lv

V1±

√3 Lv

V jω(1± Lv

V jω)2 (4.23)

Hwgw3(ω) = σw

√Lw

V1±

√3 Lw

V jω(1± Lw

V jω)2 (4.24)

In these equations w1, w2, and w3 are independent white noise signals. Choosing theminus sign in the denominators would lead to unstable filters and hence should berejected for physical reasons. And choosing the minus sign in the numerators leadsto non-minimum phase systems, so we shall use positive signs in both the numeratorand denominator [27].

The Laplace transforms H(s) are obtained by replacing the imaginary variable iωby the more general complex variable s, and the resulting transfer functions can sub-sequently be converted to state-space systems using the technique from section 6.4.2.


0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.80

50

100

150

200

250

300

350

400

450

500

0

0.151

0.235

0.245

0.210

0.145

0.068

0.318

0.363

0.456

0.538

0.565

0.560

0.508

0.382

0.229

0.0825

0.662

0.666

0.681

0.690

0.688

0.670

0.620

0.506

0.307

0.123

I

II III

[

]H

m

Vw9.15

σwg [ - ]

Figure 4.5: Standard deviation of vertical turbulence velocity as a function of altitude, givenfor three different temperature lapse rates. Curve I: dT

dH = 0.003 C m−1, curve II:dTdH = 0.0065 C m−1, curve III: dT

dH ≥ 0.01 C m−1.

This representation of the Dryden filters is very suitable for implementation in asimulation package like SIMULINK. If the white noise is approximated by a sequenceof Gaussian distributed random numbers, it is easy to determine the time-trajectoriesof the turbulence velocity components. It is important to ensure that these randomsequences are completely independent, which may not be obvious if the simulationsoftware uses some initial starting value or ‘seed’ for its random-generator.

Better approximations of the Von Kármán turbulence spectra can be obtained byusing a series of additional lead-lag networks, adding differentiating and integratingterms to the basic first-order Dryden filters. Although the resulting equations will bemore complicated than the Dryden equations, the resulting functions will still remainrational. A detailed discussion of this technique can be found in ref.[1].

4.2.4 Turbulence intensity and scale

In the power spectral density functions from the previous sections, the turbulencescale was represented by the scale-lengths Lu, Lv, and Lw, while the turbulence inten-


0 50 100 150 200 250 300 3500

50

100

150

200

250

300

350

400

450

500

48

44

42

38

35

33

26

9

160

158

156

152

149

145

139

108

69

18

300

301

305

310

315

326

329

284

161

36

H

m[

]

[ ]L mw

I

II III

Figure 4.6: Scale of (longitudinal) turbulence as a function of altitude, given for threedifferent temperature lapse rates. Curve I: dT

dH ≤ 0.005 C m−1, curve II:0.005 < dT

dH < 0.01 C m−1, curve III: dTdH ≥ 0.01 C m−1.

sity was represented by the standard deviations σu, σv, and σw. If the turbulence fieldis assumed to be isotropic, the scale lengths can all be replaced by a single length Lg,and the standard deviation factors can be replaced by a single factor σg, but this isnot necessarily true for lower altitudes.

The standard deviation of the vertical gust velocity σw was experimentally foundto be a function of height, atmospheric stability (as expressed by the temperaturelapse rate), wind velocity, and a terrain factor. Since the latter influence appears tobe relatively small and the available data show a large scatter, the wind velocity asa function of the altitude, and the atmospheric stability appear to be the primaryfactors in determining turbulence intensity. With wind profiles for the boundarylayer of the atmosphere experimentally determined at different atmospheric stabili-ties (see e.g. figure 4.1 for the standard temperature lapse rate λ = −0.0065 K m−1),the standard deviation of atmospheric turbulence turns out to be dependent on thewindspeed at a certain reference height (usually 9.15 m, or 30 ft), and the temperaturelapse rate λ.

Figure 4.5 presents the standard deviation σw in relation to the windspeed at9.15 m, as a function of the height above the ground. The standard deviations for


the other directions are equal to σw if the turbulence is isotropic. For lower altitudes,ref.[19] presents the following relations for all stability conditions of the atmosphere,based on the analysis of data from measurements:

σu

σw=

σv

σw= 2.5 0 m ≤ h < 15 m

σu

σw=

σv

σw= 1.25− 0.001h 15 m ≤ h < 250 m (4.25)

σu

σw=

σv

σw= 1 h > 250 m

The scale of the turbulence is represented by the scale length Lg, which also dependson the height above the ground and the temperature lapse rate. This has been shownin figure 4.6.

It can be concluded that the structure of the turbulence at low altitudes can be de-scribed completely by examining the figures 4.5 and 4.6, given the windspeed at thereference height of 9.15 m and the temperature lapse-rate λ for the lower atmosphere.In practice, this is mainly relevant for the simulation of final approach and landing.For higher altitudes, typical values are σg = 1 m s−1 and Lg = 300 m.

Chapter 5

Radio-navigation, sensors, actuators

The previous chapters provide a solid basis for the construction of a simulation mo-del of the aircraft and its working environment. This model allows us to extract allincorporated flight data without any restrictions, which is very useful for the analysisof flight dynamics and which allows us to build elaborate control systems. However,it should be noted that this transparency is actually an idealised representation ofreality.

In real flight, the relevant flight data is obtained through a limited array of sen-sors of limited accuracy and bandwidth. Some data can only be obtained indirectly;for instance, signals emitted by radio-navigation beacons on the ground are oftenused to derive the position of the airplane. Similarly, control inputs made by the(auto-) pilot do not represent the actual control surface deflections, as there is a sys-tem of cables and actuators (again of limited accuracy and bandwidth) in between.

In short: we have to take into account the interface between the aircraft and theflight-deck. This chapter will provide a starting point by presenting some additionalmodels, primarily focussing on the mathematical representation of radio-navigationsystems that are still commonly used for approach guidance and short-range navi-gation. At the end of the chapter, a short overview about additional sensor models,actuator models, and other navigation equipment will be given, thus identifyingroom for future expansion of the model library (and this documentation).

5.1 The Instrument Landing System

The Instrument Landing System (ILS) has been the standard aid for non-visual preci-sion approaches to landing since the 1940’s, and is still being used worldwide. Undercertain circumstances it can provide guidance data of such integrity that fully coup-led approaches and landings may be achieved. The system, which is ground-based,broadcasts very precise directional signals, providing a lateral and vertical path tothe runway up to a distance of approximately 40 kilometers from the runway.

The system comprises three distinct parts of on-ground equipment: (i) the local-izer transmitter, which gives guidance in the horizontal plane, (ii) the glideslope (orglide-path) transmitter, which provides vertical guidance, and (iii) one, two, or threemarker beacons situated on the approach line, which serve as checkpoints for thepilot to verify the distance to the runway (these markers are increasingly often being

56 Chapter 5. Radio-navigation, sensors, actuators

xloc

xgs

ygs

RunwayLocalizerantenna

Glideslopeantenna

Landingdirection

Figure 5.1: Positioning of ILS ground equipment

3.9 NM3000 ft

Localizertransmitter

Join glide-pathand commencefinal descent

Runway

Glide-pathtransmitter

Alt. 300 ft

Alt. 1200 ft

Aircrafttrack

Alt. 2500 ft

Middle marker

Outermarker

Figure 5.2: Lay-out of the approach path

replaced by the use of distance measuring equipment for direct distance-to-thresholdmeasurements). In this section we will analyze the localizer and glideslope signalsin more detail.

5.1.1 Nominal ILS signals

Figures 5.1 and 5.2 show the lay-out of the ILS ground equipment and the approachpath. The localizer signal is emitted by an antenna, situated beyond the up-wind endof the runway. Operating at a frequency within the 108.0 to 112 MHz frequency band,it radiates a signal modulated by 90 and 150 Hz tones, in which 90 Hz predominatesto the left-hand side of the approach path and 150 Hz predominates to the right, asseen from an aircraft flying on final approach course. Figure 5.3 shows the requiredminimum coverage of the localizer signals according to ICAO guidelines [2].

The glideslope antenna is located some 300 meters beyond the runway threshold(approximately adjacent to the touch-down point) and at about 120 to 150 m fromthe runway centerline. The frequency of the glideslope signal lies within the 328.6 to

5.1. The Instrument Landing System 57

Front beam area Back beam area

Runway

10 N

M

17 NM

25 NM

10o

35o

35o

10o

Localizertransmitter

Figure 5.3: Required coverage of localizer signal

Idealized glide-path(straight line)

Actual glide-path(hyperbola) Conical

surface

Glide-pathantenna

Localizerplane

Figure 5.4: Hyperbolic intersection of localizer and glideslope reference planes


8o

8o

10 NM

Glideslopetransmitter Localizer

transmitter

Runway

Figure 5.5: Required coverage of glideslope signal compared to localizer coverage

335.0 MHz band. The signal is modulated by 90 and 150 MHz tones, in which 90 Hzis predominant above the desired glide-path and 150 Hz dominates below the glide-path. Due to the position of the glideslope antenna, the intersection of the localizerreference plane and the glideslope reference cone is actually a hyperbola which islocated a small distance above the idealized straight glide-path. This is shown infigure 5.4. The minimum coverage of the glideslope signals, required by ICAO [2] isshown in figure 5.5.

An ILS installation is said to belong to a certain performance category, represent-ing the meteorological conditions under which it is to be used. These conditionshave been summarized in figure 5.6. An ILS installation of category I is intended toprovide guidance down to an altitude of 200 ft, a category II installation providesguidance down to 100 ft, and an installation of category III must provide guidancedown to the runway surface. Only cat. III signals can be used for fully automaticlandings. If the aircraft is making an approach under cat. I conditions, the pilotshould either see the runway lights at an altitude of 200 ft or cancel the final ap-proach and go-around.1

The localizer and glideslope signals are received on board the aircraft and displayedin an appropriate form to the pilot. In addition, these signals may be fed directly toan automatic pilot for automatic localizer and glideslope tracking. The nominal ILSsignals on board the aircraft are expressed in terms of the currents which are suppliedto the pilot’s cockpit instrument.

The magnitude of the localizer current iloc is proportional to the localizer devia-tion angle Γloc, shown in figures 5.7 and 5.8, while the glideslope current igs is propor-tional to the glideslope deviation angle εgs, shown in figure 5.8. From these figures,

1The altitude at which the runway lights should be visible is called the decision altitude or decisionheight. Some states and some individual airlines require larger values for the decision height than thenumbers shown in figure 5.6. Local circumstances, such as special terrain features or radio-interferencepatterns, may also dictate higher minimums.


-

-

?

?

?

?

?? ?0

100

200

1000 800 600 400 200 50 0

Cat. I

Cat. II

Cat. III

A B C

Runway visual range [m] →

↑

Decisionheight [ft]

Cat. I : Operation down to minima of 200 ft decision height and runway visual rangeof 800 m with a high probability of approach success

Cat. II : Operation down to minima below 200 ft decision height and runway visualrange of 800 m, and as low as 100 ft decision height and runway visual range of400 m with a high probability of approach success

Cat. III A: Operation down to and along the surface of the runway, with external visualreference during the final phase of the landing down to runway visual rangeminima of 200 m

Cat. III B: Operation to and along the surface of the runway and taxiways with visibilitysufficient only for visual taxiing comparable to runway visual range in the orderof 50 m

Cat. III C: Operation to and along the surface of the runway and taxiways without exter-nal visual reference

Figure 5.6: ILS performance categories

we can deduce that Γloc is defined as the the angle between the localizer referenceplane and a vertical plane that passes through the localizer antenna, and εgs is theangle between the reference glidepath and the line that connects the aircraft to theglideslope antenna. Since these angles are supposed to remain zero during the fi-nal approach, we will call them ‘localizer deviation angle’ and ‘glideslope deviationangle’, respectively.

For the simulation of ILS-approaches, we will use the runway-fixed referenceframe FRW , which has been defined in appendix A. At time t = 0 the position ofthe aircraft’s center of gravity coincides with the origin of the Earth-fixed referenceframe FE, hence, at that moment xe = 0, ye = 0, and H = H0. The position of theorigin ORW of the runway-fixed reference frame is defined by the coordinates xt andyt, measured relatively to the Earth-fixed reference frame, and the altitude of therunway above sea level, Ht (the index t denotes the runway threshold).

The horizontal relation between FRW and FE has been shown in figure 5.7. The ver-tical relation has been depicted in figure 5.9, using the intermediate reference framesF′E = O′

EX′EY′

EZ′E and F′′E = O′′

EX′′EY′′

E Z′′E to help interpret the spatial orientation. F′E


has the same orientation as FE, but its origin has been moved to the projection pointof ORW on the horizontal plane at sea level. F′′E has the same orientation as F′E, exceptits origin has been shifted to runway level. Hence:

x′′e = x′e = xe − xt (5.1)x′′e = y′e = ye − yt (5.2)

We can express the position of the aircraft relatively to the runway by introducingthe coordinates x f and y f , measured in the runway-fixed reference frame FRW (theindex f denotes ‘flight’), and the height of the airplane above the runway threshold,H f . Observing figures 5.7, 5.8, and 5.9, and substituting equations 5.1 and 5.2, wefind the following transformations from FE to FRW :

x f = (xe − xt) cos ψRW + (ye − yt) sin ψRW (5.3)y f = −(xe − xt) sin ψRW + (ye − yt) cos ψRW (5.4)

H f = H − Ht (5.5)where ψRW is the heading of the runway, measured relatively to the North, H is thealtitude of the airplane, and Ht is the elevation of the runway threshold. The lattertwo variables are both referenced to sea level.

As can be seen from figure 5.7, Γloc can be computed from the coordinates x f andy f as follows:

Rloc =√

y f2 + (xloc − x f )2

dloc = y f

Γloc = arcsin

(dloc

Rloc

)(5.6)

Γloc and dloc are positive if the aircraft flies at the right-hand side of the localizer ref-erence plane, heading toward the runway. The localizer current through the cockpitinstrument equals:

iloc = Sloc Γloc [µA] (5.7)where Sloc is the sensitivity of the localizer system. According to ref.[2], Sloc has tosatisfy the following equation:

Sloc = 1.40 xloc [µA rad−1] (5.8)where xloc is the distance from the localizer antenna to the runway threshold, shownin figure 5.2. All distances are measured in [m], and all angles must be measured in[rad]. The maximum value of the localizer current iloc is limited to ±150 µA, hence±150 µA represents a full-scale deflection on the cockpit instrument [2].

The locations which provide a constant glideslope current lie on a cone, as shown infigure 5.4. The nominal glide path has an elevation angle γgs which normally has avalue between −2 and −4. Obviously γgs is negative since the aircraft will descendalong the glide path. The magnitude of the glideslope current is proportional to theglideslope deviation angle εgs [rad] (see figure 5.8):

igs = Sgs εgs [µA] (5.9)Full-scale deflection on the cockpit instrument is again obtained at the limiting val-ues of the glideslope current igs = ±150 µA, see ref.[2]. Sgs is the sensitivity of theglideslope system, which equals:

Sgs =625|γgs|

[µA rad−1] (5.10)


Runway

Position ofaircraft’s c.g.at t = 0

Localizerantenna

xloc

xf (-)d

= y

loc

f(+

) XRW

X"E

XE

Y"EYRW

YE

Γloc

(+)

R loc

ΨRW

Figure 5.7: Localizer geometry and definition of X′E, Y′

E, XRW , and YRW-axes

gsγ (-)

gs(+

)ε

gs

d(+

)

ygs(-)

XRW

YRW

ZRW

Runway

yf (+)

Rgs

fx(-)

x(+)

gsHf

Glideslopeantenna

gsΓ (+)

Figure 5.8: Glideslope geometry and definition of XRW , YRW , and ZRW-axes


Runway

Sea level

North

ψR

W

ψ RW

yf

xf

Hf

H

Ht

y"e x"

e

YRW

RWX

Y’E

X’E

EZ’ ,

RWZ

EZ" ,

Y"E

X"E

Nominal glidepath

Figure 5.9: ILS geometry: expressing the aircraft position in the runway-fixed referenceframe and the intermediate (Earth-fixed) coordinate systems F′E and F′′E . Noticethat the airplane in the picture is turning to the right after a missed approach; thisposition corresponds with positive values of the x f and y f coordinates!

From figure 5.8 it can be seen that the deviation angle εgs can be computed fromthe coordinates x f and y f and the height above the runway, H f , using the followingexpressions:

Rgs =√

(xgs − x f )2 + (y f − ygs)2 (5.11)

εgs = γgs + arctan(

H f

Rgs

)(5.12)

The distance from the aircraft to the nominal glideslope is:

dgs = (Rgs tan γgs + H f ) cos γgs (5.13)

In these expressions εgs and dgs are positive if the aircraft flies above the glideslopereference line. Notice that γgs is always negative!


Performance categoryof the ILS system

Maximum deviationfrom nominal localizer

sensitivity [%]

Maximum deviation oflocalizer runway reference

plane from centerline atrunway threshold [m]

I ± 17 ± 10.5

II ± 17 ± 7.5(± 10 where practicable) (± 4.5 for new installations)

III ± 10 ± 3

Table 5.1: Maximum permissible localizer steady-state errors

Performance categoryof the ILS system

Maximum deviationfrom nominal glideslope

sensitivity [%]

Maximum deviation fromnominal glideslopeelevation angle [rad]

I ± 25 ± 0.075 γgs

II ± 20 ± 0.075 γgs

III ± 10 ± 0.04 γgs

Table 5.2: Maximum permissible glideslope steady-state errors

In order to be able to verify whether the aircraft flies in the glideslope coverage area(figure 5.5), we will also calculate the angle Γgs:

Γgs = arcsin(

y f − ygs

Rgs

)(5.14)

Due to the lateral position of the glideslope antenna this angle is not exactly equal toΓloc, although the differences are small.

5.1.2 Steady-state ILS offset errors and ILS noise

ICAO has established limits for ILS steady-state offset errors introduced by groundequipment. For obvious reasons, these limits are most stringent for category III ap-proaches. Tables 5.1 and 5.2 provide these limits for the localizer and glideslope trans-mitters, respectively. The nominal glide path must pass over the runway thresholdat an altitude of 15± 3 m.

Due to interference effects caused by buildings, high voltage cables, etc., the ac-tual ILS signals can become distorted in the spatial and time domains. To an ap-


proaching aircraft, these distortions appear as noise in the time-domain, superim-posed on the nominal ILS signals. Based on available experimental data, localizerand glideslope noise may be approximated by stochastic signals which have rathersimple power spectral density functions.

Refs.[1] and [19] present power spectra for ILS noise, which are expressed in thesame general form as the Dryden model for longitudinal atmospheric turbulence,see equation (4.11). The power spectral density function for localizer noise can beapproximated by: 1

Sloc(Ω) = 2σloc2Lloc

11 + (ΩLloc)2

[µA2rad−1m

](5.15)

where:

σloc = standard deviation of the localizer noise,Lloc = ‘scale’ of the localizer noise, approximately 130 mΩ = spatial frequency [rad m−1]

The power spectral density of the glide path noise appears to be similar to the local-izer noise and may be approximated by:

Sgs(Ω) = 2σgs2Lgs

11 + (ΩLgs)2

[µA2rad−1m

](5.16)

where:

σgs = standard deviation of the glideslope noise,Lgs = ‘scale’ of the glideslope noise, approximately 85 mΩ = spatial frequency [rad m−1]

For atmospheric turbulence it is often assumed that the turbulence velocities are func-tions only of the position in the atmosphere (the frozen field concept or Taylor’s hy-pothesis). This assumption can be made because aircraft usually fly at large speedscompared to turbulence velocities.

Using Taylor’s hypothesis for the ILS noise will probably introduce errors, es-pecially for aircraft with very low final approach speeds such as the Beaver. Still,this assumption makes it possible to convert the spatial power spectral density func-tions to temporal expressions in ω, which can be used for practical simulations. Oneshould remember that the power spectral density functions are in any case approxi-mations of the actual ILS noise, so if a really accurate representation of ILS noise isrequired for simulations (e.g. for assessing automatic cat. III landing systems) an ac-tual calibration of the localizer and glideslope signals for the site in question shouldbe used.

1Note: the expressions for ILS noise and atmospheric turbulence given in refs.[1] and [19] have anadditional term π in the denominator. The Dryden spectra from ref.[27] do not contain this term, dueto a slightly different definition of the Fourier transform. In this report, the definition of the Drydenfilters from ref.[27] has been used, and due to the similarity of the expressions for ILS noise the term πwill be omitted here too. See also the footnote on page 48.

The definitions of the Fourier transform and the inverse Fourier transform used in ref.[27] are:

X(ω) = Fx(t) =∫ ∞

−∞x(t)e−jωt dt; x(t) = F−1X(ω) =

12π

∫ ∞

−∞X(ω)ejωt dω


Distance to threshold, [m]741010506000-600

2.5

5

7.5

10

15

σ

µΑ

gs

loc

[ ]

(cat. III)

σσloc

gsσ

gsσ

σ loc

σloc

(cat. II, III)

(cat. I)

(cat.

II, II

I)(cat. I)

,

Figure 5.10: Maximum allowable ILS localizer and glideslope noise

With Taylor’s hypothesis it is possible to substitute ω = ΩV. Then the ILS noise canbe modelled as a white-noise signal which is sent through a linear forming filter inthe same way as the derivations for atmospheric turbulence shown in figure 4.4. Theresulting filters are:

Hloc(ω) = σloc

√2Lloc

V1

1 + LlocV jω

(5.17)

Hgs(ω) = σgs

√2Lgs

V1

1 + LgsV jω

(5.18)

Alternative shapes of the power spectral density functions for localizer and glide-slope noise are given in ref.[22]. These expressions were based upon average powerspectral density plots of beam noise, observed at several airports:

Sloc = |Hloc(ω)|2 =25 (1.5 + jω)2

(0.35 + jω)2(10 + jω)2

[µA2rad−1s

](5.19)

Sgs = |Hgs(ω)|2 =15.9

(0.25 + jω)2

[µA2rad−1s

](5.20)

The filters for these spectral density functions are:

Hloc(ω) = ± 5 (1.5 + jω)(0.35 + jω)(10 + jω)

(5.21)

Hgs(ω) = ± 3.98750.25 + jω

(5.22)

Both ILS noise models have been implemented in the FDC toolbox. The maximumallowable values of the standard deviations of localizer and glideslope noise, accord-ing to ICAO standards [2] have been given in figure 5.10.


In addition to the ILS noise and steady-state errors, specific deterministic interfer-ence patterns may occur due to signal reflections from aircraft in the vicinity of theglideslope and/or localizer transmitters. These disturbances may be quite severeand should be taken into account for the evaluation of automatic landing systems. Itis possible to construct relatively simple models of these interference effects, but thatgoes beyond the scope of this report. Ref.[1] provides more details about these typesof disturbances.

5.2 The VOR navigation system

Another radio-navigation system that is still commonly used today is the Very-highfrequency Omnidirectional Radio-range (VOR) system. The system was developedafter World War II, and has become the backbone of the air navigational systemsince the 1950’s. It provided more accurate signals than the Low-Frequency beaconsused at that time (the LF Non-Directional Beacon or NDB system is still in use today,mainly to augment instrument approach and departure procedures), and it was lessprone to interference from thunderstorms.

Distance measuring equipment (DME) was added to many VOR transmitters andreceivers, allowing the distance between the station and the aircraft to be shown inthe cockpit. The VOR system can be used for navigating between airports, follow-ing so-called ‘airways’, and it can also be used for final approach guidance if thepilot flies along a reference VOR bearing to the runway, using a timed descent oran altitude-versus-distance table (the latter procedure requires both VOR and DMEsignals).

However, unlike the ILS system, the VOR system is considered a non-precisionlanding aid, because it is not accurate enough and does not provide enough informa-tion to allow a pilot to land. Because of this, VOR/DME approaches require consid-erably higher minimum values of visibility and cloud-ceiling than ILS approaches.

5.2.1 Nominal VOR signals

The VOR system uses the 108-118 MHz frequency radio range (VHF). The VORground station radiates a cardioid pattern that rotates 30 times per second, gener-ating a 30 Hz sine wave at the output of the airborne VOR receiver. The groundstation also radiates an omnidirectional signal which is modulated with a 30 Hz ref-erence tone. The phase difference between the two 30 Hz tones is a function of thebearing of the aircraft, relatively to the VOR ground station.

A position fix can be obtained by using two or more VOR beacons, or by probingthe signal from a single beacon at two different points in time and space. In practice,however, a position fix is usually obtained by using bearing information from theVOR system and distance information from a DME station that is co-located withthe VOR transmitter. More detailed technical information about these systems canbe found in refs.[5], [7], and [23]; here we will mainly focus on the VOR navigationgeometry.

The geometry of the VOR system has been shown in figure 5.11. Simple general-aviation VOR systems make it possible for the pilot to fly along a reference VOR

5.2. The VOR navigation system 67

VOR antenna

CD

QDR

(north)E X

yVOR

ye

xe

xV

OR

VO

R

R

VOR Γ

ψ

(east)E Y

ReferenceVOR radial

Figure 5.11: Geometry of VOR navigation

radial, that can be entered using an ‘Omni Bearing Selector’. The reference bearingis called ‘Course Datum’ (CD), while the bearing on which the aircraft is actuallyflying is denoted by QDR (a term used in radio telephony). The course deviationangle ΓVOR, which is equal to the angle between the reference bearing and the actualbearing, is shown on the cockpit instrument; a typical value for a full-scale deflectionis ΓVOR = 10.

The bearing information can also be coupled to an automatic control system, al-lowing the airplane to automatically fly from or to the VOR along a reference radial,or to automatically intercept a VOR bearing. Although many autopilots still offersuch functionality today, modern airliners and business aircraft normally have moreadvanced Area Navigation systems which use information of multiple VOR stationsand other navigation equipment to follow arbitrary routes between arbitrary way-points. In this report we will consider tracking of VOR radials only.


In order to compute VOR signals for simulation purposes we need to know the exactpositions of the VOR station and the aircraft in relation to the Earth-fixed referenceframe. If the horizontal position of the VOR ground station is defined by the coor-dinates (xVOR, yVOR) and the horizontal position of the aircraft by (xe, ye), we canfind the following equations for the QDR and the course deviation angle ΓVOR (seefigure 5.11):

QDR = arctan(

ye − yVOR

xe − xVOR

)(5.23)

ΓVOR = CD −QDR (5.24)

We also need to know whether the aircraft flies toward the VOR beacon, or awayfrom it. This information is visualized in the cockpit by means of a ‘TO-FROM indi-cator’, which verifies the difference between the airplane’s heading ψ and the QDR:

|ψ−QDR| > 90 ⇒ ‘TO’ (5.25)|ψ−QDR| < 90 ⇒ ‘FROM’

(In figure 5.11 we can observe that the aircraft is flying away from the VOR beacon.This corresponds with the above given relations since ψ − QDR ≈ 40, which isindeed smaller than 90.)

5.2.2 VOR coverage and the Cone of Silence

The ground distance RVOR can be used to determine whether the aircraft flies inan area where the VOR signals can be received with appropriate reliability. Thisdistance is equal to:

RVOR =√

(xe − xVOR)2 + (ye − yVOR)2 (5.26)

If the aircraft flies in a certain area in the direct neighbourhood of the VOR transmit-ter, the signals are not accurate. This area is formed by a cone with a top-angle ofapproximately 80 to 120 degrees, the so-called Cone of Silence, which has been shownin figure 5.12. The aircraft flies outside the cone of silence if [5]:

ξ ≡ arctan(

H − HVOR

RVOR

)≤ 90 − (40 to 60) (5.27)

where H is the altitude of the aircraft and HVOR is the elevation of the VOR station.These altitudes are expressed in [m] above sea level; H − HVOR represents the heightof the airplane above the VOR station.

Table 5.3 gives the maximum coverage of the VOR signals as a function of theheight above ground level, measured in two different flight tests [7]. Using the MAT-LAB function POLYFIT to fit a polynomial to the data from this table, the followingapproximative function for the VOR coverage as a function of the altitude (expressedin meters, contrary to table 5.3 itself!) was found:

Range = 1000(− 2.3570 · 10−6 (H − HVOR)2 +

+ 5.7087 · 10−2 (H − HVOR) + 80.8612)

(5.28)

5.2. The VOR navigation system 69

Cone of Silence

VOR antenna

40 to 60o o

40 to 60

o

o

ξ

DM

E

R

VORR

H -

HV

OR

Figure 5.12: The ‘Cone of Silence’

Another, more generally accepted, rule-of-thumb to determine the coverage of aVOR station is [5]:

Range = 1.2(√

h +√

hVOR

)(5.29)

where Range expresses the VOR coverage in nautical miles, h is the height of theaircraft above the ground, measured in [ft] (this differs from equation (5.28), whichexpressed the altitude in meters above sea-level!), and hVOR is the height of the VORstation above the ground, also measured in [ft]. The latter term is often neglected.

5.2.3 VOR accuracy

The nominal VOR signals become distorted by VOR noise and steady-state errors.There are two types of systematic errors: ground station errors and airborne equip-ment errors. Each of these errors comprises both the equipment and antenna errorsand site or location errors. ICAO has established the following rules [2, 7]:

1. the error of the airborne equipment must be smaller than ±2 at a distancefrom the antenna of four times the wavelength and at an elevation-angle of 0

to 40, and

2. the maximum error for the ground station is ±3.5.


Height [ft] VOR range [NM]

1000 505000 9220000 18230000 220

3000 755000 95

Table 5.3: VOR coverage based on two different flight tests [7]

Ref.[7] presents some data about ground equipment errors, obtained from actualmeasurements. According to this source, the steady-state errors typically lay some-where in the range from±1.4 to±2.5. There are also other errors of a more randomnature, which are caused by e.g. variations of supply voltage of the ground and/orairborne equipment, temperature changes, inaccurate instrument reading, etc. Flighttests using commercial aircraft yielded the following approximative values for over-all VOR system error [7]:

ε < ±1.7 (68% of the tests)ε < ±3.4 (95% of the tests)ε < ±5.1 (99.7% of the tests)

Since ref.[7] is already somewhat outdated, modern VOR stations and receivers maybe more accurate than these figures suggest.

5.3 Other flight navigation systems

The equations from the previous section allow us to create a simulation model ofan aircraft that is operated in a conventional air-traffic environment, using VOR andDME systems for guidance along airways, standard arrival routes, and standard de-parture routes. However, in modern air-traffic control environments, it has becomeincreasingly common to define ad-hoc flight-paths along great circles1 between fixed(sometimes arbitrary) waypoints, rather than fly along pre-determined airways, de-fined by VOR radials.

The geometric position of modern airliners is computed by the Flight Manage-ment System, using integrated information from DME stations (possibly VOR sta-tions), the Inertial Reference System (IRS) from the airplane, and sometimes alsonavigation information from Global Positioning System (GPS) satellites. In this set-up, the IRS usually offers short-term position information, which remains accurateeven when manoeuvring, while the radio and/or satellite navigation signals offerlonger-term position updates which nullify the long-term IRS drift.

1A great circle is a circle on the surface of a sphere (thus on the surface of the Earth or the celestialsphere) which is formed as the result of the inter-section of the sphere and a plane passing through thecenter of the sphere.

5.4. Sensors, Actuators, Flight Control Computer 71

In the foreseeable future, the ILS is likely to remain in use as the main precisionapproach system, even though in the late 1970’s ICAO declared the far superior Mi-crowave Landing System (MLS) to become the precision approach system for the21st century. In practice, the MLS has only been applied in a few specialized loca-tions where operational requirements dictated a need for a combination of precisionand accuracy that, at that time, only the MLS could provide. Nowadays it seemsmore likely that the role of the ILS will some day be taken over by satellite-basedlanding guidance systems. Precision approach guidance using GPS is already feasi-ble today.

It would go far beyond the current scope of this report to analyze these other navi-gation systems in detail. If modern navigation systems and practices are to be eval-uated in simulations, additional mathematical models will most likely be required.However, the general approach taken in the previous two sections could serve as amodel for the determination of the governing equations: start by defining the navi-gation geometry, and include systematic and random system errors thereafter. Itshould be noted that in flight simulations, we can always compute the exact posi-tion of the airplane; constructing a realistic model of a navigation system is thereforemainly a matter of obtaining a realistic error model.

5.4 Sensors, Actuators, Flight Control Computer

The mathematical model from chapter 3 allows us to compute the motions of theaircraft, resulting from applied control inputs and external disturbances. Althoughthe model includes many observation variables that make it suitable for many ap-plications in aircraft dynamics research and flight control system design, we needto take into account the difference between the actual values of these variables andthe values which are sensed and displayed on the cockpit instruments, or used forcomputations by the flight control computers of the airplane.

In addition, we must remember that this model is based on the actual deflectionsof control surfaces, which do not necessarily correspond to the intended control in-puts generated either directly by the pilot (using the flight controls in the cockpit),or indirectly via an automatic flight control system (using electric signals to definedeflections of actuators, which in turn move the control surfaces).

Both on the input and on the output side of the aircraft model, we may needto augment the equations by including additional system dynamics, deterministicerrors, stochastic errors, and data-processing influences. Whether or not such refine-ments are really necessary obviously depends on the required accuracy for specifictasks. For instance, while it may very well be possible to build a decent set of flightcontrol laws using the idealized equations from chapter 3, it is quite possible thatother effects such as sensor noise, actuator dynamics, and time-delays and quanti-zation effects caused by computer limitations may degrade system performance tosuch an extent that additional measures have to be taken.

A striking example of the potential detrimental effects of signal processing in adigital computer was encountered during the design of the Altitude Hold control lawfor the Beaver autopilot (see chapters 14 and 15): the altitude signal was representedwith a Least Significant Bit of approximately 4 feet, which would lay well within the


required accuracy, but which inadvertently caused the reference input to consist ofa series of 4 feet step-inputs. This resulted in unacceptable control characteristics;additional filtering of the altitude signal was required to solve the problem [28].

Since the Flight Dynamics and Control toolbox currently does not include a com-prehensive library of sensor and actuator models, despite their potential importancefor flight control system design tasks and flight simulation, this report will not fur-ther elaborate on this subject. However, the toolbox does take into account somespecific ad-hoc representations of time-delays, quantization effects, and actuator dy-namics to represent the Beaver autopilot; see the corresponding block-reference fordetails.

Chapter 6

Analytical tools

When developing the aircraft differential equations in chapter 2, much emphasis wasplaced on the state-space formulation for the aircraft differential equations. This for-mulation will prove to be especially suited for the implementation of the aircraftmodel in the SIMULINK environment, and the development and application of ana-lytical MATLAB and SIMULINK software tools.

Figure 6.1 shows the nonlinear state-space model of the aircraft and the asso-ciated analytical tools. The tools provide the capability to trim the aircraft modelfor steady-state flight, perform digital simulations, and derive linear state-space de-scriptions of the aircraft dynamics. Linear control system design techniques can beapplied to these linearized aircraft models, and the resulting control laws can be val-idated with nonlinear simulations. Notice how this figure corresponds to the upperpart of figure 1.3 from chapter 1, which depicted the flight control system designcycle in the FDC toolbox.

These analytical functions are mostly generic in nature, and SIMULINK and MAT-LAB include several built-in software tools to fulfil these functions. Although it isnot necessary (and often not possible) to know the exact algorithms used by thesebuilt-in tools, it is still useful to have at least a basic understanding of the underlyingtheory. For this purpose, this chapter provides an introduction to the theory of simu-lation (in particular: numerical integration), system linearisation, and some elementsfrom linear system analysis. It also introduces a specialized trimming algorithm, tai-lored to the nonlinear aircraft model.

6.1 Numerical integration methods

The aircraft equations of motion from chapter 2, which were further elaborated inchapter 3, express the aircraft dynamics in terms of a set of twelve nonlinear ordi-nary differential equations (ODEs). To ‘simulate’ aircraft responses to control inputs orexternal disturbances, we therefore need to solve an initial-value problem.

The FDC toolbox delegates this task to the built-in SIMULINK integrators, whichhave been documented in the MATLAB and SIMULINK user-manuals, refs. [3] and [4],and in ref.[32]. These documents can all be downloaded from www.mathworks.com. Asummary of the SIMULINK solvers will be given in chapter 11. Here, we will providegeneral background information about numerical integration of ODEs.

74 Chapter 6. Analytical tools

Initialisationdata

Coefficientdata

Steady-statetrim

Nonlinearsimulation

LineariseControlsystem

simulation

Lineardesign

techniques

Nonlinearstate-space model

x = f ( x , u , )( )t ( )t ( )t t.

y = g ( x , u , )( )t ( )t ( )t t

x = A x + B u( )t ( )t ( )t.

y = C x + D u( )t ( )t ( )t

Linear state-space model

Initialisation data

Trialdesign

Figure 6.1: State-space flight models and the associated analytical tools [33]

6.1.1 The type of problems considered

The numerical integration methods considered here are used to determine time-tra-jectories of state variables of continuous dynamical systems, which are characterizedby a set of coupled ODEs:

x(t) = f(x(t), u(t), v(t), t); x(t0) = x0 (6.1)

where x is the state vector, u is the input vector, v is a vector of external disturbances,f is some nonlinear function, and x0 is the initial value of the state vector at timet0. This equation represents a so-called initial value problem. Since few differentialequations can be solved exactly, it is usually necessary to approximate the solutionsof these ODEs numerically.

If the state vector x has N elements, N constants of integration appear in thesolution of equation (6.1). A unique solution to this system can be obtained onlyif the initial values of all states are specified. The techniques for solving the vectorequation (6.1) are essentially the same as the techniques used for solving scalar initialvalue problems given by the equation:

x(t) = f (x(t), t) (6.2)

in which we have omitted the input signal u(t) and the disturbances v(t) for sake ofbrevity; including the latter signals does not change the integration methods. Numer-

6.1. Numerical integration methods 75

x2x0

t0 t1 t2

Initial value

Euler solution

x

t

x1

t3

x3

Figure 6.2: Family of solutions of an unstable ODE. The Euler approximation from equa-tion (6.3) has been displayed graphically.

ical integrators generate a sequence of discrete points t0, t1, t2, . . . in time, possiblywith variable spacing hn = tn+1 − tn (the step-size). At each point tn the solutionx(tn) is approximated by xn, which is computed from earlier values of x. If k earliervalues xn, xn−1, . . . , xn−k+1 are used for the computation of xn+1, the method is calleda ‘k-step method’. For instance, the Euler method is a single-step method:

xn+1 = xn + hn · f (xn, tn) (6.3)

This method is used by the SIMULINK integrator ode1.

6.1.2 Stability, errors, and order of a numerical integration method

Figure 6.2 shows a typical family of solutions of a first-order differential equation fordifferent initial values x0. If we select a wrong value of the initial condition, the de-viation from the desired solution will increase in time, i.e. the differential equation isunstable. The figure demonstrates how the Euler approximation from equation (6.3)will cross from one solution to another between subsequent time steps, due to thenumerical inaccuracy. For this unstable differential equation, the resulting error isshown to increase in time.

Figure 6.3 shows a family of solutions for a stable differential equation. In thiscase, the solutions of the ODE converge as time proceeds, and numerical integrationerrors do not increase with time. Nonlinear differential equations may be unstable insome regions and stable in others. For multiple coupled ODEs, the situation will beeven more complex. One should always be aware of possible instabilities of dynamicsystems when assessing numerical results.

Numerical integration methods introduce two types of errors: discretisation er-rors and round-off errors. Discretisation errors are a property of the numerical inte-gration method, while round-off errors occur due to the finite number of digits usedin the calculations (hence they are a property of the computer and the program thatis used). In general, reducing the step-size hn will decrease the discretisation error.


x

t

Figure 6.3: Family of solutions of a stable ODE

hn

Total error

Discretisation

error

Round-off

error

Error

minhn

Min.

error

Figure 6.4: Discretisation error, round-off error, and total error as a function of step-size

The total error will also decrease with hn, until a point is reached where the round-offerror is starting to become dominant. This has been illustrated in figure 6.4.

These errors may cause the numerical solution to become unstable, even whenthe ODE itself is stable. An example of this numerical instability will be shown laterin figure 6.5, which demonstrates a system where the numerical error of the Eulermethod is amplified in each step.

The order of a numerical integration method is defined in terms of the local dis-cretisation error δn, obtained when the method is applied to problems with smoothsolutions. A method is said to be of order p if a number C exists so that:

|δn| ≤ Chnp+1 (6.4)


C may depend on the derivatives of the function which defines the differential equa-tion and on the length of the interval over which the solution is sought, but it shouldbe independent of the step number n and the step-size hn.

6.1.3 Main categories of numerical integration methods

Refs.[17] and [18] recognise four general categories of step-by-step integration meth-ods. Based upon these references, we will provide a brief overview of these methodsin this section. All equations can easily be converted to vector notations when evalu-ating sets of coupled ODEs. More information can also be found in ref.[33].

1. Taylor series methods

A smooth solution x(t) of equation (6.2) can be approximated by a Taylor series ex-pansion:

x(t + hn) = x(t) + hn x(t) +hn

2

2!x(t) + . . . (6.5)

Provided it is possible to calculate higher-order time-derivatives of x, a numericalmethod of order p can be obtained by using:

xn+1 = xn + hn xn +hn

2

2!xn + . . . +

hnp

p!

(dpxdtp

)(6.6)

The derivatives xn, xn, etc. can be expressed in terms of the partial derivatives of thefunction f from the state equation (6.2). The first neglected term provides an estimateof the local discretisation error and can be used to select an appropriate step-size.

An example of a Taylor series method is the Euler method from equation (6.3),which neglects all time-derivatives of order two and higher. Hence, the order of theEuler method equals p = 1. Higher-order Taylor series methods involve increasinglycomplex computations of the higher-order derivatives, so the general applicability ofthese methods is rather limited.

2. Runge-Kutta methods

Runge-Kutta methods approximate Taylor series methods without evaluating time-derivatives beyond the first. The higher-order derivatives are replaced by a numberof evaluations of the function f . Modern Runge-Kutta algorithms typically includetechniques for estimating the discretisation error in order to control the step-size.The Runge-Kutta methods require only one solution value xn in order to computexn+1, which makes them self-starting.

In order to gain a little more insight in the relation between the Taylor series andRunge-Kutta methods, we will now first take a look at the derivation of a secondorder Runge-Kutta method. The second-order method uses two function evaluationsper step [17]:

k1 = hn f (xn, tn)k2 = hn f (xn + βk1, tn + αhn) (6.7)


The second step is a fractional step based on k1. α and β are two as yet unknowncoefficients. The two function evaluations are combined to make a complete step,which involves two additional unknown coefficients γ1 and γ2:

xn+1 = xn + γ1k1 + γ2k2 (6.8)

To determine the coefficients, k1 and k2 are expanded in a Taylor series about (tn, xn),giving:

k1 = hn fn

k2 = hn

fn + βk1

(∂ f∂x

)n+ αhn

(∂ f∂t

)n+ . . .

(6.9)

Hence:

xn+1 = xn + (γ1 + γ2)hn fn + γ2βh2n

(∂ f∂x

)n

fn + γ2αh2n

(∂ f∂t

)n+ . . . (6.10)

In these equations, fn has been used as a shorthand notation for f (xn, tn). The ex-pansion of xn+1 can be compared with the Taylor series for the actual local solutionzn(t):

zn(tn+1) = zn(tn) + hn zn(tn) +h2

n2

zn(tn) + . . .

= xn + hn fn +h2

n2

(∂ f∂x

)n

fn +(

∂ f∂t

)n

+ . . . (6.11)

Matching the coefficients of the powers of hn yields three equations involving theunknown coefficients:

γ1 + γ2 = 1γ2β = 1

2 (6.12)

γ1α = 12

It is now possible to choose one coefficient as parameter, which results in a one-parameter family of Runge-Kutta methods. For instance, if α is chosen as a parameter,we get:

k1 = hn f (xn, tn)

k2 = hn f (xn + αk1, tn + αhn) (6.13)

xn+1 = xn +(

1− 12α

)k1 +

12α

k2

Obvious choices of α are 12 , which yields a method closely related to the rectangle

rule, and 1, yielding a method related to the trapezoid rule. The method is of secondorder, because no choice of α can eliminate the h3 terms, which were neglected in theabove equations.

Higher-order Runge-Kutta methods can be derived in a similar manner. Althoughthese higher-order methods provide an improvement of accuracy, this comes at thecost of additional derivative evaluations. For a given overall accuracy in a time re-sponse calculation, there is a trade-off between many small steps with a lower-ordermethod, or fewer steps, but more derivative evaluations with a higher-order method.


αi βij γi∗ γi

0 35384

517957600

15

15 0 0

310

340

940

5001113

757116695

45

4445 − 56

15329

125192

393640

89

193726561 − 25360

2187644486561 − 212

729 − 21876784 − 92097

339200

1 90173168 − 355

33467325247

49176 − 5103

186561184

1872100

1 35384 0 500

1113125192 − 2187

67841184 0 1

40

Table 6.1: Coefficients of the Dormand-Prince (4,5) pair

In order to reduce the number of function evaluations, mathematicians have deve-loped several algorithms that combine Runge-Kutta integration with an estimationof the error in the computed function at each time-step; the error estimate can be usedto control the step-size automatically in order to meet a specified accuracy. Over theyears, several so-called Runge-Kutta pairs have been developed. These pairs combinetwo Runge-Kutta methods, usually of adjacent orders p ≥ q, which share their α andβ coefficients and differ only in the γ’s.

For p = 1, . . . , 4 it is possible to obtain a pth-order method with p function eval-uations, while for p = 5 or 6, p function evaluations will produce a (p − 1)st-ordermethod only [17]. However, for Runge-Kutta pairs the ‘extra’ function evaluation isnot wasted, as the difference between the two solutions provides a convenient errorestimate. Such pairs are defined by:

ki = hn f (xn +i−1

∑j=1

βij ki , tn + αi hn) (6.14)

The new value xn+1 is obtained using a weighted combination of the six k’s. The twoRunge-Kutta methods that form a pair result in two solutions for xn+1:

xn+1 = xn +N

∑i=1

γi ki

x∗n+1 = xn +N

∑i=1

γ∗i ki (6.15)

where N is the number of function evaluations. For 4th/5th-order pairs, N ≥ 6. Inpractice, the lower-order solution x∗n+1 is not actually computed; instead the errorestimate:

δn ≡ xn+1 − x∗n+1 =N

∑i=1

(γi − γ∗i ) (6.16)

is determined and used for step-size control.


The coefficients αi, βij, and γi can again be found by by expanding the k’s in Tay-lor series, substituting the expansions into the formula for xn+1 and comparing theresult with the Taylor series for the true local solution zn(tn+1). Notice that the β’sform a lower triangular array, so that each ki is obtained from the previous k’s.

A popular strand of explicit Runge-Kutta methods are the Dormand-Prince pairs.Table 6.1 lists the coefficients of the fourth- and fifth-order methods (represented bythe coefficients γi

∗ and γi, respectively), which are usually combined to form theDormand-Prince (4,5) pair. This pair is used by the SIMULINK solver ode45.

3. Linear multistep methods

The Runge-Kutta and Taylor series methods determine the value of xn+1 by meansof a function which depends only on tn, yn, and the step-size hn. Multistep methodsdiffer in that they use information at previous points to obtain more accuracy. Multi-step methods can be very effective, as they usually require less function evaluationsthan one-step methods of equal accuracy: a number of past values can be kept instorage as the computation proceeds. Furthermore, an estimate of the discretisationerror can often be trivially obtained [17].

Properly programmed multistep methods can efficiently provide outputs at arbi-trary points without changing the value of the step-size. The order of the methodcan be selected automatically and changed dynamically. Some multistep methodscan handle ‘stiff’ equations (see section 6.1.4), and equations can be classified as ‘stiff’or ‘nonstiff’ automatically.

Linear multistep methods can be considered as special cases of the formula:

xn+1 =k

∑i=1

αi xn+1−i + hn

k

∑i=0

βi fn+1−i (6.17)

where fi = f (xi, ti) = xi, k is an integer, and either αk or βk is not zero. This for-mula defines the general k-step method. It is linear because every fi appears linearlyin the equation; f itself does not necessarily have to be a linear function in its argu-ments. Because of the requirements for past values, the multistep methods are notself-starting; a different method must be used to calculate the starting values of x. Af-ter equation (6.17) has been started, each step involves the calculation of xn+1 fromthe known values xn, xn−1, . . . , xn−k+1, and fn, fn−1, . . . , fn−k+1.

If β0 is nonzero, the algorithm is implicit because in that case the solution xn+1is needed to evaluate fn+1 = xn+1 on the right-hand side of equation (6.17). Theimplicit equation must be solved at each time-step. If β0 = 0, the algorithm is explicit,and the calculation will be straightforward.

It is customary to use a combination of two multistep methods for computingeach step of the solution: an explicit method, called predictor, followed by one ormore applications of an implicit method, which is called a corrector. The SIMULINK

solver ode113, which is based on an Adams method, is an example of a predictor-corrector multistep method. Some important Adams solvers found in literature arethe explicit Adams-Bashforth integration method and the implicit Adams-Moultonmethod.


i : 1 2 3 4 5 6

β1i 1

2β2i 3 −1

12β3i 23 −16 5

24β4i 55 −59 37 −9

720β5i 1901 −2774 2616 −1274 251

1440β6i 4277 −7923 9982 −7298 2877 −475

Table 6.2: Coefficients for the Adams-Bashforth integration method

i : 1 2 3 4 5 6

β1i∗ 1

2β2i∗ 1 1

12β3i∗ 5 8 −1

24β4i∗ 9 19 −5 1

720β5i∗ 251 646 −264 106 −19

1440β6i∗ 475 1427 −798 482 −173 27

Table 6.3: Coefficients for the Adams-Moulton integration method

The k-step Adams-Bashforth formula can be written as:

xn+1 = xn + hn

k

∑i=1

βki fn+1−i (6.18)

Table 6.2 lists some values βki for this method. The k-step Adams-Moulton formulaequals:

xn+1 = xn−1 + hn

k−1

∑i=0

βki∗ fn+1−i (6.19)

Table 6.3 lists some values βki∗ for this method. Often Adams-Bashforth is used as

predictor and Adams-Moulton is used as corrector.

4. Extrapolation methods

The predictor methods can be regarded as extrapolation methods, as they extrapo-late the value xn+1 from known previous values of x and the function evaluations f .There exist other extrapolation methods, based on polynomial interpolation or ratio-nal function interpolation formulas, providing alternative ODE solvers. We will notdiscuss such methods will in this report, as none of the SIMULINK integrators havebeen based on these theories. See ref.[18] for more information about this subject.


x

t

x3

t3t2t1t0

x0

x1

x2 f (t)

Figure 6.5: Unstable solution using the Euler method for a stiff system.

x

t

x3

t3t2t1t0

x0x1

x2

f (t)

Figure 6.6: Stable solution using the backward Euler method for a stiff system.


k : 2 3 4 5 6

β023

611

1225

60137

60147

α143

1811

4825

300137

360147

α2 − 13 − 9

11 − 3625 − 300

137 − 450147

α3211

1625

200137

400147

α4 − 325 − 75

137 − 225147

α512

13772

147

α6 − 10147

Table 6.4: Coefficients for stiffly stable integrator (Gear method)

6.1.4 Stiff differential equations

‘Stiffness’ of the differential equations can roughly be defined as the presence of oneor more fast decay processes in time, with a time constant that is short compared tothe time-span of interest. For stiff problems, solutions can change on a time scale thatis very short compared to the interval of integration, while the solution of interestchanges on a much longer time scale.

The time constant is defined as the time in which a solution to a differential equa-tion decays by a factor 1

e . In a physical system, different elements often have differ-ent time constants, which means that some solutions to differential equations decaymuch faster than others. In such cases the signals containing fast dynamics will de-termine the stability of the integration method, even when these components mayquickly decay to insignificant levels.

Methods not designed for stiff problems must use time steps small enough to re-solve the fastest possible changes, which makes them rather ineffective on intervalswhere the solution changes slowly. Figure 6.5 shows what happens when we applythe Euler method to a stiff problem, using too large a step-size: although the ODEitself is stable, the numerical solution can be seen to diverge rapidly. The only wayto prevent this numerical instability is to reduce the step-size, but eventually round-off and discretisation errors will accumulate enough to result in another instability.Notice that the transient part of the solution, which decays very fast, prevents an in-crease in step-size, even though the solution is very smooth after only a few seconds.With such small steps, computation time will soon become critical.

Figure 6.6 shows the same problem solved by the backward Euler method, which isan implicit method:

xn+1 = xn + hn · f (xn+1, tn+1) (6.20)

This method is stable, although the accuracy of the transient part of the solution israther poor. The accuracy can be improved by using multistep backward differen-


tiation formulas, such as the following method, first implemented by C.W. Gear [18]:

xn =k

∑i=1

αi xn−i + hn β0 fn (6.21)

The coefficients αi and β0 have been listed in table 6.4. This ‘Gear method’ differsfrom the Adams method in the way in which the implicit expression is solved. Thealgorithm for the SIMULINK solver ode15s is related to this method.

6.2 System linearisation

The FDC toolbox includes a linearisation utility ACLIN, which can be used to extract alinearized aircraft model from the SIMULINK implementation of the aircraft dynam-ics. Such models are invaluable for the application of most control system designmethods. The tool calls the SIMULINK function LINMOD for the actual linearisationprocess. Here we will briefly discuss the theoretical backgrounds.

We start with the nonlinear state equation:

x(t) = f( x(t), u(t) ) (6.22)

(the disturbance vector v has been neglected this time; for this discussion we assumedisturbances to be included in the inputvector u). This expression can be expandedin a Taylor-series about an operating point (x0, u0). Keeping only the first-order terms,we find:

x(t) ≈ ∂f∂x

(x− x0) +∂f∂u

(u− u0) + x0 (6.23)

where x0 = f( x0, u0 ) and both partial derivative matrices are determined for theoperating point (x0, u0). Moving x0 to the left-hand side of the equation yields:

x− x0 =∂f∂x

(x− x0) +∂f∂u

(u− u0) (6.24)

Now define:

x′ = x− x0, a vector of length nu′ = u− u0, a vector of length m

and:

A =∂f∂x

∣∣∣∣(x0,u0)

B =∂f∂u

∣∣∣∣(x0,u0)

Substitution into equation (6.24) yields the small-perturbations formula:

x′ = Ax′ + Bu′ (6.25)

which is the desired linear state equation, with x′ and u′ being perturbations of theoperating point values of the state and control vectors, respectively.

In practice, the operating point (x0, u0) is chosen to be a singular point or equi-librium point. The system is ‘at rest’ when all of the state derivatives are identicallyzero, and we can examine the behaviour of the system near the equilibrium point by

6.2. System linearisation 85

slightly perturbing some of the variables. For instance, if the state trajectory departsrapidly from the singular point in response to a small perturbation, the human pilotis unlikely to be able to control the aircraft [33]. In section 6.3 the computation ofsteady-state equilibrium flight conditions will be explained.

The matrices A and B can be evolved analytically by evaluating the wind-axesforce equations, the moment equations, the kinematic equations, and the positionequations presented in section 2.5. This analysis involves a large series of partialderivatives of the forces and moments with respect to other variables, the so-calledstability and control derivatives. Refs.[14] and [33] explain how these derivatives canbe determined; the first reference contains an comprehensive list of derivatives, in-cluding derivatives for an large number of observation variables.

While this analytical linearisation provides useful insight in the force and mo-ment build-up (aerodynamic forces and moments in particular), we don’t need toperform this complete analysis just to find the numerical values of the system ma-trices A and B. Since the nonlinear aircraft model has been presented in state-spaceform also, it is actually more convenient to bypass the stability derivatives and cal-culate the system matrices directly. This is done by perturbing the state and controlvariables from the steady-state condition, and numerically evaluating the partial de-rivatives. In this report we will consider the latter method only; analytical linearisa-tion tools will be kept in mind for possible future FDC versions.

The matrix A can be written out as follows:

A =

∂ f1∂x1

. . . ∂ f1∂xn

......

∂ fn∂x1

. . . ∂ fn∂xn

(6.26)

where the partial derivatives are valid for the equilibrium point. This matrix can beapproximated by:

A ≈

∆ f1∆x1

. . . ∆ f1∆xn

......

∆ fn∆x1

. . . ∆ fn∆xn

=

f1(x0+∆x1,u0)− f1(x0,u0)

∆x1. . . f1(x0+∆xn,u0)− f1(x0,u0)

∆xn...

fn(x0+∆x1,u0)− fn(x0,u0)∆x1

. . . fn(x0+∆xn,u0)− fn(x0,u0)∆xn

(6.27)

with:

∆xi = ∆xi ·

δi,1δi,2...

δi,n

δi,j =

0 if i 6= j1 if i = j (6.28)

The columns of A can be written as vectors, yielding:

A ≈[

f(x0+∆x1,u0)−f(x0,u0)∆x1

. . . f(x0+∆xn,u0)−f(x0,u0)∆xn

]=[

xx1−x0∆x1

. . . xxn−x0∆xn

](6.29)

In this equation we used the definition:

xxi ≡ f(x0 + ∆xi, u0) (6.30)

which represents the output from the state equation (6.22) in the operating point withthe ith element of the state vector being perturbed by the amount ∆xi. If this pertur-bation is chosen properly, an approximation of the matrix A can now be determinedby subsequently computing its columns (i = 1, . . . , n).


A similar method can be used to find the matrix B. This time, we need to perturb theelements of the input vector u, which results in the following approximation:

B ≈[

f(x0,u0+∆u1)−f(x0,u0)∆u1

. . . f(x0,u0+∆um)−f(x0,u0)∆um

]=[

xu1−x0∆u1

. . . xum−x0∆um

](6.31)

with:

∆ui = ∆ui ·

δi,1δi,2...

δi,m

δi,j =

0 if i 6= j1 if i = j (6.32)

and:

xui ≡ f(x0, u0 + ∆ui) (6.33)

Equation (6.33) represents the output from the state equation (6.22) in the operatingpoint with the ith element of the input vector perturbed by the amount ∆ui.

Next, we can linearize the nonlinear output equation:

y(t) = g( x(t), u(t) ) (6.34)

Again, we start with the Taylor-series expansion of this equation about the operatingpoint (x0, u0):

y(t) ≈ ∂g∂x

(x− x0) +∂g∂u

(u− u0) + y0 (6.35)

if we neglect the higher-order terms; y0 = g( x0, u0 ) and both partial derivativematrices are determined for the operating point (x0, u0). This equation can be deve-loped into the following small-perturbation equation for the output vector y:

y′ ≡ y− y0 = Cx′ + Du′ (6.36)

with:

C =∂g∂x

∣∣∣∣(x0,u0)

D =∂g∂u

∣∣∣∣(x0,u0)

C and D can be approximated in a similar fashion as the matrices A and B fromthe state equation. We can thus approximate the complete set of system matrices(A, B, C, D) of the small perturbations model, without computing any stability andcontrol derivatives. With n states and m observation variables, the dimensions ofthese matrices become:

A : (n× n)B : (n×m)C : (m× n)D : (m×m)

For the Beaver model from the FDC toolbox, n equals 12 and m equals 89. The latternumber includes the twelve state variables themselves, see chapter 3. This numericallinearisation method forms the basis of the SIMULINK linearisation function LINMOD,which is called by the FDC linearisation program ACLIN.

6.3. Steady-state trimmed flight 87

6.3 Steady-state trimmed flight

The FDC toolbox contains a specialized utility ACTRIM, which determines steady-state trimmed flight conditions that can be used as ‘operating points’ for system lin-earisation, or as initial conditions for simulations. Although SIMULINK itself alreadyincludes a generic trim function TRIM, it was decided to implement a specializedtailor-made trim routine instead, using an algorithm from ref.[33] that has provedto be very effective in practice. Based on that reference, this section will discuss theunderlying theory.

6.3.1 Definition of steady-state flight

In section 2.5, it was shown that the general rigid-body dynamics can be written asa nonlinear vector equation:

x(t) = f(x(t), u(t), v(t), t) (6.37)

with state vector x, input vector u, and external disturbance vector v. In fact, forthe Beaver aircraft, the β equation turned out to be implicit, as the aerodynamicside-force itself was directly dependent on β (similar dependencies are common inaerodynamic models). In section 3.4 we solved this problem by collecting the linearβ terms on one side of the equation, but here we will take a more general approachby considering the original implicit differential equation:

f(x(t), x(t), u(t), v(t), t) = 0 (6.38)

Notice that this equation is time variant, as it reflects the most general case, wherewe have to cater for time-dependencies such as gradual weight reduction due tofuel burn. However, in the relatively short time intervals considered in our simula-tions, the system can be treated as time invariant: the states, inputs, and disturbanceschange with time, but they are not directly dependent on time itself.

We can now introduce the concept of a singular point or equilibrium point of a time-invariant system with no external control inputs. The coordinates of the singularpoint(s) of the implicit nonlinear state equations are given by the solution vectorx = xeq, which satisfies:

f(x, x, u) = 0 , with: x = 0 and: u = 0 or constant (6.39)

Here we have omitted the disturbance vector v. The system is ‘at rest’ when all ofthe time-derivatives are identically zero, and we can examine the behaviour of thesystem near the equilibrium point by slightly perturbing some of the variables, aswe have outlined in the previous section.

Steady-state trimmed flight can be defined as a condition in which all of the mo-tion variables are constant or zero, and all acceleration components are zero. Thisdefinition is very restrictive, unless some simplifying assumptions are made. Wewill assume the aircraft’s mass to remain constant, and restrict the analysis to theflat-Earth equations of motion, so that the definition will allow steady wings-levelflight and steady turning flight. If the change in atmospheric density with altitude isneglected during the trim process, a wings-level climb and a climbing turn are alsopermitted as steady-state flight conditions.


One method to find a steady-state flight condition is to balance the individual forcesand moments by closely examining the aerodynamic and propulsion models. Thedisadvantage of this approach is that it involves working within the aircraft modelitself, which would either restrict our flexibility to implement forces and momentsin whatever format we prefer (for instance, compare the polynomial structure of theBeaver aerodynamics model with the table-lookup methods often used in industry),or require the creation of customized trimming tools for every individual aircraftmodel.

We will therefore use a more generic method that will deal with the aircraft modelonly through its input and output signals, separating the software from the modelas visualized in figure 6.1. The trim algorithm must solve a set of nonlinear simulta-neous equations, derived from the state model. The very complex functional depen-dence of the aerodynamic data makes it virtually impossible to solve these equationsanalytically, so a numerical algorithm must be used to iteratively adjust the indepen-dent variables until some solution criterion is met.

The numerical solution will be approximate, but can be made arbitrarily close tothe exact solution by tightening up the criterion. It should be realized that solutionsdo not have to be unique. For example, for a given engine power, there may be twodifferent airspeed and angle of attack combinations that result in steady level flight.Our knowledge of aircraft behaviour makes it possible to specify the steady-statecondition so that the trim algorithm will converge on an appropriate solution.

6.3.2 Specification of the flight condition

We must first decide how to specify the steady-state flight condition, how many ofthe control variables may be chosen independently, and what constraints exist onthe remaining variables. We can then develop a numerical algorithm that adjusts theremaining independent variables and evaluates the constraint equations.

If we neglect the change in air density with altitude, the state equations for theaircraft coordinates xe, ye, and the altitude H can be disregarded in our search for asteady-state flight condition, as they no longer couple back into the other equationsof motion. Steady-state flight conditions that are important for flight control systemdesign can then be defined in terms of the remaining nine state variables of the flat-Earth equations:

p, q, r, V, α, β (or u, v, w) ≡ 0 and u = constant (6.40)

Additional constraints have to be made to define the exact flight condition. Herewe will consider steady wings-level flight, steady turning flight, steady pull-up orpush-over, and steady rolls, which are defined by the following constraints:

steady wings-level flight: ϕ, ϕ, θ, ψ ≡ 0 (i.e. p, q, r ≡ 0)steady turning flight: ϕ, θ ≡ 0, ψ = turn ratesteady pull-up or push-over: ϕ, ϕ, ψ ≡ 0, θ = pull-up ratesteady roll: θ, ψ ≡ 0, ϕ = roll rate

To satisfy the conditions p, q, r ≡ 0, the angular rates must be zero (as in level flight)or constant (as in steady turns). The conditions V, α, β ≡ 0 require the airspeed,


angle of attack, and sideslip angle to be constant. As a consequence, the aerodynamicand thrust forces and moments must be zero or constant.1

First of all, we will assume that the aircraft configuration (such as the position ofthe landing gear and the aircraft loading) and secondary flight controls (flaps, slats,speedbrakes) are pre-specified. In addition, we must specify the ‘secondary enginecontrols’ (target RPM for a constant-speed propeller, mixture control for a piston en-gine) and configuration settings that affect engine power (bleed air requirements forjet engines, thrust limit settings for specific phases of flight). For the Beaver model,we will pre-specify the flap position δ f and the engine RPM n.

For steady-state flight, we expect to be able to specify the (initial) altitude andthe airspeed. The latter can be controlled by changing either the engine power or thepitch attitude of the airplane (or both), so it is useful to pre-specify at least one ofthose variables:

1. We can fix the flight-path angle, within the boundaries imposed by the enginepower, and let the numerical algorithm search for a matching value of the en-gine power. This situation is sometimes referred to as ‘speed on thrust’: fora given flight-path angle, changes in airspeed are achieved by increasing ordecreasing engine power.

2. Alternatively, we can fix the engine thrust, without putting any constraints onthe flight-path angle. This can be called ‘speed on pitch’: for a given powersetting, the airspeed can be increased by lowering the nose of the airplane, andvice versa. Notice that because of equation (6.40), it is not possible to achievesteady-state flight with an engine thrust that exceeds the weight of the airplane,as even for vertical flight that would result in a linear acceleration.

The first method introduces an additional constraint on the pitch angle, while lettingthe engine thrust be determined numerically. In the latter case, the pitch angle will beadjusted numerically, but the thrust will be pre-specified. Notice that nonzero valuesof the flight-path angle will result in ‘instantaneous’ steady-state flight conditionsonly, because the air-density will no longer remain constant if the aircraft is climbingor descending.

6.3.3 Remaining control and state variables

The primary flight controls δe, δa, and δr (elevator, ailerons, rudder) enter the modelthrough the aerodynamic data. In general, it is not possible to determine any ana-lytical constraints on these variables, so these three control inputs will be tuned bythe numerical algorithm. The thrust can either be pre-specified (‘speed on pitch’), oradjusted by the numerical algorithm (‘speed on thrust’).

For the Beaver aircraft, the primary engine control variable is the manifold pres-sure pz. The engine RPM n, which is the target speed for the regulator mechanismof the constant-speed propeller, is considered a secondary engine control signal thatcan be pre-specified.

1Because of this requirement, steady-state pull-up or push-over and steady-state roll conditions canonly exist instantaneously. However, it can still be useful to trim the aircraft dynamics in such flightconditions and use the resulting operating point values of x and u for aircraft model linearisation,because flight control systems must operate there too.


In steady-state translational flight conditions, the state variables ϕ, p, q, and r areidentically zero and ψ can be selected freely. Since V and H are also specified by theuser, and xe and ye are irrelevant for the steady-state solution, the only remainingstate variables to be determined are α, β, and θ.

The angle of attack α must be adjusted by the trim algorithm to generate theamount of lift needed to support the weight of the aircraft (remember that we choseto pre-specify the airspeed and altitude, and hence, the dynamic pressure). The side-slip angle β must be adjusted by the trim algorithm to zero out the sideforce Fy.

For a given value of the flight-path angle γ (‘speed on thrust’), the pitch angle θwill be constrained, as we will explain in the next section, which presents a generalrate-of-climb constraint that allows nonzero roll angles. If the thrust is specified bythe user (‘speed on pitch’), the pitch angle can be adjusted by the trim algorithm.

In steady-state turning flight conditions, the state variables ϕ, p, q, and r will differfrom zero. The turn can be specified directly in terms of the yaw rate ψ or indirectlythrough the turn radius R. These variables are interrelated as follows:

ψ =VR

(6.41)

The initial heading can still be specified freely. If the attitude angles θ and ϕ areknown, it is possible to determine the angular rates p, q, and r from the kinematicrelations given in equation (2.59) of section 2.4.

In principle, it is also possible to define the turn by specifying the roll angle ϕdirectly. However, that will in general introduce a significant sideslip angle β, re-sulting in a skidding turn, in which a side-force is experienced by the flight crew andpassengers. To avoid this, an additional constraint for coordinated turns will be de-rived in section 6.3.5, in order to compute the roll and sideslip angles such that theaircraft is banked at an angle with no component of the aerodynamic and propulsiveside-force Ya + Yp.

If the roll angle ϕ is known, the required pitch angle θ can be obtained from therate-of-climb constraint, which will be derived in the next section. Since the turn-coordination constraint will be shown to involve both θ and ϕ, it must be solvedsimultaneously with the rate-of-climb constraint.

6.3.4 The rate-of-climb constraint

A constraint for the rate-of-climb H can be found by combining the ze part of equa-tion (2.61), and equations (2.31), (2.62), and (3.45):

sin γ =HV

= − ze

V=

= − ue sin θ + (ve sin ϕ + we cos ϕ) cos θ =

= a sin θ − b cos θ (6.42)

with:

a ≡ cos α cos β

b ≡ sin ϕ sin β + cos ϕ sin α cos β (6.43)


Solving for θ, the resulting rate-of-climb constraint is found to be [33]:

tan θ =a b + sin γ

√a2 − sin2 γ + b2

a2 − sin2 γ, θ 6= ±π

2 (6.44)

which allows us to compute θ, knowing the pre-specified value of γ and the currentvalue of ϕ. Obviously, this constraint is not applicable for ‘speed on pitch’.

6.3.5 The coordinated turn constraint

In the Earth-fixed reference frame, assuming a flat Earth, the velocity vector is tan-gential to the turning circle, so the centripetal acceleration, expressed in units of [g]equals:

G =ψVg0

(6.45)

We can derive a constraint for coordinated turns by taking the lateral v equation ofthe nonlinear force equations (2.28), imposing the steady-state condition v = 0, andthe coordination condition Fy = Fgr, i.e. no aerodynamic and/or propulsive side-force. Substituting equation (3.10) yields:

g0 cos θ sin ϕ + pw− ru = 0 (6.46)From the kinematic relations (2.59), we can derive:

p = −ψ sin θ

r = ψ cos θ cos ϕ (6.47)Substituting these equations in equation (6.46), and replacing u and v by the corre-sponding relations from equation (2.31), we find:

g0 cos θ sin ϕ− ψV(

sin θ sin α cos β + cos θ cos ϕ cos α cos β)

= 0 (6.48)

Finally, by substituting equation (6.45) and re-writing terms, the resulting coordi-nated turn constraint is found:

sin ϕ = G cos θ (sin α tan θ + cos α cos ϕ) (6.49)

6.3.6 Combined constraints

Equation (6.49) must be used in conjunction with (6.44) if we want to trim the aircraftfor a coordinated turning flight with a specified rate-of-climb. If these equations aresolved simultaneously, the only remaining variables to be adjusted by the numeri-cal trim algorithm are the angle of attack and sideslip angle and the control inputs.According to ref.[33] the simultaneous solution equals:

tan ϕ = Gcos β

cos α

(a− b2) + b tan α√

c (1− b2) + G2 sin2 β

a2 − b2 (1 + c tan2 α)(6.50)

where:a ≡ 1− G tan α sin β

b ≡ sin γ

cos β(6.51)

c ≡ 1 + G2 cos2 β


xu

Specify (initial)flight- and aircraft-

condition for trimming

Minimisationalgorithm

Store steady-statevalues of andx u

Flight pathconstraints

Aircraft model(evaluate state equations)

Scalar cost functionJ = J , ( ) ( )x x u

.

x.

Figure 6.7: Aircraft trim algorithm

The value of ϕ found in equation (6.50) can be substituted in (6.44) to solve for θ.When the flight-path angle is zero, equation (6.50) reduces to:

tan ϕ =G cos β

cos α− G sin α sin β(6.52)

For skidding turns ϕ can be selected freely by the user, so then only the rate-of-climbconstraint remains to be solved.

6.3.7 The resulting steady-state trimmed-flight algorithm

We can now develop a general aircraft-trim algorithm that determines steady-stateflight conditions by searching for the state and control vectors for which the statederivatives V, α, β, p, q, and r are identically zero, as specified in equation (6.40).

This is achieved by means of a multivariable numerical optimisation routine thatminimises a scalar cost function by adjusting the control inputs and appropriate statevariables. The cost function J is usually equal to the sum of the weighted squares ofthe time-derivatives:

J = c1V2 + c2α2 + c3 β2 + c4 p2 + c5q2 + c6r2 (6.53)

where ci, i ∈ 1, 2, . . . , 6, are weighting constants. A suitable optimisation techniquefor this particular problem is the Simplex method [33].

Figure 6.7 shows a block diagram of the resulting trim algorithm. First the flightcondition must be specified. The trim program must make an initial guess for theindependent state variables and the control variables that will be adjusted during

6.4. Miscellaneous simulation issues 93

the trim process. Next, the minimisation routine which searches for those values of xand u that minimise the cost function J will be started. The elements of these vectors,which are adjusted by either the minimisation routine or the constraints, are updatedfor each iteration step.

The state equations are then evaluated for the new values of u and x to find thetime-derivative of the state-vector, x. Substituting the results in equation (6.53) yieldsthe new value of J, which is returned to the minimisation routine. A stop criterionthat depends upon the change of J between two iterations is used to decide whento finish the minimisation procedure. Also, the maximum number of iterations islimited so the process will stop if the solution does not converge.

6.4 Miscellaneous simulation issues

In the previous sections, we have discussed most analytical functions from figure 6.1,focussing on numerical integration, linearisation and trimming methods. In this sec-tion, some other issues which may be encountered during numerical nonlinear sim-ulations will be highlighted. These topics are relevant for the FDC toolbox, becausethey shed some light on the practical difficulties one may encounter, and providebackground information for some analytical functions. The information from sec-tion 6.4.2 has been applied in practice to create some FDC submodels.

6.4.1 Algebraic loops

Continuous systems are often expressed as block diagrams, which divide the sys-tem into logical modules, and suggest a certain order of computations. The latter,though convenient for digital simulations, is not in accordance with reality: in theactual system, all variables will change simultaneously, not sequentially. A suitablecalculation sequence is needed for digital simulations, but we should realize that thisis an artificial construct – a sequential representation of what is, in effect, a parallelsystem.

If feedback is applied to a system, it may not be possible to find a suitable compu-tation sequence for digital simulations. This situation generally occurs when blockshaving direct feedthrough of their input signals form a feedback-loop: the block out-puts cannot be computed without knowing the values of the signals entering theblocks, while the block inputs cannot be computed without knowing the signals leav-ing the blocks. This is called an algebraic loop.

A simple example of this situation can be seen in figure 6.8, which shows a sys-tem consisting of a gain K with negative unity feedback. Mathematically, this loopimplies that the output of the summation junction is an algebraic state e, constrainedto equal the first input u minus the output y, which equals K · e:

y = K · e = K(u− y) (6.54)

The solution of this simple loop is:

y =(

K1 + K

)u (6.55)

but most algebraic loops cannot be solved so easily [4].


Ku e y+_

Figure 6.8: Gain with unity feedback: an algebraic loop

0 1 2 3 4 5-2

-1

0

1

2

3

4

t [ s ] y( t ) / K

Input: unit step at t = 0K = 1.5K = 1.0K = 0.5

Figure 6.9: Dynamics, introduced by the algebraic loop from figure 6.8

AlgebraicEquations

ALBx g(x)

Figure 6.10: Iterative solution of an algebraic loop


It is interesting to see what will happen if we try to integrate this system with anumerical integration method, using a step-size hn, by introducing an artificial com-putation sequence as follows:

en = un − yn−1

yn = Ken = K(un − yn−1) (6.56)

where yn ≡ y(n · hn) and yn−1 ≡ y((n − 1)·hn−1) for an integer value n. Taking theZ-transform of these equations yields:

Y(z)U(z)

=Kz

z + K(6.57)

which indicates that inadvertent additional dynamics have been introduced as a con-sequence of trying to calculate the responses of a parallel system using sequential cal-culations. Figure 6.9 visualizes unit step-responses for the Z-transfer function (6.57)for several values of the gain K.

When SIMULINK detects an algebraic loop it will calls a loop solving routine ateach time step. The loop solver tries to determine a solution by means of Newton-Rhapson iterations [4]. First, a new block ALB is added to the system containing theimplicit algebraic equations from the algebraic loop, see figure 6.10. This block hasan input g(x) and an output x. The block attempts to find a value of x such thatg(x) = x, which means that it tries to solve the following nonlinear equation:

G(x) ≡ g(x)− x = 0 (6.58)

This is done by applying the Newton-Rhapson method [8]:

xi+1 = xi −G(xi)G′(xi)

(6.59)

where:

G′(xi) =G(xi + ∆x)

∆x(6.60)

for small values of ∆x. The subscript i in these equations denotes the iteration num-ber, not the time-step. In some situations, this method will not converge to a solutionwithin a reasonable number of iterations. SIMULINK will display an error message ifit is unable to solve the algebraic loop within 200 iterations (it is possible and recom-mended to specify an initial guess; see ref.[4] for more information).

Since the Newton-Rhapson iterations have to be carried out for every time-step,the presence of one or multiple algebraic loops will slow down simulations. Oneshould try to avoid this whenever possible. An algebraic loop can be ‘broken’ byincluding an additional dynamic element in the feedback loop, e.g. a filter or anartificial time-delay. However, the effect of such measures needs to be weightedcarefully – remember the inadvertent dynamics from figure 6.9.

Sometimes, it is possible to write out the system equations in an explicit form.For instance, the algebraic loop from figure 6.8 can be eliminated by replacing thisdiagram with a single block representing equation (6.55). Another example was pro-vided in section 3.4, where an algebraic loop in the equation for the aircraft’s sideslipangle was averted by re-writing the differential equation in an explicit form.


U(s) s Vn-1

1/ss V

n-2s V V(s) Y(s)

++

++

++

bn-1

bn-2

b1

b0

++

++

++

+-

an-1

an-2

a1

a0

bn

++

Vs n

1/s 1/s

Figure 6.11: Block-diagram equivalent of a transfer function

6.4.2 Obtaining state-models from transfer functions

Linear systems are often represented in terms of transfer functions, which can be im-plemented in SIMULINK block-diagrams by means of Transfer Fcn blocks. However,since the numerical integrators cannot be applied directly to such transfer functions,a conversion to state-space format is necessary. Obviously, SIMULINK will handlethis conversion for Transfer Fcn blocks, but we will discuss this topic in a little moredetail nevertheless, as this knowledge will prove to be useful for the implementationof transfer functions with non-constant coefficients.

There exist a variety of techniques to convert transfer functions into linear statemodels. Refs.[8, 33] and [36] contain some examples, and ref.[10] includes a morefundamental discussion of this topic. Regardless of the method, the resulting statemodels will not be unique, as they depend on the choice of state variables. Here wewill focus on what is called the ‘controllable canonical form realisation’ [10], whichwill generally be adequate for our needs.

For a broad class of systems the dynamic behaviour of variations about operatingpoint values can be approximated by an nth-order linear differential equation:

dnydtn + an−1

dn−1ydtn−1 + . . . + a2

d2ydt2 + a1

dydt

+ a0y =

= bmdmudtm + bm−1

dm−1udtm−1 + . . . + b2

d2udt2 + b1

dudt

+ b0u (6.61)

where u(t) and y(t) represent the variations of input and output signals, ai and bi are


real constants, and m and n are scalars, representing the highest-order derivativesof the input and output signals, respectively (m ≤ n). The corresponding transferfunction is:

H(s) ≡ Y(s)U(s)

=bmsm + bm−1sm−1 + . . . + b2s2 + b1s + b0

sn + an−1sn−1 + . . . + a2s2 + a1s + a0(6.62)

If there are no input derivatives present in the differential equation (i.e. if m = 0), thetask of finding a state representation is trivial: state variables can simply be assignedto the output y and its derivatives up to order n − 1, and n state equations can bewritten down immediately.

To derive the state equations in the general case where input derivatives are present,we will first re-write this transfer function, introducing a help function V(s):

V(s) ≡ Y(s)bmsm + . . . + b1s + b0

=U(s)

sn + . . . + a1s + a0(6.63)

This yields the following equations:

Y(s) = (bmsm + . . . + b1s + b0) V(s) (6.64)

snV(s) = U(s)− an−1sn−1V(s)− . . . − a1sV(s)− a0V(s) (6.65)

These equations can be represented in a ‘simulation diagram’, as illustrated in fig-ure 6.11. This diagram is constructed from a series of cascaded first-order integrals(the 1

s blocks) and simple gain blocks; V(s) is the output of the last integrator andthe number of integrators is equal to the degree of the denominator polynomial oftransfer function (6.62).

Equation (6.65) relates the input of the first integrator to the transfer function in-put U(s) and the feedback signals from later integrators. This equation correspondsto the lower half of figure 6.11. Equation (6.64) establishes the resulting output signalY(s); the output connections have been drawn in the upper half of the figure. Noticethat the figure assumes the highest order of the input and output derivatives to beequal, i.e. m = n. For m < n, some of the bi coefficients are zero.

If we now assign state variables to the integrator outputs, working from right toleft and starting with the rightmost integrator, we can define the state vector for thistransfer function block as:

x(s) = V(s)

1ss2

s3

...sn−1

(6.66)

By observing the simulation diagram, we can obtain the familiar linear state andoutput equations (taking notice of the fact that u and v are scalars, and x is a vectorof length n):

x = Ax + buy = cx + du (6.67)


The state matrices then become:

A =

0 1 0 . . . 00 0 1 . . . 00 0 0 . . . 0...

......

...0 0 0 . . . 1−a0 −a1 −a2 . . . −an−1

b =

000...01

(6.68)

c =[

b0 b1 b2 . . . bn−1]

d = bn

This form of the system matrix A is known as a companion-matrix: all elements arezero, except for the superdiagonal 1’s and the nonzero bottom row. The simplicity ofthis form makes it useful for theoretical derivations, but its numerical computationproperties are not particularly good. However, this is not a problem when dealingwith systems of low order [33].

For the FDC toolbox, the structure from figure 6.11 has been applied for the imple-mentation of the Dryden turbulence filters, which are defined by transfer functionswith airspeed-dependent coefficients, and for a filter in the Altitude Select mode ofthe Beaver autopilot, which also uses non-constant coefficients. Obviously, the stan-dard Transfer Fcn block from SIMULINK is more convenient for the implementationof transfer functions with constant coefficients.

Chapter 7

Getting started with the FDC toolbox

Having treated the underlying theory, it is now time to introduce the Flight Dynam-ics and Control Toolbox software itself. This chapter explains how to install thetoolbox on your computer, and allows you to get acquainted with the software byexploring the FDC directories and libraries. It also explains the modular and layeredarchitecture of the SIMULINK models and outlines the relation between models andlibraries. A detailed description of all individual FDC models and programs willbe provided later in chapters 8 to 11, while the practical use of the software will bedemonstrated in chapter 13.

7.1 Objectives of the FDC toolbox

Let’s start by summarizing the purpose of this software. The Flight Dynamics andControl toolbox (‘FDC toolbox’) for MATLAB and SIMULINK was conceived as anOpen Source software environment for flight simulation, open-loop analysis of air-craft dynamics, and closed-loop analysis of flight control systems. It has been con-structed around a nonlinear dynamics model of the DeHavilland DHC-2 Beaveraircraft, which is characterized by comprehensive, yet still straightforward modelequations. The model has been implemented in a layered, modular SIMULINK blockdiagram structure, which can be adapted for other airplanes with relative ease.

The toolbox includes SIMULINK models of the airplane dynamics, wind and tur-bulence, radio-navigation signals, and the control laws of the Beaver autopilot, asdeveloped at Delft University of Technology [28]. It also provides analytical MAT-LAB routines for the computation of steady-state flight conditions and linearizedflight models, and several help-utilities that simplify system handling. The individ-ual models, subsystems, and blocks have been systematically collected in a series ofSIMULINK libraries.

The toolbox was originally created as part of an autopilot design project. Thecurrent version 1.4, when applied in the context of the MATLAB platform and itsmultitude of systems analysis and control design tools, can be considered an advance‘proof of concept’ of an integrated software environment for flight control systemdesign, which can help streamline the design cycle discussed in chapter 1. However,its application is not limited to FCS design only – the toolbox can provide a startingpoint for a wide range of stability and control related research projects and courses.

100 Chapter 7. Getting started with the FDC toolbox

7.2 System requirements

Version 1.4 of the FDC toolbox was developed for MATLAB Release 11 (MATLAB 5.3 /SIMULINK 3.0), but it has been reported to work correctly with later MATLAB releasesas well. Although it has been built and tested on an MS WINDOWS system, the tool-box is intended to be system-independent. While this has not been tested extensively,user reports suggest that this goal has indeed been achieved.

Any computer that is powerful enough to handle the hardware requirements forMATLAB and SIMULINK (for detailed information, refer to the website of The Math-works: http://www.mathworks.com) should be able to handle the FDC systems com-fortably. Only if your computer is barely able to cope with the demands of MATLAB

itself it may run out of memory when performing intensive FDC simulations. Thetoolbox requires at least 2.7 MBytes of free space on your harddisk, although up totwice that amount of free space may be needed in practice, depending on the file-system used and the amount of ‘file slack’ for the relatively large number of smallfiles. It is, however, highly recommended to have additional space available for datastorage and possible future model enhancements.

These hardware and software requirements may be changed for future versionsof the toolbox. For the most up-to-date information, refer to the website of theFDC toolbox, http://www.dutchroll.com or http://www.dutchroll.org, and theREADME-file that is shipped with the software itself.

7.3 License Agreement

The FDC toolbox version 1.4 is distributed as Open Source software, licensed underthe Open Software License (OSL), version 2.1 or later. A copy of this license hasbeen included in appendix F and the software itself includes a flat-text copy of theOSL. (Earlier versions of the toolbox have been distributed under slightly differentlicenses, which are now considered obsolete. Redistribution of those versions underthe terms of the OSL version 2.1 or later is considered acceptable.)

The OSL allows you to freely use and distribute the toolbox. It also allows youto modify the source code, and re-distribute modified files, provided the licensingterms are not altered. This licensing model was chosen to allow as many people aspossible to freely use, change, and share this software. Unrestricted access to thesource code was deemed essential, as one of the main ‘features’ of this toolbox is itstransparent design, which makes it easier to understand how to put the theory offlight dynamics modelling into practice, and which provides the flexibility to changethe tools and models if required.

For more information about the philosophy behind open source software and li-censing, see the website of the Open Source Initiative, http://www.opensource.org.Please take some time to study appendix F before using this software. If, for somereason, these licensing terms are not suitable or not acceptable for your particular sit-uation, it is recommended to contact the author to see if a different licensing schemecan be arranged.

7.4. Installation and initialisation of FDC 1.4 101

Figure 7.1: Starting the FDC 1.4 initialisation

Figure 7.2: Splash screen

7.4 Installation and initialisation of FDC 1.4

Note: all file and path-notations in this report have been presented in MS-WINDOWS

format. For different operating systems, use the appropriate substitutes. All screen-shots and other examples have been created with MATLAB Release 11 for WINDOWS.It is possible that newer MATLAB and SIMULINK versions use a different menu struc-ture, keyboard shortcuts, or default directories, and the referrals in this chapter toright-click context-menus may be valid for WINDOWS systems only.

The FDC Toolbox is distributed via the FDC website (http://www.dutchroll.com orhttp://www.dutchroll.org). It has been packed into a ZIP archive – an installer isnot available. To install the FDC toolbox, the ZIP archive must be unpacked intoan appropriate directory, and the FDC subdirectories must be appended to the MAT-


LAB path by running a dedicated initialisation utility. The following instructions willguide you through this installation process:

1. Copy the archive file FDC14.ZIP into a temporary directory.

2. Create a suitable destination directory for the FDC toolbox. The recommendedlocation is a subdirectory FDC14.ZIP within the TOOLBOX directory of MATLAB

but any other dedicated directory would do fine as well. For example, if MAT-LAB itself has been installed into C:\MATLAB, the recommended destinationdirectory for the FDC toolbox would be C:\MATLAB\TOOLBOX\FDC14, but ifyou prefer something like K:\MYTOOLS\FDC14 that’s fine also.

3. Unpack FDC14.ZIP into this destination directory. Be sure to retain the FDCdirectory structure when unpacking. (If you use the MS-DOS based PKUNZIP

utility, this is achieved by using the -d option on the pkunzip command-line;newer unpack routines, such as WINZIP or 7ZIP, will normally retain the direc-tory structure by default.)

4. At this stage, it is recommended to read the documentation in the FDC sub-directory DOC. In particular, check README.TXT for important last-minute in-formation (this file also contains a copy of these installation instructions), andCOPYING.TXT and LICENSE.TXT for the terms of use. Other documentation filesare CHANGELOG.TXT, which describes the major changes in the last few FDCversions, ROADMAP.TXT, which outlines past FDC developments and futureplans, and CONTENTS.TXT, which contains a complete list of FDC files.

5. Start MATLAB version 5.3 or later and use the command cd or chdir to go to theFDC directory specified above (from now on denoted as ‘FDC root-directory’).This has been illustrated in figure 7.1, where it is assumed that the FDC toolboxhas been installed into the directory K:\MYTOOLS\FDC14.

6. Type fdc at the command-line to run the FDC initialisation routine. The splashscreen from figure 7.2 will appear, to signal that the toolbox is being started;click on the splash screen with the mouse pointer, or press any key to continue.1

After closing the splash screen, the command window will look like figure 7.3.

7. The toolbox will now be initialized by appending the FDC subdirectories to theMATLAB-path. As shown in figure 7.3, you will be asked to verify the defaultFDC search-path: Path ok? (y=yes, n=no, s=suppress this message in the future). Ifyou have followed the above instructions, it is normally sufficient to verify thelocation of the FDC root-directory; the option to change subdirectory names ismeant to accommodate possible future additions to the toolbox.

8. If the displayed path differs from the actual location of the FDC directories,answer the above question with n. The initialisation routine will direct you tothe menu shown in figure 7.4, from where you can change the root-directory,change or delete the subdirectories, or add new subdirectories to the toolbox.Select ‘ready’ to return to the directory-check window from figure 7.3.

9. If the FDC path is correct, you can leave the directory-check window by answer-ing the question from step 7 with y. This directory-check (and the directory

1The splash screen can be disabled for future sessions by commenting-out the line containing thecall fdc splash; in the file FDC.M, contained in the FDC root-directory.

7.4. Installation and initialisation of FDC 1.4 103

Figure 7.3: Verify the FDC directory structure during initialisation

Figure 7.4: Specifying a new FDC 1.4 root-directory during initialisation


Figure 7.5: Suppressing the directory-check for future FDC-sessions

Figure 7.6: FDC initialisation completed

7.5. Uninstalling FDC 1.4 105

editing features) can be suppressed for all future FDC sessions by answeringwith s instead.1 If this latter option is selected, the initialisation routine willask for confirmation, as shown in figure 7.5.

10. Next, the welcome message from figure 7.6 will be shown to signal that thetoolbox has been initialized. The FDC directories have now been appended tothe MATLAB path, so all FDC programs and models can now be opened directlyfrom the command line, regardless of the current working directory. The mainFDC library can be accessed by typing fdclib, while the on-line helpfiles forFDC 1.4 can be shown in a webbrowser or the MATLAB help browser by typingbrowse fdc. In addition, the FDC directories will be appended to the bottom ofthe list in the MATLAB help window, which can be opened by typing helpwin.Double-clicking those directories will reveal a brief overview of their contents.(The same information can be opened directly from the MATLAB commandline by typing help <dirname> , where <dirname> is the name of the FDC root-directory or subdirectory.)

Notice that the FDC directories will not be appended to the MATLAB path perma-nently. After closing MATLAB it will be necessary to repeat steps 5 to 10 from theabove list again: start MATLAB, change to the FDC root-directory, type fdc at thecommand-line, and verify the directory structure. This last step can be skipped forfuture FDC sessions by choosing the ‘suppress’ option in step 8.

Users who intend to use the FDC toolbox frequently, may find it convenientto permanently append the FDC root-directory to the MATLAB path. This can beachieved by manual editing of the MATLAB system files PARDEF.M or STARTUP.M,or by means of the path browser, which can be started by typing editpath at thecommand-line. See the MATLAB documentation for more information about theMATLAB path [3].

In the remainder of this report we will assume that the toolbox has been properly ini-tialized, so that all options are readily available from the command-line, regardlessof the current working directory.

7.5 Uninstalling FDC 1.4

Although the toolbox does not include an uninstall utility, the uninstall process itselfis straightforward: just delete the entire FDC 1.4 directory, including all subdirec-tories (however, be careful not to inadvertently delete important datafiles from theDATA directory, if you wish to use them later!).

If the FDC directories have been permanently appended to the MATLAB pathby editing PATHDEF.M or STARTUP.M, it will also be necessary to remove the FDC-related items from those initialisation files, either by hand, or by using the MATLAB

path browser. The FDC toolbox does not store any information in the Windowsregistry or in other directories, and involves no other system-dependencies.

1If it is desired to restore the directory check and editing features for later FDC sessions, the fileFDCINIT.INI must be deleted from the FDC root-directory. This will cause the FDC initialisation routineto assume that the toolbox is run for the first time, and reset the FDC path to its default status.


7.6 The FDC directory structure

Let’s take a closer look at the contents of the FDC toolbox, starting with an overviewof its directory structure. The files from this toolbox have been organized in tenseparate subdirectories:

AIRCRAFT contains the nonlinear aircraft model Beaver, the main library FDCLIB,the aircraft model sublibraries FDCLIB1 till FDCLIB10, and the program MOD-BUILD, that defines the parameters for the aircraft model,

APILOT contains several simulation models of the Beaver autopilot, and some re-lated MATLAB functions,

DATA is used to store FDC datafiles (in particular *.TRI files, which are used tostore trimmed flight conditions, *.LIN files, to store system matrices of linearizedaircraft models, and *.DAT files, to store model parameters),

DOC contains program documentation files (README-file, list of new features, listof features for future versions of the toolbox, a complete list of all files from thetoolbox, and the software license documents),

EXAMPLES contains some open-loop simulation models and MATLAB demos thataccess the aircraft model for open-loop simulations, an analysis of the aerody-namic and propulsive models, and the computation of an elevator deflectioncurve for trimmed flight conditions,

HELP contains the HTML helpfiles for the FDC models and programs,

NAVIGATE contains the library NAVLIB and its sublibraries, which include modelsof the ILS and VOR radio-navigation systems,

PROGRAMS contains the trim and linearisation routines, a tool for quick analy-sis of the properties of linear systems, routines for post-processing simulation re-sults, load routines for model-initialisation and quick access to FDC datafiles, theHTML browse routine that forms part of the on-line help system, and some sup-porting routines to determine the screensize, display text-menus, convert num-bers to strings in a nice lay-out, determine the data and help directories, and fixstates in the aircraft model,

TOOLS contains the SIMULINK library FDCTOOLS, which includes several usefulgeneral-purpose blocks that cannot be found in the standard SIMULINK libraries,

WIND contains the library WINDLIB and its sublibraries, which include models ofsteady wind and atmospheric turbulence.

7.7 The FDC model libraries

As we will see in the next section, the SIMULINK models in the FDC toolbox have alayered, modular structure. The subsystems and masked blocks that comprise thesemodels have been arranged in a series of SIMULINK libraries. A single access-pointto all libraries and simulation models is provided by the main library FDCLIB, shownin figure 7.7, which can be opened by typing fdclib at the command-line.

7.7. The FDC model libraries 107

Figure 7.7: Main block-library of the FDC toolbox

FDCLIB includes the six aircraft model sublibraries FDCLIB1 till FDCLIB6, which con-tain the blocks from the nonlinear dynamic model of the Beaver. In addition, it pro-vides links to the following libraries and models:

• the nonlinear six-degree-of-freedom models of the complete aircraft (thesystem Beaver and subsystem equivalents of this model),

• the wind and turbulence library WINDLIB,

• the radio-navigation library NAVLIB,

• the open-loop simulation models OLOOP1, OLOOP2, and OLOOP3,

• the closed-loop autopilot simulation models PAH, RAH, PAHRAH, APILOT1,APILOT2, APILOT3, and the autopilot blocklibrary APLIB,

• the general-purpose library FDCTOOLS,

• the library FBUTTONS, which contains a selection of buttons that have beenincluded in the open-loop and closed-loop models of the FDC toolbox.

Detailed descriptions about these libraries and simulation models will be providedin the next chapters. The sublibraries and models can be opened by double-clicking


Figure 7.8: Top-level of the system Beaver

the corresponding boxes in the main library window, or by right-clicking these boxesand selecting ‘open’ in the context-menu. They can also be accessed directly fromthe MATLAB command-line by typing their names in lower-case. For instance, thecommand navlib will open the navigation library NAVLIB, and apilot1 will openthe autopilot model APILOT1.

7.8 Taking a closer look at the aircraft model

The complete nonlinear aircraft model is contained in the SIMULINK system Beaver,which can be accessed via FDCLIB, or directly from the command-line. A detaileddescription of this model can be found in chapter 8. Here we will use this model toexplain the layered and modular structure of the SIMULINK systems, the use of blocklibraries, and the on-line help facilities for the FDC toolbox. A similar structure hasbeen used for virtually all SIMULINK models from this toolbox.

To open the system Beaver, double-click the block ‘Complete system BEAVER’ inthe FDCLIB window, or type beaver at the command-line. The top-level of this modelhas been shown in figure 7.8. This level handles the input/output functions of theaircraft model, sending simulation results to the MATLAB workspace by means ofTo Workspace blocks, and providing Inport and Outport handles that allow MATLAB

programs to access this model. The actual system dynamics have been implementedin the subsystem ‘Beaver dynamics and output equations’.

7.9. Linking to SIMULINK libraries 109

Notice the three blocks with shadow borders (in reality, these blocks have been ac-centuated by a blue colour). The shadow indicates that some action will occur whenthese blocks are double-clicked. In this case, related help information will be dis-played in your webbrowser or the MATLAB help browser. The upper-left block iscalled a ‘title block’, which shows the blockname, the author, and the latest revisiondate; it has been linked to help information about the subsystem itself. Similar titleblocks can be found in all models and most subsystems from the FDC toolbox.

If you double-click on the subsystem ‘Beaver dynamics and output equations’, thedialog window from figure 7.9 will be shown. The first line below the window titleprovides the blockname, and indicates that we are dealing with a masked subsystem,that has been linked from a SIMULINK library. Directly beneath, a brief descriptionabout the block is given. Detailed information about the masked subsystem will beshown in a webbrowser or in the MATLAB help browser if the Help button is clicked.

The dialog window can be closed by clicking Cancel, which will cause SIMULINK

to return to the system Beaver. Without further interaction from the user, the subsys-tem ‘Beaver dynamics and output equations’ will remain active, which is indicated byfour tiny black squares in its corners. The active status of the subsystem can be cycledby repeated single-clicking on the subsystem block (the tiny squares will disappearwhen the block is deactivated, and reappear when it is reactivated again).

In order to examine the internal structure of this block, we need to look underthe mask. This can be done in several ways: (i) right-click the block, and select ‘Lookunder Mask’ in the context-menu, (ii) activate the block and select ‘Look under Mask’in the Edit menu, or (iii) activate the block and press Ctrl + U in order to unmaskthe block. Use whatever method you prefer. Unmasking the subsystem ‘Beaver dy-namics and output equations’ results in the opening of the new window shown infigure 7.10, which reveals the internal structure of this subsystem.

This second level of the aircraft model again contains a title block in the upper-leftcorner; double-clicking this block will reveal the same help information as the Helpbutton from figure 7.9. The subsystem includes four masked blocks, which havebeen linked from a SIMULINK library, and five subsystems without a mask interface.To indicate that these unmasked subsystems also have library links, they have beenhighlighted with a light-blue colour (shown as a grey colour in figure 7.10).

7.9 Linking to SIMULINK libraries

SIMULINK libraries enable users to copy blocks from external libraries into the si-mulation models, and automatically update these blocks when the source librarieschange. In fact, the model only contains a placeholder for the block, instead of theblock itself, with a link referring to the applicable source library that contains theactual block contents. This promotes the re-use of existing blocks, and prevents in-advertent proliferation of multiple versions of the same block (some being properlyupdated, some inadvertently remaining unchanged).

To demonstrate the use of the libraries in the FDC toolbox, we will take a closerlook at the block Gravity, which can be found slightly left of the center of figure 7.10.Double-clicking this block results in the mask-dialog from figure 7.11. As we haveseen before in figure 7.9, the mask-dialog includes a short description of the block, a


Figure 7.9: Mask dialog for the system Beaver

Figure 7.10: Level 2 of the system Beaver (main level of the aircraft model)

7.9. Linking to SIMULINK libraries 111

Figure 7.11: Mask dialog for the block Gravity

Figure 7.12: Gravity and wind forces blocklibrary

Figure 7.13: Looking under the mask of Gravity

Figure 7.14: Error when trying to edit a locked library


note that the block has been masked, and a note that the block has been linked froma library. In this case, there is also a parameter field, although it has been lockedbecause the parameter definition for this particular block can only be changed in thelibrary in which it is defined.

It is possible to quickly jump from a block in a model (actually: its placeholder) tothe corresponding library by: (i) right-clicking the block and selecting ‘Go To LibraryLink’ from the context-menu, (ii) activating the block and selecting ‘Go To LibraryLink’ from the Edit menu, or (iii) activating the block and pressing Ctrl + L . If weapply this method to the Gravity block, figure 7.12 will be opened, with the Gravityblock being activated as shown in the figure. Of course, if you know the name of thelibrary, it is also possible to open it directly from the command-line. In this exampletyping fdclib4 or double-clicking the ‘Gravity and wind forces’ button in the mainFDC library will open the library shown in figure 7.12.

The internal structure of this block can again be shown by unmasking it first.This yields figure 7.13, which shows the deepest level of this block, i.e. the levelin which the actual equations are evaluated. The expressions within the individualFcn blocks will probably look rather cryptic at first sight, but once one knows themeaning of the input and output signals (as explained in the next chapters and theon-line help information) and the part of the theory on which these equations arebased, understanding the block-equations actually turns out to be relatively easy.

Notice that it is not necessary to open the blocklibrary to view the deepest level of ablock: it is possible to look beneath the mask of a linked block within a model too.The only drawback is that this may cause confusion because linked blocks can notbe edited within the model. Libraries are ‘read-only’ or ‘locked’ by default, whichmeans that it is not possible to change any elements in library blocks, unless thelibrary is released first by selecting the ‘Unlock Library’ option in the Edit menu. Ifthe user does try to edit a locked library, or manipulate a linked block directly fromwithin a model, the error message from figure 7.14 will be displayed.

It is not possible to edit the contents of a linked block within a model, because theactual block contents are included in the library only. However, it is possible to breaka library link after copying a block from the library, by selecting the option ‘BreakLibrary Link’ in the Edit menu. In that case, the placeholder containing the librarylink will be overwritten with the block’s actual contents – effectively creating a cloneof the block, and editing the block within the model will become possible. Since thisbreaks the library link, it will obviously not affect the contents of the library itself.

Unfortunately, the placeholder containing the library link will look exactly thesame as the original block in the library; the only visual difference is the link indica-tion in the mask-dialog, and that is only present if a mask dialog exists in the firstplace. Some subsystems from the FDC toolbox do not have a mask-dialog, eventhough they have been linked from a library. To make the user aware of the librarylinks in those cases, such linked, yet unmasked subsystems have been highlightedwith a light-blue colour.

Please be very careful when editing existing blocks in the FDC libraries: sincethey may be called by several other models, it is not recommended to alter their in-put/output definitions (e.g. increase the number of outputs), or change the namesof blocks within a library. The latter is important, because library links are defined

7.10. Summary of the model and library structure 113

by reference to the blocknames (changing blocknames in models doesn’t matter, be-cause in that case only the name of the link placeholders is modified). A save methodto implement big changes is to create a clone of the original block first, by copyingthe block and breaking its library link.

7.10 Summary of the model and library structure

Let’s summarize these last two sections before proceeding. All FDC models have amodular and layered structure, because of the use of subsystems and masked blocks.A mask interface hides the contents of a subsystem beneath an additional layer thatcan provides short block-information, a help-button with a link to extensive block-information, an indication that tells us whether we are dealing with the actual blockor a linked copy, and possibly also one or several parameter fields. It is possible tozoom in to masked subsystems by using the ‘Look Under Mask’ option in the Edit orcontext menus to ‘unmask’ these blocks.

Almost all subsystems from the FDC models have been sorted in libraries. Thelink status of masked subsystems is indicated in their mask-dialog window; linkedsubsystems which have not been masked are distinguished by a light-blue back-ground colour. Direct editing of these blocks within the models in which they areapplied is not possible, except when the library link is broken first, which will causethe editing to be limited to the new, local, copy of the block. Editing blocks within alibrary is possible after unlocking the library first.

The easiest way to open the required library is to follow the library link from themodel, but it is also possible to open libraries directly from the command-line. Inaddition, all FDC libraries can also be accessed via the main library FDCLIB.

Relevant help information for masked blocks will be shown in a webbrowser orin the MATLAB help browser if the Help button is clicked in the mask-dialog. Double-clicking the title block of a model or subsystem will have the same effect, whetherthe subsystem has been masked or not.

7.11 Colour conventions for the FDC models

In general, the blocks in FDC models use a simple black-on-white colour scheme,but there are some exceptions. In the previous section, we already saw that a light-blue background colour for subsystem blocks has been used to indicate that thosesubsystems are contained in a library. In addition, the following colours have beenused:

black-on-cyan (with shadow border):used for button-blocks, i.e. blocks that will start a related MATLAB utility whendouble-clicked,

black-on-yellow (no shadow border):used to indicate places where data is sent from the SIMULINK systems to the MAT-LAB workspace

black-on-yellow (with shadow border):used to highlight signal switches that require user-interaction,


blue-on-white (no shadow border):used for title blocks which do not link to additional help-information,

blue-on-white (with shadow border):used for title blocks that will reveal related help information in the webbrowseror the MATLAB help browser when double clicked; also used for the Mux blocksin the first level of the aircraft model, to indicate that double-clicking these blockswill reveal additional help-information about the muxed signals,

magenta-on-white:used to highlight the internal feedback-loops of the nonlinear aircraft model,

black-on-green:used to highlight Scope blocks and other blocks with similar plotting functions.

Additional colour combinations have been used for the autopilot models; these willbe discussed later in chapter 15.

7.12 Some cautions

Although you are encouraged to use, modify, and extend the FDC models and toolsfor your own experiments, it is important to be aware of the many interactions be-tween the various models, libraries, tools, and helpfiles, which may not always beobvious. As noted before, be especially careful when changing blocknames and/orediting existing blocks in libraries, to prevent inadvertently breaking library links ormismatching connections. When in doubt, it is safer to create a clone of the originalblock before doing any editing, by copying the block and breaking its library link.

For example, in the case of the system Beaver and its subsystem equivalents,changing the number of Inport and/or Outport blocks will cause connection prob-lems for the open-loop simulation models, the autopilot models, the interface to theaircraft trimming program, and the workspace input/output functions. Although itis not difficult to correcting these problems, it does require a lot of attention, espe-cially for users who are not yet fully familiar with the toolbox.

In order to maintain the integrity of the toolbox, it is advised always to keepsafety copies of the original files on your system, which will allow you to quickly re-store errors when necessary (of course, it is always possible to re-install the completepackage if things really go wrong). It is also recommended to use distinct filenamesfor your own adaptations of the FDC models and tools to prevent possible mix-ups inthe future. Don’t let that stop you from experimenting, though: this is Open Sourcesoftware for a reason!

Users who now decide to start working with the toolbox right away should notbe surprised if they are, at times, confronted with some disturbing error messages.Over the years the programs have been equipped with some basic error-trappingsubroutines, but that doesn’t make this toolbox entirely error-proof. If you are notkeen on reading before experimenting, it is recommended to at least study the rel-evant helpfiles and read chapter 13, which contains some examples of the practicaluse of this toolbox.

7.13. About the block and function reference chapters 115

7.13 About the block and function reference chapters

In the next three chapters, the SIMULINK implementation of the aircraft model, thewind and turbulence models, and the radio-navigation models will be discussedin detail. These chapters will list all subsystems and blocks in alphabetical order,providing a short description, a list of equations (or a list of subsystems and blocksfor subsystems which don’t contain any individual equations), lists of input andoutput signals1, an overview of the block or subsystem parameters, and an overviewof important connections to other blocks or subsystems.

The description of the elements from the aircraft model in chapter 8 also includesthe path in the aircraft model, starting with the interface level Beaver level 1, andthe location of the block-library containing the element, starting with FDCLIB. Forthe description of the wind and turbulence elements in chapter 9 and the radio-navigation elements in chapter 10 the locations in the main library FDCLIB and thewind or navigation libraries Windlib or Navlib will be included.

Chapters 11 and 12 describe the analytical functions and support utilities for theFDC toolbox. Together with the model reference chapters, this completes the ‘refer-ence guide’ for the basic FDC models and tools. Practical applications of the toolboxwill be elaborated later in chapter 13, and in chapters 14 and 15, which describe acase-study of the Beaver autopilot.

1To avoid signal clutter, the FDC models make extensive use of vector signals. If a vector signal isused as input to a block, this doesn’t necessarily mean that all elements from this vector are actuallyneeded; in general only a subset of these elements is used by the block equations.

Chapter 8

Aircraft model block reference

The previous chapter provided an introduction to the FDC software, describing theinstallation process and the general architecture of the models and libraries. In thischapter we will take a closer look at the dynamics model of the DeHavilland DHC-2Beaver aircraft, which is the core element of the FDC toolbox. First, the structure ofthis model will be outlined and compared with the theoretical basis from chapter 3.Next, all individual blocks and subsystems from the aircraft model will be describedin alphabetical order. Hereafter, chapters 9 and 10 will provide similar informationfor the wind, turbulence, and radio-navigation models.

8.1 The aircraft model and its subsystem equivalents

The SIMULINK implementation of the nonlinear aircraft model has been based onthe block-diagram structure from figure 3.2 of chapter 3. The resulting SIMULINK

model has been shown in figure 8.1. This model differs from figure 3.2 in that itgathers all output signals on the right-hand side of the block-diagram, which resultsin a stairway-like structure in which subsequent blocks are shifted to the right anddownwards. Also, the axis-transformations have been integrated in the forces andmoments blocks, and a separate block for computing additional observation varia-bles has been included directly below the subsystem ‘Aircraft equations of motion’.But despite these differences, the overall structure of figure 3.2 should be clearlyrecognisable in the SIMULINK model.

Apart from the aerodynamic and propulsive forces, all elements from figure 3.2are independent of the airplane under consideration. This is also true for the SI-MULINK model from figure 8.1, with the exception of a single aircraft-dependentcorrection block xdotcorr (Beaver) that is contained in the subsystem ‘Aircraft Equa-tions of Motion (Beaver)’. Notice how all aircraft-dependent elements (which havecurrently been elaborated for the Beaver aircraft) have been distinguished by theirsuffix ‘(Beaver)’.

From left to right and from top to bottom we can distinguish the following blocksand subsystems in the SIMULINK model from figure 8.1:

• Airdata Group. This subsystem evaluates airdata equations and computes im-portant atmospheric properties such as temperature and pressure, which are

118 Chapter 8. Aircraft model block reference

required to determine the external forces and moments (and hence, to solvethe equations of motion).

• Aerodynamics Group (Beaver), Engine Group (Beaver), Gravity, and Fwind. Thesesubsystems determine the individual contributions to the external forces andmoments upon the airplane. Not surprisingly, the aerodynamic and propulsiveforces and moments are currently valid for the Beaver aircraft only.

• FMsort. This block computes the body-axes components of the resulting forcesand moments, and it stores the results in a separate force vector and momentvector.

• Aircraft Equations of Motion (Beaver). The core element of the nonlinear aircraftmodel. This subsystem first determines the time-derivative of the state vectorby evaluating the differential equations from section 2.5. Next, this vector issent through an Integrator block, to find the state vector itself. The subsystem isaircraft-dependent in that it contains a block which corrects the time-derivativeof the state vector for a term that was omitted from the aerodynamic model(this is related to the implicit nature of the state equations; see section 3.4 andthe description of the block xdotcorr (Beaver) for more information).

• Additional Outputs. This subsystem computes some additional observation sig-nals that are not needed to solve the equations of motion, yet may be useful forpost-simulation analysis of the airplane responses.

• Hlpfcn. This block computes some frequently used sines and cosines of angularvalues from the state vector. It has been located in the internal feedback-loopof the aircraft model, because of the trivial nature of the results. The feedback-loop itself is necessary, because the external forces and moments that determinethe movements of the airplane are themselves dependent upon the airplanemotions.

On the left-hand side of figure 8.1, we see the external inputvectors uaero and uprop,which contain the control inputs to the aerodynamic and engine models (control sur-face deflections, engine RPM, and engine manifold pressure). The third inputvectoris uwind, which is used to account for unsteady atmosphere; it contains the wind ve-locity components along the aircraft’s body-axes and the time-derivatives of thesevelocities. This vector can include both deterministic stochastic terms (i.e. wind andatmospheric turbulence). See table D.3 in appendix D for the exact definitions of theinput vectors.

The output vectors from the blocks in figure 8.1 are all gathered on the left-handside of this model. In total there are 18 output vectors, which have been defined intable D.2 of appendix D.

In order to handle the input/output functions for this flight simulation model, an ad-ditional system level was introduced. This system level makes sure that the relevantinput and output signals are logged into the MATLAB workspace, and it providesconnections for external models and access points for MATLAB functions.

In the system hierarchy, this ‘interface level’ forms an additional layer on top ofthe actual aircraft model from figure 8.1, which is why this level will be designated‘Beaver Level 1’ in the remainder of this report. The actual aircraft model is consid-

8.1. The aircraft model and its subsystem equivalents 119

yhlp

x

xdot

18yad3

17yad2

16yad1

15yatm

14Fwind

13Fgrav

12FMprop

11FMaero

10Cprop

9Caero

8yacc

7ypow

6yfp

5ydl

4yuvw

3ybvel

2xdot

1x

Fwind

Wind forces

Gravity

Gravity forces

x

uprop

yatm

yad1

ypow

Cprop

FMpropEngine Group (Beaver)

x

yatm

yad1

yad2

yad3

Airdata Group

Ftot

Mtot

uwind

yatm

yhlp

x

xdot

ybvel

Aircraft Equationsof Motion (Beaver)

x

uaero

yad1

ydl

Caero

FMaero

AerodynamicsGroup (Beaver)

x

xdot

yhlp

Ftot

Fgrav

yfp

yuvw

yacc

Additional outputs

FMsort

Add/sort forcesand moments

1

hlpfcn

(co)sines ofalpha, beta,

psi, theta, phi

1

3uwind

2uprop

1uaero

Figure 8.1: Block-diagram of the main level of the aircraft model (Beaver Level 2)

16rb/2V

15qc/V

14pb/2V

13Hdot

12H

11ye

10xe

9phi

8theta

7psi

6r

5q

4p

3beta

2alpha

1V

time

To Workspace

In To Workspace Out To Workspace

Mux

Double-click for info!

Muxclick2x forinfo!

Mux

Mux

Mux

Demux

Demux

Demux

Clock

DeHavillandDHC-2 Beaverdynamics and

output equations

12wwdot

11vwdot

10uwdot

9ww

8vw

7uw

6pz

5n

4deltaf

3deltar

2deltaa

1deltae

uwind

uprop

uaero

xdot

ydl

x

Figure 8.2: Block-diagram of the interface level of the aircraft model (Beaver Level 1)


ered the ‘main level’ of the airplane model, because it contains the actual systemdynamics. The full name of this subsystem is ‘DeHavilland DHC-2 Beaver dynamicsand output equations’, but for obvious reasons we will use the shorthand notation‘Beaver Level 2’.

The toolbox includes three variants of the airplane model: a stand-alone modelof the Beaver aircraft (called Beaver), and two ‘subsystem equivalents’ of this model.The stand-alone model is used for model analysis from the MATLAB environment(simulations, trimming, linearisation), while the subsystem equivalents are intendedto be used as subsystems within larger simulation models, such as the autopilot mod-els from chapter 15. All three variants call the subsystem Beaver Level 2, and they alluse the same input definitions.

The stand-alone model and the first subsystem equivalent use the I/O structurefrom figure 8.2; the second subsystem equivalent uses a slightly different outputstructure, creating two output vectors instead of 16 scalar output signals. From fig-ure 8.2 we can see that all inputs and outputs are sent to the MATLAB workspace,together with a clock signal that provides a corresponding time reference for post-simulation processing (e.g. trajectory plotting). Only a small subset of the outputshas been connected to the scalar Outport blocks in Beaver Level 1, visible on the right-hand side of figure 8.2.1 The current choice of output signals provides sufficientinformation for the autopilot simulation models from chapter 15.

8.2 The aircraft model block libraries

The blocks and subsystems from the aircraft model have been sorted six individualblocklibraries, which are directly accessible from the main FDC library FDCLIB:

1. Airdata, atmosphere,

2. Aerodynamics,

3. Engine forces and moments,

4. Gravity and wind forces,

5. Equations of motion,

6. Other (output-) equations.

Although these libraries are considered to be sublibraries of FDCLIB, they can alsobe accessed directly by typing fdclibi in the command-line, where i represents thenumber of the blocklibrary according to the list above.

In addition, FDCLIB contains a direct link to the system Beaver (the stand-aloneversion of the aircraft model), and a link to a sublibrary containing the subsystemequivalents of Beaver. The stand-alone model and this sublibrary can also be openeddirectly from the command-line by typing beaver or fdclib10, respectively. In fig-ure 8.3, the main FDC library has been shown, with highighted links to the aircraftblocklibraries and the complete aircraft models. FDCLIB can be opened from thecommand-line by typing fdclib.

1The reason for using scalar Inport and Outport blocks in the interface level of the aircraft modelwas that older versions of SIMULINK did not allow the use of vector inputs or outputs in top-levels ofsystems. See the description of Beaver Level 1 for more information.

8.2. The aircraft model block libraries 121

Figure 8.3: Main FDC library with highlighted aircraft model sublibraries

The remainder of this chapter (pages 122 to 164) provides a detailed descriptionof all blocks and subsystems from the nonlinear aircraft model, i.e. the systemBeaver or one of its subsystem equivalents. The blocks have been sorted in al-phabetical order; their locations have been referenced with respect to the systemBeaver and the main FDC library FDCLIB.


12 ODEs Beaver level 1 / Beaver level 2 / Aircraft Equations of Motion / 12 ODEs

Main FDC library / Equations of motion

TypeAircraft-independent subsystem, essential for solving the equations of motion. The sub-system is not masked.

DescriptionThe subsystem 12 ODEs contains the twelve non-linear Ordinary Differential Equationsthat describe the aircraft dynamics. The equations are valid for all rigid bodies, assum-ing a flat, non-rotating Earth; see chapter 2 for a detailed theoretical discussion. Thetime-derivatives of the twelve state variables are nonlinear functions of the state varia-bles themselves and of the external forces and moments. The latter depend upon thestate variables, external control inputs, and external disturbances affecting the airplane.

Subsystems and/or blocksThe subsystem 12 ODEs contains four blocks:

Vabdot computes time-derivatives of true airspeed, angle of attack, and sideslip angle,

pqrdot computes time-derivatives of the angular velocities along the body-axes of theaircraft,

Eulerdot computes time-derivatives of the Euler angles,

xyHdot computes time-derivatives of the coordinates and the altitude above sea-level.

Inputsx = [ V α β p q r ψ θ ϕ xe ye H ]T state vector, x

Ftot = [ Fx Fy Fz ]T total external forces, Ftot

Mtot = [ L M N ]T total external moments, Mtot

yhlp = [ cos α sin α cos β sin β tan β sin ψ cos ψ sin θ cos θ sin ϕ cos ϕ ]Tfrequently used sines and cosines, yhlp

ybvel∗ = [ u + uw v + vw w + ww ]T body-axes velocity components plus wind, ybvel∗

Outputsx = [ V α β p q r ψ θ ϕ xe ye H ]T time-derivative of state vector, xdot

Note: the vector x that leaves the subsystem 12 ODEs must be corrected for the directcontribution of β to the aerodynamic side force Ya. This correction is taken into accountby the block xdotcorr (Beaver), which has been described later.

ParametersThe block Vabdot reads the parameter vector GM1 from the MATLAB workspace; the blockpqrdot requires the matrix GM2. The definitions of GM1 and GM2 can be found in ap-pendix C. These variables can be loaded from the file AIRCRAFT.DAT, using the utilityDATLOAD (see section 12.4.2). If this datafile has somehow inadvertently been deleted, itcan be re-created by running the program MODBUILD (see section 12.6.1).

Connectionsin: x comes from the block Integrator; Ftot and Mtot come from FMsort; yhlp comes from

Hlpfcn; ybvel∗ is the sum of the output from uvw and the wind velocity components

from the external input vector uwind.

out: x (not corrected for the implicit nature of the β-equation) is connected to the blockxdotcorr (Beaver).

Type browse 12odes at the command-line for on-line help.


Accel Beaver level 1 / Beaver level 2 / Additional Outputs / Accel

Main FDC library / Other (output-) equations

TypeAircraft-independent masked subsystem block, not essential for solving the equations ofmotion.

DescriptionThe block Accel computes some accelerations and specific forces (outputs of accelerome-ters) in the aircraft’s center of gravity. These output variables are useful for several FCSdesign tasks, e.g. turn-coordination by means of feedback of the specific force along theYB-axis, or manoeuvre load limiting. However, these variables are not required to actuallysolve the equations of motion themselves! Computing accelerations outside the center ofgravity will require additional terms, which are not taken into account in this block; referto ref.[14] for more details.

EquationsThe equations used by the block Accel have been discussed in some more detail in sec-tion 3.6.

• Kinematic accelerations ax,k, ay,k, and az,k along the body-axes, measured in the vehi-cle’s c.g.:

ax,k =1g0

(u + qw− rv) =Fx

W

ay,k =1g0

(v + ru− pw) =Fy

W

az,k =1g0

(w + pv− qu) =Fz

WThese accelerations are measured in units of g which explains why the terms have beendivided by g0. W = m g is the total weight of the aircraft, measured in [N]. Note: thekinematic accelerations differ from the body-axes velocity rates u, v, and w, which arecomputed in the block uvwdot, because the latter do not contain the angular and trans-lational velocity cross-product terms.

• Outputs of body-axis accelerometers (specific forces) Ax, Ay, and Az, measured at thevehicle’s c.g.:

Ax = ax,k + sin θ = (Fx − Xgr) / WAy = ay,k − cos θ sin ϕ = (Fy −Ygr) / WAz = az,k + cos θ cos ϕ = (Fz − Zgr) / W

These specific forces are also measured in units of g.

InputsFtot = [ Fx Fy Fz ]T total external forces, Ftot

Fgrav = [ Xgr Ygr Zgr ]T gravity forces, Fgrav

Outputsyacc = [ Ax Ay Az ax,k ay,k az,k ]T specific forces and accelerations, yacc

ParametersAccel needs the parameter vector GM1 to be present in the MATLAB workspace, in orderto extract the mass m of the aircraft (the mass has been implemented as a parameter, i.e.it is assumed to remain constant during the relative short time intervals considered insimulations). The definition of GM1 can be found in appendix C. GM1 can be loadedfrom the file AIRCRAFT.DAT, using the utility DATLOAD (see section 12.4.2). If this datafile


has somehow inadvertently been deleted, it can be re-created by running the programMODBUILD (see section 12.6.1).

Connectionsin: Ftot comes from the block FMsort; Fgrav comes from Gravity.

out: yacc is not used by any other block from the aircraft model.

Type browse accel at the command-line for on-line help.


Additional Outputs Beaver level 1 / Beaver level 2 / Additional Outputs


TypeAircraft-independent subsystem, essential for solving the equations of motion. The sub-system is not masked.

DescriptionThe subsystem Additional Outputs contains some useful output equations which are notrequired to solve the state equations, and which do not logically fit in other subsystemsfrom the nonlinear aircraft model. The user is free to add other ‘additional output blocks’to this subsystem, or delete available blocks from this subsystem.However, it should be noted that the output signals from this subsystem are not meant tobe used as inputs to the forces and moments blocks or the equations of motion themselves.The ‘additional outputs’ may be functions of the state variables, their time-derivatives,external inputs and/or disturbances, or outputs from other subsystems from the aircraftmodel.1

Subsystems and/or blocksThe subsystem Additional Outputs contains three blocks:

Accel computes specific forces (outputs of accelerometers) and kinematic accelerations,

Flpath computes some flight-path related variables,

uvwdot computes the time-derivatives of the body-axes velocity components.


x = [ V α β p q r ψ θ ϕ xe ye H ]T time-derivative of state vector, xdot



Fgrav = [ Xgr Ygr Zgr ]T gravity forces, Fgrav

Outputsyfp = [ γ fpa χ Φ ]T flight-path variables, yfp

yuvw = [ u v w ]T time-derivatives of body-axes velocities, yuvw

yacc = [ Ax Ay Az ax,k ay,k az,k ]T specific forces and accelerations, yacc

ParametersThe block Accel reads the parameter vector GM1 from the MATLAB workspace; the blockFlpath requires the initial value of the state vector, xinco. GM1 can be loaded from thefile AIRCRAFT.DAT, using the utility DATLOAD (see section 12.4.2); its definition can befound in appendix C. If this datafile has somehow inadvertently been deleted, it can bere-created by running the program MODBUILD (see section 12.6.1). The initial value of thestate vector can be computed using the aircraft trim program ACTRIM (see section 11.1),or loaded from file using the utility TRILOAD (see section 12.4.2).

1Since the outputs from Additional Outputs are not involved in the solution of the state equationsthemselves, the use of time-derivatives of state variables within this subsystem does not yield algebraicloops (see section section 6.4.1). However, if outputs from this subsystem are fed back to the input-side of the aircraft model, e.g. via an autopilot control loop, an algebraic loop may inadvertently becreated. This can cause simulations to slow down considerably, and such an algebraic loop may be toocomplicated for SIMULINK to solve altogether. For this reason, feeding back ‘additional outputs’ intothe aircraft model should be prevented.


Connectionsin: x comes from the block Integrator; x comes from xfix; yhlp comes from Hlpfcn; Ftot

comes from FMsort; Fgrav comes from Gravity.

out: yfp from Flightpath, yuvw from uvwdot, and yacc from Accel are not connected to anyother block in the aircraft model.

Type browse moreouts at the command-line for on-line help.


Aerodynamics Group (Beaver) Beaver level 1 / Level 2 / Aerodynamics Group (Beaver)

Main FDC library / Aerodynamics

TypeAircraft-dependent subsystem, essential for solving the equations of motion. The subsys-tem is not masked.

DescriptionThe subsystem Aerodynamics Group (Beaver) contains blocks for computing the aerody-namic forces and moments that act on the aircraft under consideration. In this casethe aerodynamic model is valid for the DHC-2 Beaver aircraft. It uses model data fromref.[34] (see also section 3.3.1). Notice that the subsystem Aerodynamics Group does notcompute propeller slipstream related contributions to the aerodynamic forces and mo-ments; that task is performed by the subsystem Engine Group instead.

Subsystems and/or blocksThe subsystem Aerodynamics Group (Beaver) contains three blocks:

Aeromod computes dimensionless aerodynamic force and moment coefficients for theaircraft under consideration (currently Aeromod contains the aerodynamic mo-del of the Beaver from ref.[34], which has been described in section 3.3.1),

Dimless computes dimensionless angular velocities,FMdims converts the dimensionless force and moment coefficients to dimensional for-

ces and moments.

Since the block Aeromod (Beaver) is aircraft-dependent, it needs to be replaced if the userwants to implement a model of a different aircraft in the FDC framework. However, ifthe new aircraft model also uses different definitions of the non-dimensional angular ve-locities, it may be more convenient to replace the complete subsystem Aerodynamic Groupinstead. Either way, this modular construction allows the user to build a comprehensiveSIMULINK library of aerodynamic models.


uaero = [ δe δa δr δ f ]T aerodynamic control inputs, uaero

yad1 = [ a M qdyn ]T basic airdata variables, yad1

Outputs

ydl = [ pb2V

qcV

rb2V ]T dimensionless angular velocities, ydl

Caero = [ CXa CYa CZa Cla Cma Cna ]T aerodynamic force and moment coefficients, Caero

FMaero = [ Xa Ya Za La Ma Na ]T dimensional aerodynamic forces and moments, FMaero

ParametersThe block Dimless and the block FMdims read the parameter-vector GM1 from the MAT-LAB workspace; the block Aeromod (Beaver) needs the parameter-matrix AM. The defin-itions of these variables can be found in appendix C. The variables can be loaded fromthe file AIRCRAFT.DAT, using the utility DATLOAD (see section 12.4.2). If this datafile hassomehow inadvertently been deleted, it can be re-created by running the program MOD-BUILD (see section 12.6.1).

Connectionsin: x comes from the block Integrator; uaero is an external input vector containing aero-

dynamic control inputs; yad1 comes from the block Airdata1.out: ydl from Dimless is used by the block Aeromod; Caero from Aeromod is used by

FMdims; FMaero from FMdims is used by the block FMsort.Type browse aerogrp at the command-line for on-line help.


Aeromod (Beaver) Beaver level 1 / Beaver level 2 / Aerodynamics Group / Aeromod (Beaver)


TypeAircraft-dependent masked subsystem block, essential for solving the equations of mo-tion.

DescriptionThe block Aeromod (Beaver) contains the aerodynamic model of the DHC-2 Beaver air-craft. The model is based on ref.[34], which expresses the aerodynamic forces and mo-ments in terms of nonlinear polynomial functions of state variables and external aerody-namic control inputs. This block needs to be updated if one wishes to implement a modelof a different aircraft within the FDC framework. Thanks to the black-box structure ofAeromod, it is relatively easy to change the structure of the equations if necessary, e.g. toincorporate look-up table functions, which often define the aerodynamic equations fordifferent airplane models.

Note: Aeromod (Beaver) does not take into account contributions to the forces and mo-ments due to the propeller slipstream. This is done in the masked subsystem block Eng-mod within the subsystem Engine Group.

EquationsThe aerodynamic force and moment coefficients of the Beaver are expressed in terms ofnonlinear polynomial functions of the state variables and aerodynamic control inputs.The model includes longitudinal-lateral cross-coupling effects, as well as unsteady aero-dynamics, but it does not take into account the influence of compressibility, as airspeed isassumed to be low [34]. The equations have been described in more detail in section 3.3.1.

• Coefficients of the aerodynamic forces and moments, measured in the body-fixed refer-ence frame:

CXa = CX0 + CXα α + CXα2 α2 + CX

α3 α3 + CXq

qcV

+ CXδrδr + CXδ f

δ f + CXαδ fαδ f


p b2V

+ CYr

rb2V

+ CYδaδa + CYδr

δr + CYδrαδrα

(+CYβ

βb2V

)CZa = CZ0 + CZα α + CZ

α3 α3 + CZq

qcV

+ CZδeδe + CZ

δe β2 δeβ2 + CZδ fδ f + CZαδ f

αδ f

Cla = Cl0 + Clββ + Clp

p b2V

+ Clrrb2V

+ Clδaδa + Clδr

δr + Clδaαδaα

Cma = Cm0 + Cmα α + Cmα2 α2 + Cmq

qcV

+ Cmδeδe + Cm

β2 β2 + Cmr

rb2V

+ Cmδ fδ f

Cna = Cn0 + Cnββ + Cnp

p b2V

+ Cnr

rb2V

+ Cnδaδa + Cnδr

δr + Cnq

qcV

+ Cnβ3 β3

The coefficients of the polynomials represent the stability and control derivatives of theBeaver; they have been listed in table B.3 of appendix B. A closer look at the internals ofthe block Aeromod (Beaver) reveils that the polynomial evaluation has been implementedin practice by means of a multiplication of the vector:[

1 α α2 α3 β β2 β3 pb2V

qcV

rb2V

δe δa δr αδ f αδr αδa δeβ2 0]T

with the constant parameter matrix AM in which the stability and control derivatives ofthe Beaver are contained.

Notice that the direct contribution of the time-derivative of the sideslip angle β to theaerodynamic side-force coefficient CYa has not been taken into account in this block: the


last element of the multiplication vector equals zero instead of βb/2V, i.e. the bracketedterm in the CYa equation is neglected by Aeromod (Beaver)! This was necessary in order toprevent the β equation from becoming implicit, which would have yielded an algebraicloop in the simulation model (see section 6.4.1). The error which results from neglectingthis term is corrected in the separate block xdotcorr.



ydl = [ pb2V

qcV


OutputsCaero = [ CXa CYa CZa Cla Cma Cna ]T aerodynamic force and moment coefficients, Caero

ParametersThe block Aeromod reads the parameter matrix AM from the MATLAB workspace. AMcontains the stability and control coefficients of the Beaver; see appendix C for its exactdefinition. This matrix can be loaded from the file AIRCRAFT.DAT, using the utility DAT-LOAD (see section 12.4.2). If this datafile has somehow inadvertently been deleted, it canbe re-created by running the program MODBUILD (see section 12.6.1).

Connectionsin: x comes from the block Integrator; uaero is an external input vector, containing the

aerodynamic control inputs; ydl comes from Dimless.

out: Caero is connected to FMdims.

Type browse aeromod at the command-line for on-line help.


Aircraft Equations of Motion (Beaver) Level 1 / Level 2 / Aircraft Equations of Motion

Main FDC library / Equations of Motion

TypeAircraft-independent subsystem, except for the block xdotcorr (Beaver), essential for solv-ing the equations of motion. The subsystem is not masked.

DescriptionThe subsystem Aircraft Equations of Motion (Beaver) contains the generic nonlinear six-degree-of-freedom rigid-body equations of motion. It determines the time-derivatives ofthe state variables from the aircraft model, and the time-trajectories of the state variablesthemselves. Aircraft Equations of Motion (Beaver) contains one aircraft-dependent element:the block xdotcorr (Beaver) is needed to correct the time-derivative of the sideslip anglefor the implicit nature of the sideforce equation in the aerodynamic model. Because ofthis, this subsystem is not entirely aircraft-independent; the current implementation hasbeen tailored to the DeHavilland DHC-2 Beaver.

Subsystems and/or blocksThe subsystem Aircraft Equations of Motion (Beaver) contains two blocks:

uvw computes the body-axes velocity components as a function of the true air-speed, angle of attack, and sideslip angle,

xdotcorr applies corrections to the time-derivatives of the state variables in order to takeinto account the implicit nature of the aerodynamic forces and moments model(the current implementation is valid for the Beaver model, where the time-derivative of the sideslip angle is corrected to account for the contribution ofβ to the aerodynamic sideforce Ya).

In addition, Aircraft Equations of Motion (Beaver) contains the subsystem:

12 ODEs contains the state equations, which express the time-derivatives of the statevariables in terms of the external forces and moments, and the state variablesthemselves.

An Integrator-block is used determine the time-trajectories of the state variables as a func-tion of their time-derivatives and initial condition.

InputsFtot = [ Fx Fy Fz ]T total external forces, Ftot


uwind = [ uw vw ww uw vw ww ]T wind velocity components along body-axesand their time-derivatives, uwind

yatm = [ ρ ps T µ g ]T basic atmospheric properties, yatm


Outputsx = [ V α β p q r ψ θ ϕ xe ye H ]T state vector, x


ybvel = [ u v w ]T body-axes velocity components, ybvel

ParametersThe block xdotcorr (Beaver) reads the parameter matrix AM and the vector GM1 from theMATLAB workspace. The subsystem 12 ODEs needs the parameter vector GM1 and thematrix GM2. The definitions of these variables can be found in appendix C. The variables


can be loaded from the file AIRCRAFT.DAT, using the utility DATLOAD (see section 12.4.2).If this datafile has somehow inadvertently been deleted, it can be re-created by runningthe program MODBUILD (see section 12.6.1). The block Integrator requires the initial valueof the state vector, xinco, which can be computed using the aircraft trim program ACTRIM(see section 11.1), or loaded from file using the utility TRILOAD (see section 12.4.2).

Connectionsin: Ftot and Mtot come from FMsort; uwind is an external input containing wind and tur-

bulence velocities and their time-derivatives; yatm comes from Atmosph; yhlp comesfrom Hlpfcn.

out: x, which leaves the block Integrator, is connected to many other blocks in the air-craft model; x from xfix is connected to Accel, Flpath, and uvwdot; ybvel from uvw isconnected to xyHdot.

Type browse eqmotion at the command-line for on-line help.


Airdata1 Beaver level 1 / Beaver level 2 / Airdata Group / Airdata1

Main FDC library / Airdata, atmosphere

TypeAircraft-independent masked subsystem block, essential for solving the equations of mo-tion.

DescriptionThe block Airdata1 is used to compute some essential airdata variables. This informationis usually required to be able to compute the aerodynamic and propulsive forces andmoments, and hence, to solve the equations of motion. For the Beaver model, only thedynamic pressure qdyn is actually needed to solve the state equations, but models of fasterflying aircraft usually also require the Mach number M. Other airdata (-related) equationshave been implemented in the blocks Atmosph, Airdata2, and Airdata3.

EquationsThe equations used by the block Airdata1 have been discussed in more detail in sec-tion 3.5.

• Dynamic pressure qdyn, [kg m−2]:

qdyn = 12 ρV2

• Speed of sound a, [ms−1]:

a =√

γRT

where γ = 1.4 is the ratio of specific heats of air with constant pressure and constantvolume, respectively, and R = Ra/M0 = 287.05 JK−1kg−1 is the specific gas constant ofthe air (Ra = 8314.32JK−1kmol−1 is the molar gas constant, and M0 = 28.9644 kg kmol−1

is the molecular weight of the air at sea level).

• Mach number M, [ – ]:

M =Va



Outputsyad1 = [ a M qdyn ]T basic airdata variables, yad1

ParametersAll parameters for Airdata1 are defined within the block itself; Airdata1 does not use anyparameters from the MATLAB workspace.

Connectionsin: x comes from the block Integrator; yatm comes from Atmosph.

out: yad1 is connected to the blocks Airdata2 and Airdata3.

Type browse airdata1 at the command-line for on-line help.




TypeAircraft-independent masked subsystem block, in general not required for solving theequations of motion.

DescriptionThe block Airdata2 is used to compute the impact pressure qc, calibrated airspeed Vc, andequivalent airspeed Ve. While these airdata parameters are important for certain applica-tions (e.g. for analysing windtunnel measurements or flight tests), they are generally notrequired to solve the equations of motion. Therefore, in principle, Airdata2 can safely bedeleted from the SIMULINK model without affecting the solutions of the ODEs (althoughthis would introduce practical problems, due to broken connections). The equations fromthis block are independent of the aircraft under consideration. Other airdata (-related)equations have been implemented in the blocks Atmosph, Airdata1, and Airdata3.


• Impact pressure qc, [Nm−2]:

qc = ps

(1 +

γ− 12

M2) γ

γ−1− 1

where γ = 1.4 is the ratio of specific heats of air with constant pressure and constantvolume respectively.

• Calibrated airspeed Vc, [ms−1]:

Vc =

√√√√√ 2γ

γ− 1p0

ρ0

(

1 +qc

p0

) γ−1γ

− 1

where p0 = 101325 Nm−2 is the air pressure at sea level, and ρ0 = 1.225 kgm−3 is the airdensity at sea level.

• Equivalent airspeed Ve, [ms−1]:

Ve = V√

ρ

ρ0=

√2qdyn

ρ0

Inputsyatm = [ ρ ps T µ g ]T basic atmospheric properties, yatm


Outputsyad2 = [ qc Ve Vc ]T additional airdata (-related) variables, yad2

ParametersAll parameters for Airdata2 are defined within the block itself; Airdata2 does not use anyparameters from the MATLAB workspace.

Connectionsin: yatm comes from the block Atmosph; yad1 comes from Airdata1.

out: yad2 is not connected to any other block in the aircraft model.





TypeAircraft-independent masked subsystem block, in general not required for solving theequations of motion.

DescriptionThe block Airdata3 is used to compute the Reynolds number Rc, which refers to the meanaerodynamic chord of the aircraft, the Reynolds number per unit length Re, and the totaltemperature Tt. While these airdata parameters are important for certain applications (e.g.for analysing windtunnel measurements or flight tests), they are generally not required tosolve the equations of motion. Therefore, in principle, Airdata3 can safely be deleted fromthe SIMULINK model without affecting the solutions of the ODEs (although this wouldintroduce practical problems, due to broken connections). The equations from this blockare independent of the aircraft under consideration. Other airdata (-related) equationshave been implemented in the blocks Atmosph, Airdata1, and Airdata2.


• Total temperature Tt, [K]:

Tt = T(

1 +γ− 1

2M2)

• Reynolds number Rc, [ – ]:

Rc =ρVc

µ

• Reynolds number per unit length Re, [m−1]:

Re =ρVµ




Outputsyad3 = [ Tt Re Rc ]T additional airdata (-related) variables, yad3

ParametersThe block Airdata3 reads the parameter vector GM1 from the MATLAB workspace in orderto extract the mean aerodynamic chord c. The definition of GM1 can be found in appen-dix C. The variable can be loaded from the file AIRCRAFT.DAT, using the utility DATLOAD(see section 12.4.2). If this datafile has somehow inadvertently been deleted, it can bere-created by running the program MODBUILD (see section 12.6.1).

Connectionsin: x comes from the block Integrator; yatm comes from Atmosph; yad1 comes from Air-

data1.

out: yad3 is not connected to any other block in the aircraft model.



Airdata Group Beaver level 1 / Beaver level 2 / Airdata Group


TypeAircraft-independent subsystem, part of which is essential for solving the equations ofmotion. The subsystem is not masked.

DescriptionThe subsystem Airdata Group is used to compute airdata (-related) variables. Some ofthese data are required to solve the equations of motion, while other data is provided asadditional ‘nice to know’ information.

Subsystems and/or blocksThe subsystem Airdata Group contains four blocks:

Atmosph computes basic atmospheric properties (air-temperature, pressure, density) us-ing the ICAO Standard Atmosphere model, as well as the dynamic viscosityof the air and the gravitational acceleration,

Airdata1 computes the most important airdata variables which in general are requiredto solve the equations of motion of an aircraft,

Airdata2 computes additional airdata (-related) variables which may be useful for suchpurposes as comparing simulations with real flight experiments, windtunnelmeasurements, etc.,

Airdata3 computes some more additional airdata (-related) variables.

The blocks Airdata2 and Airdata3 do not affect the solution of the aircraft equations ofmotion, and can therefore be safely deleted from the model (except that this would requirereadjustment of several connecting lines as well). While this might have been useful tospeed up simulations and free memory on slow computer systems in the past, there areno convincing reasons to do so today. In any case, the blocks Atmosph and Airdata1 arealways required to solve the state equations.


Outputsyatm = [ ρ ps T µ g ]T basic atmospheric properties, yatm


yad2 = [ qc Ve Vc ]T additional airdata (-related) variables, yad2

yad3 = [ Tt Re Rc ]T additional airdata (-related) variables, yad3

ParametersThe parameters for the blocks Airdata1, Airdata2, and Atmosph are all defined internally.Airdata3 reads the parameter vector GM1 from the MATLAB workspace; its definition canbe found in appendix C. GM1 can be loaded from the file AIRCRAFT.DAT, using the utilityDATLOAD (see section 12.4.2). If this datafile has somehow inadvertently been deleted, itcan be re-created by running the program MODBUILD (see section 12.6.1).

Connectionsin: x comes from the block Integrator (subsystem Aircraft Equations of Motion).

out: yatm, which leaves the block Atmosph is connected to the blocks Airdata1, Airdata2,and Airdata3, Power, Gravity, and xdotcorr (Beaver); yad1 from Airdata1 is connectedto Airdata2, Airdata3, and FMdims; yad2 from Airdata2 and yad3 from Airdata3 are notconnected to any other block in the aircraft model.

Type browse adgrp at the command-line for on-line help.


Atmosph Beaver level 1 / Beaver level 2 / Airdata Group / Atmosph



DescriptionThe block Atmosph is used to compute some basic atmospheric properties, using the ICAOStandard Atmosphere model (see for instance ref.[30] for a description of that model). Italso computes the local value of the gravitational acceleration g and the dynamic viscosityµ. The outputs from Atmosph are used (amongst others) by the block Airdata1 for thecalculation of airdata variables that must be known to solve the equations of motion, andby the blocks Airdata2 and Airdata3, for the computation of additional airdata (-related)variables.

EquationsThe equations used by the block Atmosph have been discussed in more detail in sec-tion 3.5.

• Air temperature T in the troposphere, according to the ICAO Standard Atmospheremodel, [K]:

T = T0 + λH

where T0 = 288.15 K is the air temperature at sea level and λ = −0.0065 Km−1 is the tem-perature lapse-rate in the troposphere. In this equation the small difference betweenthe geometrical altitude h and the geopotential altitude H has been neglected in viewof the relatively low altitudes considered; see section 3.5 for more details.

• Static air pressure in Standard Atmosphere ps, [Nm−2]:

ps = p0

(T0

T

) gλR

where p0 = 101325 Nm−2 is the air pressure at sea level and R = Ra/M0 = 287.05JK−1kg−1 is the specific gas constant of the air (Ra = 8314.32JK−1kmol−1 is the molargas constant, and M0 = 28.9644 kg kmol−1 is the molecular weight of the air at sealevel).

• Air density ρ, [kgm−3], according to the gas law for ideal gasses:

ρ =ps

RT• Coefficient of the dynamic viscosity µ, [kg m−1s−1], according to Sutherland’s equa-

tion [30]:

µ =1.458 · 10−6 T

32

T + 110.4• Gravitational acceleration g, [ms−2]:

g = g0

(REarth

REarth + h

)2

where g0 = 9.80665 ms−2 is the gravitational acceleration at sea level and REarth =6371020 m is the radius of the Earth. Note: although this equation uses the radiusof the Earth, the state equations in the block 12 ODEs are still based on a flat-Earth mo-del! This equation only takes into account the altitude-dependency of the gravitationalacceleration.



Outputsyatm = [ ρ ps T µ g ]T basic atmospheric properties, yatm

ParametersAll parameters for Atmosph are defined within the block itself; Atmosph does not use anyparameters from the MATLAB workspace.

Connectionsin: x comes from the block Integrator.

out: yatm is connected to the blocks Airdata1, Airdata2, Airdata3, Power (Beaver), Gravity,and xdotcorr (Beaver)

Type browse atmosph at the command-line for on-line help.


Beaver level 1 Beaver level 1

Main FDC library / Complete system Beaver

TypeFirst level of the Beaver dynamics model, which provides connections to other SIMULINKsystems and an interface between the model and the MATLAB workspace.

DescriptionThe first level of the aircraft model (see figure 8.2) takes care of the input/output func-tions of the simulation model. It collects all input and output signals in vectors whichare sent to the MATLAB workspace by means of To Workspace blocks. A related timeline,which can be used for post-simulation analysis and processing of simulation data, is alsomade available. Furthermore, Beaver Level 1 contains a set of relevant Inport and Outportblocks, to allow the aircraft model to be connected to external SIMULINK systems, andto provide access points for analytical MATLAB functions (most noticably the trimmingfunctions).

There are twelve Inport blocks: six control inputs and six inputs representing atmos-pheric disturbances. On the output-side, only a relevant subset of the system outputshave been connected to Outport blocks, to prevent the ‘interface level’ from becoming toocluttered. This subset provides enough information for the autopilot simulation models,which will be discussed in chapter 15.

The aircraft model comes in three flavours: a stand-alone system, called Beaver, andtwo subsystem equivalents of this model. The stand-alone system is used for model-analysis from the MATLAB environment (simulations, trimming, linearisation), while thesubsystem equivalents are used as subsystems within larger simulation models. Thesevariants are virtually identical, except that one of the subsystem equivalents combinesthe output signals in two vectors, instead of using 16 individual scalar outputs.

It should be noted that the structure of this ‘interface level’ is actually a leftover from ear-lier incarnations of this toolbox, which were designed for earlier SIMULINK versions, thatdid not allow the use of vector inputs and outputs in top-levels of a system. Versions 1.0,1.1, and 1.2 of the FDC toolbox used a graphical ‘S-function’ to implement the aircraftmodel, i.e. an entirely separate SIMULINK system, which could be called by other models,if desired.

The advantage of this approach, compared to using ordinary subsystems, was thata single model could be called by several larger models, without having to duplicateany code. However, the feature to treat graphical models as ‘S-functions’ was droppedfrom SIMULINK 2 (nowadays, the term ‘S-function’ is used only to describe specially for-matted program functions, written in MATLAB, C, or Fortran). The current version ofthe FDC toolbox uses the newer SIMULINK library functionality to maintain a centralizedcopy of the aircraft model.

Subsystems and/or blocksThe first level of the aircraft model uses Mux and To Workspace blocks to collect the inputsand output signals, and send these to the MATLAB workspace. A Clock block providesa corresponding timeline for the simulation. Demux, Inport, and Outport blocks provideaccess points for external SIMULINK systems and MATLAB functions. The actual aircraftmodel has been implemented in a single subsystem, called ‘DeHavilland DHC-2 Beaverdynamics and output equations’, or shortly: Beaver Level 2.

InputsThe motions of the aircraft are affected by six control inputs (elevator, ailerons, rudder,flaps, engine RPM, and engine manifold pressure), and six inputs representing atmos-pheric disturbances (three wind velocity components, and their time-derivatives). Thesesignals have all been represented by scalar Inport blocks, and sorted by means of Muxblocks, to obtain the three external input vectors uaero, uprop, and uwind:



uprop = [ n pz ]T external propulsion inputs, uprop


OutputsThe time-trajectories of the above mentioned input signals are collected in the workspacevariable In, while the time-trajectories of all output signals from the subsystem BeaverLevel 2 are collected in the workspace variable Out. A clock signal is collected in theworkspace variable time, to provide a corresponding time-axis. In and Out are matriceswhose columns represent time-trajectories of the individual input or output signals, andwhose rows represent data-points; the number of data-points corresponds to the lengthof the vector time. See appendix D for the exact definitions of these variables.

A subset of the output signals is sent to the Outport blocks in this top-level, whichallow the model to be connected to external systems, or to be accessed by MATLAB func-tions. The subset of outputs includes the twelve state variables, the rate of climb/descent,and the dimensionless pitch rate, roll rate, and yaw rate; these outputs are extracted fromthe following output vectors from Beaver Level 2:

x = [ V α β p q r ψ θ ϕ xe ye H ]T state vector, x


ydl = [ pb2V

qcV


Note: the stand-alone model Beaver and one of the subsystem equivalents use scalarOutport blocks to send these output signals to the outside world. The second subsystemequivalent combines the state variables and the rate of climb/descent in a single outputvector, which is connected to the first Outport block, and sends the dimensionless angularvelocities to the second Outport block.

ParametersBeaver level 1 (or rather: Beaver Level 2) requires the variables AM, EM, GM1, GM2, andxinco to be defined in the MATLAB workspace. The definitions of these variables can befound in appendix C; they can be loaded from the file AIRCRAFT.DAT, using the utilityDATLOAD (see section 12.4.2). If this datafile has somehow inadvertently been deleted, itcan be re-created by running the program MODBUILD (see section 12.6.1).

The vector xinco contains the initial value of the state vector. A steady-state initialvalue can be computed using the aircraft trim routine ACTRIM (see section 11.1), or it canbe loaded into the MATLAB workspace from file, using TRILOAD (see section 12.4.2). Ofcourse, it is also possible to manually enter xinco, if required.

Furthermore, an optional vector xfix may be defined in the MATLAB workspace, toartificially fix certain states to their initial values; see the description of the block xfix foran explanation. If xfix is not present in the workspace when the aircraft model equationsare evaluated, it will automatically be set to its default value ones(1,12) by the block xfix.If it is desired to artificially fix certain states, xfix should be entered manually (it must bea vector of length 12, with all elements being either one or zero), or by running the utilityFIXSTATE (see section 12.6.2).

ConnectionsBeaver Level 1 is the interface level of the aircraft model, where all input and outputvectors are collected and sent to the MATLAB workspace. The Inport and Outport blocksprovide connections to external models and MATLAB functions.

Type browse level1 at the command-line for on-line help about this level of the aircraftmodel. Type browse inputs or browse outputs for help about the input/output defini-tions.


Beaver level 2 Beaver level 1 / Beaver level 2

Main FDC library / Complete system Beaver / Beaver level 2

TypeSecond level of the Beaver dynamics model. This masked subsystem contains the nonlin-ear differential equations, and a large range of output equations.

DescriptionThe full name of this second level in the aircraft model is ‘DeHavilland DHC-2 Beaver dy-namics and output equations’, which signifies that this is in fact the core module of thetoolbox (the first level of the aircraft model handles the workspace output functions andprovides an interface between the aircraft model and MATLAB). For sake of brevity, wewill refer to this subsystem as Beaver level 2 below. This subsystem organises the in-dividual elements from the nonlinear aircraft model in a block-diagram structure thatresembles figure 3.2 from chapter 3. See figure 8.1 for a picture of Beaver Level 2 itself.

Subsystems and/or blocksThe subsystem Beaver level 2 contains five non-masked subsystems:

• Additional outputs computes several useful output variables which are not required tosolve the equations of motion themselves (and hence, ‘additional’),

• Aerodynamics Group (Beaver) computes the aerodynamic forces and moments for theBeaver,

• Aircraft equations of motion (Beaver) contains the general differential equations for therigid-body dynamics and an aircraft-dependent block that corrects the time-derivativesof the state variables for the implicitness of the state equations,

• Airdata Group computes airdata (-related) variables,• Engine Group (Beaver) computes the propulsive forces and moments for the Beaver.

In addition, Beaver level 2 contains four masked blocks:

• FMsort adds all individual contributions to the external forces and moments, and splitsthis in a force-vector and a moment-vector,

• Fwind computes the contributions to the external forces and moments due to non-steady atmosphere (wind and turbulence),

• Gravity computes the gravitational forces along the aircraft’s body-axes,• Hlpfcn computes several sines and cosines, which are used multiple times by other

blocks from the aircraft model.

Inputsuaero = [ δe δa δr δ f ]T aerodynamic control inputs, uaero





ybvel = [ u v w ]T body-axes velocity components, ybvel

yuvw = [ u v w ]T time-derivatives of body-axes velocities, yuvw

ydl = [ pb2V

qcV


yfp = [ γ fpa χ Φ ]T flight-path variables, yfp

ypow = [ dpt P ]T engine power related variables, ypow


yacc = [ Ax Ay Az ax,k ay,k az,k ]T specific forces and accelerations, yacc


Cprop = [ CXp CYp Czp Clp Cmp Cnp ]T propulsive force and moment coefficients, Cprop

FMaero = [ Xa Ya Za La Ma Na ]T dimensional aerodynamic forces and moments, FMaero

FMprop = [ Xp Yp Zp Lp Mp Np ]T dimensional propulsive forces and moments, FMprop

Fgrav = [ Xgr Ygr Zgr ]T gravity force components along body-axes, Fgrav

Fwind = [ Xw Yw Zw ]T corrections to body-axes forces in nonsteady atmosphere, Fwind



yad2 = [ qc Ve Vc ]T additional airdata (-related) variables, yad2

yad3 = [ Tt Re Rc ]T additional airdata (-related) variables, yad3

ParametersSeveral blocks and subsystems from Beaver level 2 require the variables AM, EM, GM1,GM2, and xinco to be defined in the MATLAB workspace. The following list provides anoverview of the parameter requirements:

AM Aerodynamics Group (Beaver), Aircraft Equations of Motion (Beaver)

EM Engine Group (Beaver)

GM1 Additional Outputs, Aerodynamics Group (Beaver), Aircraft Equations of Motion(Beaver), Airdata Group, Engine Group (Beaver), Fwind, Gravity

GM2 Aircraft Equations of Motion (Beaver)

xfix Aircraft Equations of Motion (Beaver)

xinco Aircraft Equations of Motion (Beaver)

The definitions for AM, EM, GM1, and GM2 can be found in appendix C. These variablescan be loaded from the file AIRCRAFT.DAT, using the utility DATLOAD (see section 12.4.2).If this datafile has somehow inadvertently been deleted, it can be re-created by runningthe program MODBUILD (see section 12.6.1).

The vector xinco contains the initial value of the state vector. A steady-state initialvalue can be computed using the aircraft trim routine ACTRIM (see section 11.1), or it canbe loaded into the MATLAB workspace from file, using TRILOAD (see section 12.4.2). Ofcourse, it is also possible to manually enter xinco, if required.

The vector xfix is optional: if this variable is not present in the workspace when theaircraft model equations are evaluated, it will automatically be set to its default valueones(1,12) by the block xfix (which is contained in the subsystem Aircraft Equations ofMotion (Beaver). If it is desired to artificially fix certain states, xfix should be enteredmanually (it must be a vector of length 12, with all elements being either one or zero), orby running the utility FIXSTATE (see section 12.6.2).

Connectionsin: all input vectors are obtained from the interface level of the aircraft model (Beaver

level 1).

out: all output vectors from the aircraft model (except for some very trivial results suchas the help vector yhlp) are sent to the top-level of the aircraft model.

Type browse level2 at the command-line for on-line help.


Dimless Beaver level 1 / Beaver level 2 / Aerodynamics Group / Dimless



DescriptionThe block Dimless is used to obtain dimensionless roll, pitch, and yaw rates, which arerequired for the aerodynamic model of the Beaver. It should be noted that the equationsused to determine these dimensionless rotational velocities are typical for most modelsdeveloped by the Control and Simulation Division, Faculty of Aerospace Engineering,Delft University of Technology. Other sources may use different expressions, so be care-ful to verify these expressions before trying to implement a model of a different aircraftwithin the FDC structure. The equations themselves are independent of the aircraft underconsideration.

EquationsThe equations used by the block Dimless are straightforward:

• Non-dimensional roll rate:

p → p b2V

• Non-dimensional pitch rate:

q → qcV

• Non-dimensional yaw rate:

r → r b2V


Outputs

ydl = [ pb2V

qcV

rb2V ]T non-dimensional angular velocities, ydl

ParametersDimless needs the parameter vector GM1 to be present the MATLAB workspace, in orderto extract the wing span b and mean aerodynamic chord c. The definition of GM1 can befound in appendix C. GM1 can be loaded from the file AIRCRAFT.DAT, using the utilityDATLOAD (see section 12.4.2). If this datafile has somehow inadvertently been deleted, itcan be re-created by running the program MODBUILD (see section 12.6.1).


out: ydl is connected to the block Aeromod.

Type browse dimless at the command-line for on-line help.


Engine Group (Beaver) Beaver level 1 / Beaver level 2 / Engine Group (Beaver)

Main FDC library / Engine forces and moments

TypeAircraft-dependent subsystem, essential for solving the equations of motion. The subsys-tem is not masked.

DescriptionThe subsystem Engine Group (Beaver) contains blocks which determine the engine powerand compute the resulting forces and moments due to operation of the powerplant, in-cluding contributions of the propeller slipstream to the aerodynamic forces and moments.The subsystem is based on model data from ref.[34] (see also section 3.3.1), which is validfor the DeHavilland DHC-2 Beaver aircraft. The remainder of the aerodynamic modelhas been implemented in the subsystem Aerodynamics Group (Beaver).

Subsystems and/or blocksThe subsystem Engine Group (Beaver) contains three blocks:

Power computes the power of the engine and the dimensionless increase in air pres-sure across the plane of the propeller,

Engmod computes dimensionless force and moment coefficients which are caused bythe operation of the powerplant, including propeller slipstream effects,

FMdims converts the dimensionless force and moment coefficients to dimensional forcesand moments.





Outputsypow = [ dpt P ]T engine power related variables, ypow

Cprop = [ CXp CYp Czp Clp Cmp Cnp ]T propulsive force and moment coefficients, Cprop


ParametersThe block Engmod reads the engine model parameter matrix EM from the MATLAB work-space; the block FMdims requires the parameter vector GM1. The definitions of thesevariables can be found in appendix C. The variables can be loaded from the file AIR-CRAFT.DAT, using the utility DATLOAD (see section 12.4.2). If this datafile has somehowinadvertently been deleted, it can be re-created by running the program MODBUILD (seesection 12.6.1).

Connectionsin: x comes from the block Integrator; uprop is an external input vector containing the

engine control inputs; yatm comes from Atmosph; yad1 comes from Airdata1.

out: ypow from Power is connected to the block Engmod; Cprop from Engmod is connectedto FMdims; FMprop from FMdims is connected to FMsort.

Type browse enggrp at the command-line for on-line help.


Engmod (Beaver) Beaver level 1 / Beaver level 2 / Engine Group / Engmod (Beaver)



DescriptionThe block Engmod (Beaver) determines the propulsive forces and moments for the Beaveraircraft, using a model from ref.[34]. It computes the force and moment coefficients whichare caused by the operation of the powerplant (this includes the engine thrust, gyroscop-ical effects caused by the rotating propeller, and the influence of the propeller slipstreamupon the aerodynamic forces and moments), as a function of the dimensionless increasein air pressure across the working plane of the propeller. The latter signal is determinedby the separate block Power (Beaver).

Engmod (Beaver) needs to be updated if one wishes to implement a model of a differ-ent aircraft within the FDC framework. Thanks to its black-box structure, it is relativelyeasy to change the structure of the equations if necessary, e.g. to incorporate look-up ta-ble functions, to implement functions which are typical for a jet engine, or to increase thenumber of engines.

EquationsThe propulsive force and moment coefficients of the Beaver are expressed in terms ofnonlinear polynomial functions of the state variables and the dimensionless increase inpressure across the working plane of the propeller. The equations are based on ref.[34];see section 3.3.2 for more details.

• Propulsive force and moment coefficients measured in the body-fixed reference frame:

CXp = CXdptdpt + CXα dpt2

α dpt2

CYp = 0

CZp = CZdptdpt

Clp = Clα2dpt

α2dpt

Cmp = Cmdptdpt

Cnp = Cndpt3dpt3

The coefficients of the polynomials represent engine stability and control derivatives ofthe Beaver; they have been listed in table B.4 of appendix B. A closer look at the inter-nals of the block Engmod (Beaver) reveils that the polynomial evaluation has been imple-mented in practice by means of a multiplication of the vector:[

dpt dpt3 α · dpt2 dpt · α2]T

with the constant parameter matrix EM in which the engine stability and control deriva-tives of the Beaver are contained.


ypow = [ dpt P ]T engine power related variables, ypow

OutputsCprop = [ CXp CYp Czp Clp Cmp Cnp ]T propulsive force and moment coefficients, Cprop


ParametersEngmod needs the parameter matrix EM to be present in the MATLAB workspace, in orderto read out the stability and control coefficients of the engine forces and moments model.The definition of this matrix can be found in appendix C. EM can be loaded from the fileAIRCRAFT.DAT, using the utility DATLOAD (see section 12.4.2). If this datafile has some-how inadvertently been deleted, it can be re-created by running the program MODBUILD(see section 12.6.1).

Connectionsin: x comes from the block Integrator; ypow comes from Power.

out: Cprop is connected to FMdims.

Type browse engmod at the command-line for on-line help.


Eulerdot Beaver level 1 / Beaver level 2 / Aircraft Equations of Motion / 12 ODEs / Eulerdot


TypeAircraft-independent masked subsystem block, contains three (out of twelve) state equa-tions.

DescriptionThe block Eulerdot is used to compute the time-derivatives of the Euler angles, i.e. theyaw angle ψ, pitch angle θ, and roll angle ϕ. These three variables form a subset of thetwelve state variables of the nonlinear aircraft model.

EquationsThe equations used by the block Eulerdot have been discussed in some more detail insection 2.4.

• Time-derivatives of the Euler angles ψ, θ, and ϕ, [rad s−1]:


cos θ

θ = q cos ϕ− r sin ϕ

ϕ = p + ψ sin θ

Inputsueul = [ xT Ftot

T MtotT yhlp

T ]T input vector to Eulerdot, ueul

where:





Outputsyeul = [ ψ θ ϕ ]T time-derivatives of the Euler angles, yeul (part of x)

ParametersNone.

Connectionsin: x comes from the block Integrator; Ftot and Mtot come from the block FMsort; yhlp

comes from the block Hlpfcn.

out: yeul is muxed together with the time-derivatives of the other state variables into asingle vector x (not corrected for the implicit nature of the β-equation). This time-derivative of the state vector x is then connected to the block xdotcorr.

Type browse eulerdot at the command-line for on-line help.


Flpath Beaver level 1 / Beaver level 2 / Additional Outputs / Flpath


TypeAircraft-independent masked subsystem block, not essential for solving the equations ofmotion.

DescriptionThe block Flpath is used to compute some flight-path (-related) variables. These outputvariables are useful for flight path tracking, but are not required to actually solve theequations of motion themselves.

EquationsThe equations used by the block Flpath have been discussed in some more detail in sec-tion 3.6.

• Flight-path angle γ, [rad]:

γ = arcsin(

HV

)• Flight-path acceleration fpa, i.e. the acceleration in the direction of the true airspeed

vector V, [g]:

fpa =Vg0

with g0 = 9.80665 ms−1 the gravitational acceleration at sea level.• Azimuth angle χ, [rad]:

χ = β + ψ

• Bank angle Φ, [rad]:

Φ = arcsin(

sin ϕ cos θ)




Outputsyfp = [ γ fpa χ Φ ]T flight-path variables, yfp

ParametersNone.

Connectionsin: x comes from the block Integrator; x comes from 12 ODEs via the correction blocks

xdotcorr (Beaver) and xfix; yhlp comes from the block Hlpfcn.

out: yfp is not used by any other block from the aircraft model.

Type browse flpath at the command-line for on-line help.


FMdims Beaver level 1 / Beaver level 2 / Aerodynamics Group or Engine Group / FMdims

Main FDC library / Aerodynamics or Engine forces and moments


DescriptionThe block FMdims is used to obtain dimensional forces and moments from the dimension-less force and moment coefficients as determined by the aerodynamic model Aeromod(Beaver) and the propulsion model Engmod (Beaver). It should be noted that the rela-tion between the dimensionless coefficients and the corresponding forces and momentsis typical for most aircraft models from the Faculty of Aerospace Engineering of DelftUniversity of Technology; other sources may apply slightly different definitions.

EquationsThe equations used by the block FMdims have been discussed in some more detail insection 3.3.1.

• Dimensional forces, [N]:

Xa = CXa qdyn SYa = CYa qdyn SZa = CZa qdyn S

• Dimensional moments, [Nm]:

La = Cla qdyn S bMa = Cma qdyn S cNa = Cna qdyn S b

The index a denotes aerodynamic forces and moments, which corresponds to the use ofFMdims in the subsystem Aerodynamics Group; replace this by p for the propulsive forcesand moments, determined in the subsystem subsystem Engine Group.

Inputsyad1 = [ a M qdyn ]T basic airdata variables, yad1


or:Cprop = [ CXp CYp Czp Clp Cmp Cnp ]T propulsive force and moment coefficients, Cprop

OutputsFMaero = [ Xa Ya Za La Ma Na ]T dimensional aerodynamic forces and moments, FMaero

or:FMprop = [ Xp Yp Zp Lp Mp Np ]T dimensional propulsive forces and moments, FMprop

ParametersFMdims reads the parameter vector GM1 from the MATLAB workspace, in order to extractthe mean aerodynamic chord c, the wing span b, and the wing surface S. See appendix Cfor the exact definition of GM1. This vector can be loaded from the file AIRCRAFT.DAT,using the utility DATLOAD (see section 12.4.2). If this datafile has somehow inadvertentlybeen deleted, it can be re-created by running the program MODBUILD (see section 12.6.1).

Connectionsin: yad1 comes from the block Airdata1; Caero comes from Aeromod (Beaver); Cprop comes

from Engmod (Beaver).


out: FMaero or FMprop are connected to FMsort.

Type browse fmdims at the command-line for on-line help.


FMsort Beaver level 1 / Beaver level 2 / FMsort



DescriptionThe block FMsort is used to determine the sum of all contributions to the external forcesand moments, and sort the results in a force-vector and moment-vector. The FDC modelof the Beaver aircraft takes into account aerodynamic forces and moments, propulsiveforces and moments, gravitational forces, and wind-corrections. These contributions aredetermined by the blocks Aerodynamics Group (Beaver), Engine Group (Beaver), Gravity,and Fwind, respectively. It is relatively straightforward to include additional terms, suchas landing gear forces or forces caused by sudden weight-changes of the airplane, byincluding the appropriate submodels and editing FMsort accordingly.

EquationsThe equations used by the block FMsort are straightforward:

• Resulting forces along the body-axes, [N]:

Fx = Xa + Xp + Xgr + XwFy = Ya + Yp + Ygr + YwFz = Za + Zp + Zgr + Zw

• Resulting moments around the body-axes, [Nm]:

L = La + LpM = Ma + MpN = Na + Np

InputsFMaero = [ Xa Ya Za La Ma Na ]T dimensional aerodynamic forces and moments, FMaero


Fgrav = [ Xgr Ygr Zgr ]T gravity force components along body-axes, Fgrav

Fwind = [ Xw Yw Zw ]T corrections to body-axes forces in nonsteady atmosphere, Fwind

OutputsFtot = [ Fx Fy Fz ]T total external forces, Ftot


ParametersNone.

Connectionsin: FMaero comes from the block Aeromod (Beaver); FMprop comes from the block Eng-

mod (Beaver); Fgrav comes from Gravity; Fwind comes from Fwind.

out: Ftot and Mtot are both connected to Vabdot, pqrdot, Eulerdot, and xyHdot; Ftot is alsoconnected to Accel.

Type browse fmsort at the command-line for on-line help.


Fwind Beaver level 1 / Beaver level 2 / Fwind

Main FDC library / Gravity and wind forces

TypeAircraft-independent masked subsystem block, necessary for solving the equations ofmotion in a nonsteady atmosphere.

DescriptionThe block Fwind is used to compute correction terms for the external forces, which need tobe added to the forces along the aircraft’s body-axes when considering flight in nonsteadyatmosphere. These correction terms depend upon the components of the wind velocityvector Vw along the aircraft’s body-axes, the time-derivatives of these wind components,and the roll, pitch, and yaw rates of the aircraft.

EquationsThe equations used by the block Fwind have been discussed in some more detail in sec-tion 3.3.4.

• Corrections to the force components along the body-axes, to account for nonsteadyatmosphere, [N]:

Xw = −m (uw + qww − rvw)Yw = −m (vw − pww + ruw)Zw = −m (ww + pvw − quw)


uwind = [ uw vw ww uw vw ww ]T body-axes components of the wind velocity,and their time-derivatives, uwind

OutputsFwind = [ Xw Yw Zw ]T corrections to body-axes forces in nonsteady atmosphere, Fwind

ParametersFwind needs the parameter vector GM1 to be present the MATLAB workspace, in orderto extract the mass m of the aircraft (the mass has been implemented as a parameter, i.e.it is assumed to be constant during the relative short time intervals considered). Thedefinition of this vector can be found in appendix C. GM1 can be loaded from the fileAIRCRAFT.DAT, using the utility DATLOAD (see section 12.4.2). If this datafile has some-how inadvertently been deleted, it can be re-created by running the program MODBUILD(see section 12.6.1).

Connectionsin: x comes from the block Integrator; uwind is an external input vector containing the

components of the wind (and/or turbulence) velocity, plus their time-derivatives.

out: Fwind is connected to FMsort.

Type browse fwind at the command-line for on-line help.


Gravity Beaver level 1 / Beaver level 2 / Gravity

Main FDC library / Gravity and wind forces


DescriptionThe block Gravity computes the resolution of the aircraft’s weight in body-axes compo-nents, using the pitch and roll angle to determine the attitude of the airplane (the yaw-angle does not affect the gravitational force components). The gravitational accelerationvaries with height; its local value is obtained from the block Atmosph.

EquationsThe equations used by the block Gravity have been discussed in some more detail in sec-tion 3.3.3.

• Contribution of the aircraft’s weight to the body-axes force components, [N]:

Xgr = − W sin θYgr = W cos θ sin ϕZgr = W cos θ cos ϕ

where W = mg is the weight of the aircraft, measured in [N].



OutputsFgrav = [ Xgr Ygr Zgr ]T gravity force components along body-axes, Fgrav

ParametersGravity needs the parameter vector GM1 to be present the MATLAB workspace, in orderto extract the mass m of the aircraft (the mass has been implemented as a parameter, i.e. itis assumed to be constant during the relative short time intervals considered). The defini-tion of GM1 can be found in appendix C. GM1 can be loaded from the file AIRCRAFT.DAT,using the utility DATLOAD (see section 12.4.2). If this datafile has somehow inadvertentlybeen deleted, it can be re-created by running the program MODBUILD (see section 12.6.1).

Connectionsin: x comes from the block Integrator; yatm comes from Atmosph.

out: Fgrav is connected to FMsort.

Type browse gravity at the command-line for on-line help.


Hlpfcn Beaver level 1 / Beaver level 2 / Hlpfcn



DescriptionThe block Hlpfcn is used to compute frequently used sines and cosines of the angle ofattack, the sideslip angle, and the Euler angles, in order to reduce the number of duplicatesine and cosine evaluations in the simulation model. Since the outputs from this block areused by several other subsystems, Hlpfcn has been placed in an internal feedback loop ofthe aircraft model.

EquationsHlpfcn simply determines the required sines and cosines, and stores the results in a singlevector.


Outputsyhlp = [ cos α sin α cos β sin β tan β sin ψ cos ψ sin θ cos θ sin ϕ cos ϕ ]T

frequently used sines and cosines, yhlp

(Please notice that this vector also includes a term ‘tan β’ and that the selected cosine-sinesequence is unfortunately not very intuitive.)

ParametersNone.


out: yhlp is connected to uvw, xdotcorr, Eulerdot, pqrdot, Vabdot, xyHdot, and uvwdot (Addi-tional Outputs).

Type browse hlpfcn at the command-line for on-line help.


Integrator Beaver level 1 / Beaver level 2 / Aircraft Equations of Motion / Integrator


TypeStandard SIMULINK block, essential for solving the equations of motion.

DescriptionThe block Integrator is used to obtain the time-trajectories of the twelve state variablesby integrating the corresponding derivatives, starting with the initial value of the statevector, that needs to be defined in the MATLAB workspace before starting a simulation.

EquationsThe Integrator block determines the new value of the state vector by integrating its time-derivative over the current time-interval, and adding this result to its previous value.

• Update of the state vector for the current time-step:

x(tn+1) = x(tn) +∫ tn+1

tnx(t)dt; n = 0, 1, . . .

where the integral is approximated using a numerical integration method. See section 6.1for more information.

Inputsx = [ V α β p q r ψ θ ϕ xe ye H ]T time-derivative of state vector, xdot


ParametersIntegrator reads the vector xinco from the MATLAB workspace; xinco contains the initialvalue of the state vector. A steady-state initial value can be computed using the aircrafttrim routine ACTRIM (see section 11.1), or it can be loaded into the MATLAB workspacefrom file, using TRILOAD (see section 12.4.2). Of course, it is also possible to manuallyenter the elements of xinco, if required.

Connectionsin: x comes from the block xdotcorr.

out: x is connected to most other blocks in the aircraft model.

See the SIMULINK block-reference in the ‘MATLAB helpdesk’ documentation for more infor-mation about the Integrator block.


Power (Beaver) Beaver level 1 / Beaver level 2 / Engine Group / Power (Beaver)



DescriptionThe block Power (Beaver) is used to compute the engine power P and the dimensionlessincrease in total air pressure, measured across the working plane of the propeller, dpt. Theequations are valid for the Beaver aircraft, but the structure of these relations is probablytypical for piston-powered aircraft, driven by a constant-speed propeller; see also ref.[34].Power (Beaver) needs to be updated if one wishes to implement a model of a differentaircraft within the FDC framework. Thanks to its black-box structure, it is relatively easyto change the structure of the equations if necessary, e.g. to incorporate look-up tablefunctions.

EquationsThe equations used by the block Power (Beaver) have been discussed in more detail insection 3.3.2.

• Dimensionless increase in air pressure, measured across the working plane of the pro-peller, [–]:

dpt =∆pt

12 ρV2

= C1 + C2

(P

12 ρV3

)with P

12 ρV3 measured in [kW kg−1 s3], and: C1 = 0.08696, C2 = 191.18, see ref.[34].

• Engine power P, [Nm s−1]:

P = 0.7355−326.5 +

(0.00412(pz + 7.4)(n + 2010) + (408.0− 0.0965n)

(1.0− ρ

ρ0

))Inputs




Outputsypow = [ dpt P ]T engine power related variables, ypow

ParametersAll parameters for Power (Beaver) have been defined within the block itself; the blockdoes not use any parameters from the MATLAB workspace.

Connectionsin: x comes from the block Integrator; uprop is an external input vector with control in-

puts for the engine; yatm comes from Atmosph.

out: ypow is connected to Engmod (Beaver).

Type browse power at the command-line for on-line help.


pqrdot Beaver level 1 / Beaver level 2 / Aircraft Equations of Motion / 12 ODEs / pqrdot



DescriptionThe block pqrdot computes the time-derivatives of the roll rate p, pitch rate q, and yawrate r. These three variables form a subset of the twelve state variables of the nonlinearaircraft model.

EquationsThe equations used by the block pqrdot have been discussed in some more detail in sec-tion 2.1.4.

• Time-derivatives of the angular velocities around the body-axes, [rad s−2]:

p = Ppp p2 + Ppq pq + Ppr pr + Pqqq2 + Pqrqr + Prrr2 + Pl L + Pm M + PnN

q = Qpp p2 + Qpq pq + Qpr pr + Qqqq2 + Qqrqr + Qrrr2 + Ql L + Qm M + QnN

r = Rpp p2 + Rpq pq + Rpr pr + Rqqq2 + Rqrqr + Rrrr2 + Rl L + Rm M + RnN

The coefficients Ppp, Ppq, Ppr, ... , Rm, and Rn are inertia coefficients, see the definition intable 2.2.

Inputsupqr = [ xT Ftot

T MtotT yhlp

T ]T input vector to pqrdot, pqr

where:





Outputs

ypqr = [ p q r ]T time-derivatives of the angular velocitiesaround the body-axes, ypqr (part of x)

ParametersThe block pqrdot needs the parameter matrix GM2 to be present the MATLAB workspace,in order to extract the inertia coefficients (the moments and products of inertia have beenimplemented as parameters, i.e. they are assumed to be constant during the relative shorttime intervals considered). The definition of this matrix can be found in appendix C. GM2can be loaded from the file AIRCRAFT.DAT, using the utility DATLOAD (see section 12.4.2).If this datafile has somehow inadvertently been deleted, it can be re-created by runningthe program MODBUILD (see section 12.6.1).


comes from the block Hlpfcn.

out: ypqr is muxed together with the time-derivatives of the other state variables into asingle vector x (not corrected for the implicit nature of the β-equation). This time-derivative of the state vector x is then connected to the block xdotcorr.

Type browse pqrdot at the command-line for on-line help.


uvw Beaver level 1 / Beaver level 2 / Aircraft Equations of Motion / uvw



DescriptionThe block uvw is used to compute the body-axes velocity components, using the angle ofattack α, sideslip angle β, and true airspeed V. These velocity components are requiredto determine the coordinates xe and ye and the altitude H of the aircraft.

EquationsThe equations used by the block uvw have been discussed in some more detail in sec-tion 2.2.2.

• Velocity component u, directed along the XB-axis, [ms−1]:

u = V cos α cos β

• Velocity component v, directed along the YB-axis, [ms−1]:

v = V sin β

• Velocity component w, directed along the ZB-axis, [ms−1]:

w = V sin α cos β



Outputsybvel = [ u v w ]T body-axes velocity components, ybvel

ParametersNone.

Connectionsin: x comes from the block Integrator; yhlp comes from the block Hlpfcn.

out: ybvel is connected to xyHdot.

Type browse uvw at the command-line for on-line help.


uvwdot Beaver level 1 / Beaver level 2 / Additional Outputs / uvwdot


TypeAircraft-independent masked subsystem block, not essential for solving the equations ofmotion (the block does not contain any state equations).

DescriptionThe block uvwdot computes the time-derivatives of the body-axes velocity componentsu, v, and w. It should be noted that these body-axes velocity components are not statevariables, and therefore, their time-derivatives do not represent state equations (the stateequations have been based on the airspeed, angle of attack, and sideslip angle, instead ofthe body-axes velocity components, as explained in section 2.2).

EquationsThe equations used by the block uvwdot have been discussed in some more detail in sec-tion 3.6.

• Time-derivative of the velocity component along the XB-axis, [ms−2]:

u = V cos α cos β−V(α sin α cos β + β cos α sin β)

• Time-derivative of the velocity component along the YB-axis, [ms−2]:

v = V sin β + V β cos β

• Time-derivative of the velocity component along the ZB-axis, [ms−2]:

w = V sin α cos β + V(α cos α cos β− β sin α sin β)




Outputsyuvw = [ u v w ]T time-derivatives of body-axes velocities, yuvw

ParametersNone.

Connectionsin: x comes from the block Integrator; x comes from the block xfix; yhlp comes from the

block Hlpfcn.

out: yuvw is not used by any other block from the aircraft model.

Type browse uvwdot at the command-line for on-line help.


Vabdot Beaver level 1 / Beaver level 2 / Aircraft Equations of Motion / 12 ODEs / Vabdot



DescriptionThe block Vabdot computes the time-derivatives of the true airspeed V, angle of attack α,and sideslip angle β. These three variables form a subset of the twelve state variables ofthe nonlinear aircraft model.

EquationsThe equations used by the block Vabdot have been discussed in some more detail in sec-tion 2.2.

• Time-derivative of the true airspeed V, [ms−2]:

V =1m

(Fx cos α cos β + Fy sin β + Fz sin α cos β)

• Time-derivative of the angle of attack α, [rad s−1]:

α =1

V cos β

1m


+ q− (p cos α + r sin α) tan β

• Time-derivative of the sideslip angle β, [rad s−1]:

β =1V

1m



InputsuVab = [ xT Ftot

T MtotT yhlp

T ]T input vector to Vabdot, uVab

where:





Outputs

yVab = [ V α β ]T time-derivatives of the airspeed, angle of attack, andsideslip angle, yVab (part of x)

ParametersVabdot needs the parameter vector GM1 to be present the MATLAB workspace, in orderto extract the mass m of the aircraft (the mass has been implemented as a parameter, i.e. itis assumed to be constant during the relative short time intervals considered). The defini-tion of GM1 can be found in appendix C. GM1 can be loaded from the file AIRCRAFT.DAT,using the utility DATLOAD (see section 12.4.2). If this datafile has somehow inadvertentlybeen deleted, it can be re-created by running the program MODBUILD (see section 12.6.1).


comes from the block Hlpfcn.out: yVab is muxed together with the time-derivatives of the other state variables into a

single vector x (not corrected for the implicit nature of the β-equation). This time-derivative of the state vector x is then connected to the block xdotcorr.

Type browse Vabdot at the command-line for on-line help.


xdotcorr (Beaver) Beaver level 1 / Beaver level 2 / Aircraft Equations of Motion / xdotcorr (Beaver)



DescriptionAs discussed in section 3.4, the aerodynamic model of the Beaver aircraft includes an im-plicit differential equation of the sideslip angle: the time-derivative of the sideslip angleappears on both sides of the equation (β is dependent on the sideforce, while the aerody-namic component of the sideforce itself is directly dependent on β). To avoid this from re-sulting in an algebraic loop (see section 6.4.1), which would slow down the simulations ormake the system too complicated for SIMULINK to solve, the equation has been re-writtenas an explicit differential equation. In order to keep the resulting model as generic as pos-sible, the resulting equation was split into an aircraft-independent part, which neglectedthe direct contribution of β to the aerodynamic sideforce, and an aircraft-dependent part,which took care of this dependency.

The latter task is performed by the block xdotcorr (Beaver), which is the only aircraft-dependent block in the subsystem Aircraft Equations of Motion (Beaver) (hence the suf-fix ‘Beaver’). Please notice that xdotcorr is in fact part of the aerodynamic model; thisblock should be updated if the aircraft model is adapted for a different aircraft type. Thismethod can be applied for any implicit state equation, as long as the dependencies are lin-ear. For nonlinear implicit relations, it will be necessary to use a different solution to thisproblem, e.g. artificially breaking an implicit loop by introducing a delay in the internalx-feedback loop.

EquationsThe β-equation for the Beaver can be written as:

β =1

Vm

(− Fx cos α sin β + Fy

∗ cos β− Fz sin α sin β + 12 ρV2S CYβ

βb2V cos β

)+


where Fy∗ is the side-force without the contribution of β. The β-term on the right-hand

side of this equation can easily be moved to the left-hand side:

β∗ ≡ β

(1− ρSb

4mCYβ

cos β

)=

=1

Vm(−Fx cos α sin β + Fy

∗ cos β− Fz sin α sin β)+ p sin α− r cos α

Based upon this equation the following calculation sequence has been used in the simula-tion model of the Beaver:

1. compute the external forces and moments as usual, but neglect the β-contributionto the aerodynamic side-force for the time being (Aeromod),

2. substitute the thus obtained forces and moments into the general β-equation, toobtain the value β∗ (12 ODEs), and

3. compute the actual value of β using the expression β = β∗(

1− ρSb4m CYβ

cos β)−1

(xdotcorr).


Inputsx = [ V α β p q r ψ θ ϕ xe ye H ]T uncorrected time-derivative of state vector, xdot



Outputsx = [ V α β p q r ψ θ ϕ xe ye H ]T time-derivative of state vector, xdot, corrected for β

ParametersThe block xdotcorr (Beaver) needs the parameter vector GM1 to be present the MATLABworkspace, in order to extract the wing span, wing surface, and mass m of the aircraft(the mass has been implemented as a parameter, i.e. it is assumed to be constant duringthe relative short time intervals considered). It also needs the parameter matrix AM, toextract the stability derivative CYβ

. The definition of AM and GM1 can be found in ap-pendix C. Both variables can be loaded from the file AIRCRAFT.DAT, using the utilityDATLOAD (see section 12.4.2). If this datafile has somehow inadvertently been deleted, itcan be re-created by running the program MODBUILD (see section 12.6.1).

Connectionsin: x (not corrected for the implicit nature of the β-equation) comes from the subsystem

12 ODEs; yhlp comes from the block Hlpfcn; yatm comes from Atmosph.

out: x (with a corrected value of β) is connected to the block xfix.

Type browse xdotcorr at the command-line for on-line help.


xfix Beaver level 1 / Beaver level 2 / Aircraft Equations of Motion / xfix


TypeAircraft-independent masked Gain block, not necessary for solving the equations of mo-tion themselves but quite useful for purposes such as autopilot design and analysis.

DescriptionSometimes it is useful to artificially fix state variables to their initial values by simplysetting their time-derivatives to zero, thus totally disregarding the values of the time-derivatives resulting from the model equations. Neglecting parts of the system dynamicscan be useful to establish ‘reference’ system responses, against which ‘actual’ responsescan be measured. Examples are the design of a speed-hold autothrottle controller, whoseresponses can be compared to the ‘ideal’ situation in which the airspeed is artificiallyheld constant, or the analysis of lateral-longitudinal cross-coupling effects by comparingsimulations from the full aircraft model with results in which the longitudinal or lateralaircraft dynamics are artificially neglected.

The block xfix can be used to force state variables from the aircraft model to remainfixed to their initial value during the simulation. It is in fact a masked Gain block thatmultiplies the time-derivatives of all state variables with a value of either one, or zero.In the first situation, the computed time-derivative is used, in the second situation, thetime-derivative is artificially set to zero, causing the corresponding state variable to stayconstant.

EquationsThe block xfix modifies the time-derivative of the state vector by performing an element-by-element multiplication (in the equation below denoted with the symbol ?) with thevector xfix. The elements from this vector are equal to one or zero, and the total numberof elements corresponds to the length of the state vector.

• Modified time-derivative of the state vector:

xnew = xold ? xfix =

VαβpqrψθϕxeyeH

?

xfix(1)xfix(2)xfix(3)

...

...

...

...

...xfix(12)

where: xfix(i) =

01

i ∈ 1, 2, . . . , 12

Inputsxold = [ V α β p q r ψ θ ϕ xe ye H ]T unmodified time-derivative of state vector, xdot

Outputsxnew = [ V α β p q r ψ θ ϕ xe ye H ]T modified time-derivative of state vector, xdot

ParametersThe block xfix tries to read the multiplication vector xfix from in the MATLAB workspace.If the variable xfix is not present in the workspace when the aircraft model is accessed bye.g. a simulation or a linearization process, it will automatically be set to its default valueones(1,12). If it is desired to artificially fix specific states, xfix should either be entered


manually (it must be a vector of length 12, with all elements being either one or zero), orbe defined by running the utility FIXSTATE (see section 12.6.2).

Connectionsin: the unmodified vector x comes from the block xdotcorr (Beaver).

out: the modified vector x, whose elements may have been artificially set to zero, isconnected to the block Integrator.

Type browse xfix at the command-line for on-line help. Information about FIXSTATE canbe displayed on screen by typing browse fixstate at the command-line.


xyHdot Beaver level 1 / Beaver level 2 / Aircraft Equations of Motion / 12 ODEs / xyHdot



DescriptionThe block xyHdot computes the time-derivatives of the aircraft’s X and Y-coordinates xeand ye, measured with respect to the Earth-fixed reference frame, and of the the altitudeH. These three variables form a subset of the twelve state variables of the nonlinearaircraft model. For most purposes it is possible to omit xe and ye from the simulationmodel, because the motions of the aircraft are not affected by its position relative to theEarth. The coordinates are useful, however, for navigational purposes. Notice that it isnot possible to omit the altitude H from the simulation model, because of the altitude-dependency of the air temperature, pressure, and density, which affect the aerodynamicand propulsive forces and moments.

EquationsThe equations used by the block xyHdot have been discussed in some more detail in sec-tion 2.4.

• Time-derivative of the X-coordinate xe, [ms−1]:


• Time-derivative of the Y-coordinate ye, [ms−1]:


• Rate of climb or descent, [ms−1]:

H = −ze = ue sin θ − (ve sin ϕ + we cos ϕ) cos θ

Inputsybvel

∗ = [ u + uw v + vw w + ww ]T body-axes velocity components plus wind, ybvel∗uxyH = [ xT Ftot

T MtotT yhlp

T ]T input vector to xyHdot, uxyH

where:





OutputsyxyH = [ xe ye H ]T time-derivatives of the coordinates and altitude, yxyH (part of x)

ParametersNone.


comes from the block Hlpfcn; ybvel∗ is the sum of the output from uvw and the wind

velocity components from the external input vector uwind.out: yxyH is muxed together with the time-derivatives of the other state variables into a

single vector x (not corrected for the implicit nature of the β-equation). This time-derivative of the state vector x is then connected to the block xdotcorr.

Type browse xyhdot at the command-line for on-line help.

Chapter 9

Wind and turbulence block reference

In chapter 4 we discussed the nonsteady nature of the atmosphere, providing somebasic wind and turbulence models that were suitable for implementation in SIMU-LINK. This chapter will provide a detailed description of the resulting SIMULINK

blocks. If you want to manipulate these blocks, or gain a better insight in the struc-ture of these blocks, it is recommended to unmask the blocks and compare the inter-nal block equations with the descriptions from this chapter. See section 7.8 for moreinformation about the masked interface of the FDC systems.

9.1 The wind and turbulence blocklibrary

All wind and turbulence blocks have been collected in the SIMULINK blocklibraryWINDLIB, which is shown in figure 9.1. This library can be accessed from the mainFDC library (shown in figure 7.7 of chapter 7) by double-clicking the ‘Wind andturbulence library’ button, or by typing windlib in the MATLAB command-window.WINDLIB itself consists of two sublibraries: WNDLIB1, which contains the determin-istic wind models, and WNDLIB2, which contains the stochastic turbulence models.These sublibraries have been shown in figures 9.2 and 9.3.

Figure 9.1: Wind and turbulence library WINDLIB

166 Chapter 9. Wind and turbulence block reference

Figure 9.2: Sublibrary with wind-models

Figure 9.3: Sublibrary with turbulence models

The remainder of this chapter (pages 167 to 177) provides detailed descriptionsof the individual blocks from the wind and turbulence library. The blocks havebeen listed in alphabetical order; their locations have been referenced in relationto the main FDC library and the wind and turbulence library.

9.1. The wind and turbulence blocklibrary 167

BLwind Main FDC library / Wind and turbulence / Wind models / BLwind

Wind and turbulence library / Wind models / BLwind

TypeMasked subsystem block.

DescriptionThe block BLwind calculates components of the wind velocity along the aircraft’s body-axes in the boundary layer of the Earth (‘BL’ stands for ‘Boundary Layer’), which rangesfrom ground level to a height of about 300 m. The wind velocity and direction (both in thehorizontal plane and the vertical plane) can be freely defined as a function of the altitude.By default, a wind velocity function according to ref.[1] is used, the wind direction isassumed to be constant, and the vertical wind component is set to zero.

EquationsFor a detailed discussion of the equations from the block BLwind, refer to section 4.1.

• Total wind velocity in the boundary layer of the Earth, according to ref.[1], [ms−1]:

Vw = Vw 9.15

H0.2545 − 0.40971.3470

(0 < h < 300m)Vw = 2.86585 Vw9.15 (h ≥ 300m)

where Vw 9.15 is the wind velocity at a height of 9.15 m.

• Horizontal and vertical components of the wind velocity, [ms−1]:

Vwhor = Vw · cos γw

Vwvert ≡ ww = −Vw · sin γw

where γw is the ‘vertical wind direction angle’, i.e. the angle between the wind vectorand the horizontal plane.

• Horizontal components of the wind velocity, aligned along the Earth-fixed referenceframe, [ms−1]:

uw = Vwhor · cos(ψw − π)vw = Vwhor · sin(ψw − π)

where ψw is the ‘horizontal wind direction angle’, i.e. the direction from where the hor-izontal component of the wind (Vwhor ) emanates, measured relatively to the magneticnorth (ψw is measured in [rad]; it equals zero when the wind is blowing from the north,and π when the wind is blowing to the north).

• Wind components, measured along the body-axes of the aircraft, [ms−1]:

VBw = (TΦ · TΘ · TΨ) ·VE

w

where TΦ, TΘ, and TΨ represent the transformation matrices corresponding to Eulerrotations, and the superscripts denote the applicable reference frame. This transforma-tion has been written out in more detail in appendix A, equation (A.4).

The angles γw and ψw may be defined as a function of the height above ground, similar tothe wind velocity function, but by default the values have been set to 0 [rad] and π [rad],respectively (no vertical wind component, and the wind is blowing to the north).

Please notice that the thickness of the boundary layer has been hard-wired in the BLwindstructure by means of a Saturation block, which has been hidden beneath the mask in-terface of BLwind. The height above ground is extracted from the twelfth element of theinput vector, which has the same definition as the state vector x from the aircraft model.However, it should be noted that this element actually represents the altitude of the air-plane above sea-level, which means that the equations are only valid when ground-leveland sea-level coincide!


Inputsx = [ V α β p q r ψ θ ϕ xe ye H ]T state vector from the aircraft model, x

Outputs[ uw vw ww ]T wind velocities along aircraft’s body-axes, [uw,vw,ww]’

ParametersBLwind does not require any workspace parameters to be specified. The user may changethe equations for the wind velocity, horizontal wind direction, and vertical wind directionin the mask dialog, which is opened after double-clicking the block BLwind. In theseequations, u[1] denotes the height above ground-level (which is assumed to be equal tothe altitude above sea-level, as explained above).

Connectionsin: x is usually extracted from the nonlinear aircraft model (type browse outputs at

the command-line for more information about the outputs from the aircraft model).

out: the wind velocity components can be used to create the input vector uwind for theaircraft model (since the body-axes wind-components are in general not constantacross the flight-path of the airplane, it will be necessary to compute the time-derivatives of the wind velocity components too, using an additional Derivativeblock — the vector uwind can be constructed by muxing the output vector fromBLwind with the time-derivative from this Derivative block).

Type browse blwind at the command-line for on-line help.


Cwind Main FDC library / Wind and turbulence / Wind models / Cwind

Wind and turbulence library / Wind models / Cwind


DescriptionThe block Cwind calculates components of the wind velocity along the aircraft’s body-axesfor a constant wind (‘C’ stands for ‘Constant’). The user can specify the wind velocity anddirection (both in the horizontal plane and the vertical plane).

EquationsFor a detailed discussion of the equations from the block Cwind, refer to section 4.1.

• Horizontal and vertical components of the wind velocity, [ms−1]:

Vwhor = Vw · cos γw

Vwvert ≡ ww = −Vw · sin γw

where γw is the ‘vertical wind direction angle’, i.e. the angle between the wind vectorand the horizontal plane.

• Horizontal components of the wind velocity, aligned along the Earth-fixed referenceframe, [ms−1]:

uw = Vwhor · cos(ψw − π)vw = Vwhor · sin(ψw − π)

where ψw is the ‘horizontal wind direction angle’, i.e. the direction from where the hor-izontal component of the wind (Vwhor ) emanates, measured relatively to the magneticnorth (ψw is measured in [rad]; it equals zero when the wind is blowing from the north,and π when the wind is blowing to the north).

• Wind components, measured along the body-axes of the aircraft, [ms−1]:

VBw = (TΦ · TΘ · TΨ) ·VE

w

where TΦ, TΘ, and TΨ represent the transformation matrices corresponding to Eulerrotations, and the superscripts denote the applicable reference frame. This transforma-tion has been written out in more detail in appendix A, equation (A.4).


Outputs[ uw vw ww ]T wind velocities along aircraft’s body-axes, [uw,vw,ww]’

ParametersCwind does not require any workspace parameters to be specified. The user must specifythe wind velocity, horizontal wind direction, and vertical wind direction in the maskdialog, which is opened after double-clicking the block Cwind.


the command-line for more information about the outputs from the aircraft model).out: the wind velocity components can be used to create the input vector uwind for the

aircraft model (since the body-axes wind-components are in general not constantacross the flight-path of the airplane, it will be necessary to compute the time-derivatives of the wind velocity components too, using an additional Derivativeblock — the vector uwind can be constructed by muxing the output vector from Cwindwith the time-derivative from this Derivative block).

Type browse cwind at the command-line for on-line help.


Turbulence Group 1 Main library / Wind & turbulence / Atmosph. turb. models / Turbulence Group 1

Wind and turbulence library / Atmospheric turbulence models / Turbulence Group 1

TypeNon-masked subsystem.

DescriptionThe subsystem Turbulence Group 1 determines longitudinal, lateral, and vertical turbu-lence velocity components along the body-axes of the aircraft, plus their time-derivatives,using Dryden filters with constant coefficients. The user must specify the mean airspeed,scale length, and standard deviation in each of the Dryden filters from this subsystem(longitudinal, lateral, and vertical). Variations of the filter coefficients with the airspeedare neglected, as the influence of such variations is usually rather small. If this limitationis not acceptable, use Turbulence Group 2 instead.

Subsystems and/or blocksThe subsystem Turbulence Group 1 contains three blocks:

UDRYD1 generates the turbulence velocity component along the XB-axis of the aircraft(‘longitudinal turbulence’), and its time-derivative,

VDRYD1 generates the turbulence velocity component along the YB-axis of the aircraft(‘lateral turbulence’), and its time-derivative,

WDRYD1 generates the turbulence velocity component along the ZB-axis of the aircraft(‘vertical turbulence’), and its time-derivative.

InputsNone.

Outputsuwind = [ ug vg wg ug vg wg ]T wind velocity vector (turbulence only), uwind

Note: the outputvector from Turbulence Group 1 has been named uwind, because it has thesame structure as the input vector uwind for the aircraft model. However, in the case of theaircraft model, this vector is meant to take into account deterministic wind components,as well as stochastic turbulence.

ParametersTurbulence Group 1 does not require any workspace parameters to be specified. The usermust specify the scale lengths Lug ,vg ,wg , the standard deviations σug ,vg ,wg , and the esti-mated mean value of the true airspeed for which the motions are evaluated for each ofthe three blocks UDRYD1, VDRYD1, and WDRYD1; double-click these blocks to open themask-dialogs that allow you to define these block parameters.

Connectionsin: no connections.

out: uwind can be connected to the input-side of the aircraft model (see the description ofBeaver Level 1 in chapter 8). If simulations involve deterministic wind components,the wind components need to be added to the outputs from this subsystem first,before entering the aircraft model.

Type browse turb1 at the command-line for on-line help.


Turbulence Group 2 Main library / Wind & turbulence / Atmosph. turb. models / Turbulence Group 2

Wind and turbulence library / Atmospheric turbulence models / Turbulence Group 2

TypeNon-masked subsystem.

DescriptionThe subsystem Turbulence Group 2 determines longitudinal, lateral, and vertical turbu-lence velocity components along the body-axes of the aircraft, plus their time-derivatives,using Dryden filters with airspeed-dependent coefficients. The user must specify the scalelength and standard deviation in each of the Dryden filters from this subsystem (longitu-dinal, lateral, and vertical). Variations of the filter coefficients are computed ‘on-the-fly’,as a function of the airspeed. Since the resulting variations in filter characteristics are usu-ally relatively small, the turbulence library also offers a simplified subsystem TurbulenceGroup 1, which uses constant filter coefficients.

Subsystems and/or blocksThe subsystem Turbulence Group 2 contains three blocks:

UDRYD2 generates the turbulence velocity component along the XB-axis of the aircraft(‘longitudinal turbulence’), and its time-derivative,

VDRYD2 generates the turbulence velocity component along the YB-axis of the aircraft(‘lateral turbulence’), and its time-derivative,

WDRYD2 generates the turbulence velocity component along the ZB-axis of the aircraft(‘vertical turbulence’), and its time-derivative.

InputsV true airspeed of the aircraft, V

Outputsuwind = [ ug vg wg ug vg wg ]T wind velocity vector (turbulence only), uwind

Note: the outputvector from Turbulence Group 2 has been named uwind, because it has thesame structure as the input vector uwind for the aircraft model. However, in the case of theaircraft model this vector is meant to take into account deterministic wind components,as well as stochastic turbulence.

ParametersTurbulence Group 2 does not require any workspace parameters to be specified. The usermust specify the scale lengths Lug ,vg ,wg and the standard deviations σug ,vg ,wg for each ofthe three blocks UDRYD2, VDRYD2, and WDRYD2; double-click these blocks to open themask-dialogs that allow you to define these block parameters.

Connectionsin: the airspeed V is usually extracted from the state vector x of the nonlinear aircraft

model.

out: uwind can be connected to the input-side of the aircraft model (see the description ofBeaver Level 1 in chapter 8). If simulations involve deterministic wind components,the wind components need to be added to the outputs from this subsystem first,before entering the aircraft model.

Type browse turb2 at the command-line for on-line help.


UDRYD1 Main FDC library / Wind and turbulence / Atmospheric turbulence models / UDRYD1

Wind and turbulence library / Atmospheric turbulence models / UDRYD1


DescriptionThe block UDRYD1 computes the longitudinal turbulence velocity component, which isaligned along the XB-axis of the aircraft, together with its time-derivative, using a longi-tudinal Dryden filter with constant coefficients. The user must specify the longitudinalscale-length of the turbulence Lug , the standard deviation σug , and the (expected) meanairspeed of the aircraft. UDRYD1 does not take into account variations of the filter coeffi-cients with the airspeed, as the influence of those variations is usually very small; if thislimitation is not acceptable, use UDRYD2 instead.

EquationsFor a detailed discussion of the equations from the block UDRYD1 and the underlyingtheory, refer to section 4.2.

• Longitudinal turbulence velocity, [ms−1]:

ug(s) = Hugw1(s) w1(s)

where w1 is a white noise signal, that is generated internally by a white-noise generatorwithin the block UDRYD1, and Hugw1 is the transfer function of the longitudinal turbu-lence velocity filter.

• Transfer function of the longitudinal turbulence filter:

Hugw1(s) = σug

√2Lug

V1

1 +LugV s

Note: the value of the airspeed V, used by UDRYD1, is kept constant during simulations.This value must be specified by the user; obviously, the most realistic result is obtainedby specifying the (estimated) mean velocity of the airplane. If very large variations inairspeed are anticipated, use the block UDRYD2 instead.

InputsNone.

Outputsug longitudinal turbulence velocity, ugug time-derivative of longitudinal turbulence velocity, ug dot

ParametersUDRYD1 does not require any workspace parameters to be specified. The user must spec-ify the scale length Lug , the standard deviation σug , and the estimated mean value of thetrue airspeed for which the motions are evaluated in the mask dialog, which is openedafter double-clicking the block UDRYD1.


out: ug and ug are usually combined with other turbulence velocities and their time-derivatives in a single vector that can be connected on the input side of the aircraftmodel (through the uwind port).

Type browse udryd1 at the command-line for on-line help.


UDRYD2 Main FDC library / Wind and turbulence / Atmospheric turbulence models / UDRYD2

Wind and turbulence library / Atmospheric turbulence models / UDRYD2


DescriptionThe block UDRYD2 computes the longitudinal turbulence velocity component, which isaligned along the XB-axis of the aircraft, together with its time-derivative, using a longi-tudinal Dryden filter with coefficients that will vary with airspeed. The user must specifythe longitudinal scale-length of the turbulence Lug and the standard deviation σug , but thefilter coefficients of UDRYD2 are computed ‘on-the-fly’, as a function of the airspeed. Sincethe resulting variations in filter characteristics are usually relatively small, the turbulencelibrary also offers the simplified block UDRYD1, which uses constant filter coefficients.

EquationsFor a detailed discussion of the equations from the block UDRYD2 and the underlyingtheory, refer to section 4.2.

• Longitudinal turbulence velocity, [ms−1]:

ug(s) = Hugw1(s) w1(s)

where w1 is a white noise signal, that is generated internally by a white-noise generatorwithin the block UDRYD2, and Hugw1 is the transfer function of the longitudinal turbu-lence velocity filter.

• Transfer function of the longitudinal turbulence filter:

Hugw1(s) = σug

√2Lug

V1

1 +LugV s

Note: the filter coefficients are computed ‘on-the-fly’, as a function of the actual value ofthe airspeed V. In practice, the transfer-function has been implemented in the form of itsblock-diagram equivalent, which was determined using the theory from section 6.4.2; thegains in this block-diagram are ‘scheduled’ as a function of V.


Outputsug longitudinal turbulence velocity, ugug time-derivative of longitudinal turbulence velocity, ug dot

ParametersUDRYD2 does not require any workspace parameters to be specified. The user mustspecify the scale length Lug , and the standard deviation σug in the mask dialog, whichis opened after double-clicking the block UDRYD2.


model.

out: ug and ug are usually combined with other turbulence velocities and their time-derivatives in a single vector that can be connected on the input side of the aircraftmodel (through the uwind port).

Type browse udryd2 at the command-line for on-line help.


VDRYD1 Main FDC library / Wind and turbulence / Atmospheric turbulence models / VDRYD1

Wind and turbulence library / Atmospheric turbulence models / VDRYD1


DescriptionThe block VDRYD1 computes the lateral component of the turbulence velocity, which isaligned along the YB-axis of the aircraft, together with its time-derivative, using a lateralDryden filter with constant coefficients. The user must specify the lateral scale-length ofthe turbulence Lvg , the standard deviation σvg , and the (expected) mean airspeed of theaircraft. VDRYD1 does not take into account variations of the filter coefficients with theairspeed, as the influence of those variations is usually very small; if this limitation is notacceptable, use VDRYD2 instead.

EquationsFor a detailed discussion of the equations from the block VDRYD1 and the underlyingtheory, refer to section 4.2.

• Lateral turbulence velocity, [ms−1]:

vg(s) = Hvgw2(s) w2(s)

where w2 is a white noise signal, that is generated internally by a white-noise generatorwithin the block VDRYD1, and Hvgw2 is the transfer function of the lateral turbulencevelocity filter.

• Transfer function of the lateral turbulence filter:

Hvgw2(s) = σvg

√2Lvg

V1 +

√3

LvgV s(

1 +LvgV s)2

Note: the value of the airspeed V, used by VDRYD1, is kept constant during simulations.This value must be specified by the user; obviously, the most realistic result is obtainedby specifying the (estimated) mean velocity of the airplane. If very large variations inairspeed are anticipated, use the block VDRYD2 instead.

InputsNone.

Outputsvg lateral turbulence velocity, vgvg time-derivative of lateral turbulence velocity, vg dot

ParametersVDRYD1 does not require any workspace parameters to be specified. The user must spec-ify the scale length Lvg , the standard deviation σvg , and the estimated mean value of thetrue airspeed for which the motions are evaluated in the mask dialog, which is openedafter double-clicking the block VDRYD1.


out: vg and vg are usually combined with other turbulence velocities and their time-derivatives in a single vector that can be connected on the input side of the aircraftmodel (through the uwind port).

Type browse vdryd1 at the command-line for on-line help.


VDRYD2 Main FDC library / Wind and turbulence / Atmospheric turbulence models / VDRYD2

Wind and turbulence library / Atmospheric turbulence models / VDRYD2


DescriptionThe block VDRYD2 computes the lateral component of the turbulence velocity, which isaligned along the YB-axis of the aircraft, together with its time-derivative, using a lateralDryden filter with coefficients that will vary with airspeed. The user must specify thelateral scale-length of the turbulence Lvg and the standard deviation σvg , but the filtercoefficients of VDRYD2 are computed ‘on-the-fly’, as a function of the airspeed. Sincethe resulting variations in filter characteristics are usually relatively small, the turbulencelibrary also offers the simplified block VDRYD1, which uses constant filter coefficients.

EquationsFor a detailed discussion of the equations from the block VDRYD2 and the underlyingtheory, refer to section 4.2.

• Lateral turbulence velocity, [ms−1]:

vg(s) = Hvgw2(s) w2(s)

where w2 is a white noise signal, that is generated internally by a white-noise generatorwithin the block VDRYD2, and Hvgw2 is the transfer function of the lateral turbulencevelocity filter.

• Transfer function of the lateral turbulence filter:

Hvgw2(s) = σvg

√2Lvg

V1 +

√3

LvgV s(

1 +LvgV s)2



Outputsvg lateral turbulence velocity, vgvg time-derivative of lateral turbulence velocity, vg dot

ParametersVDRYD2 does not require any workspace parameters to be specified. The user must spec-ify the scale length Lvg and the standard deviation σvg in the mask dialog, which is openedafter double-clicking the block VDRYD2.


model.

out: vg and vg are usually combined with other turbulence velocities and their time-derivatives in a single vector that can be connected on the input side of the aircraftmodel (through the uwind port).

Type browse vdryd2 at the command-line for on-line help.


WDRYD1 Main FDC library / Wind and turbulence / Atmospheric turbulence models / WDRYD1

Wind and turbulence library / Atmospheric turbulence models / WDRYD1


DescriptionThe block WDRYD1 computes the vertical component of the turbulence velocity, which isaligned along the ZB-axis of the aircraft, together with its time-derivative, using a verticalDryden filter with constant coefficients. The user must specify the vertical scale-length ofthe turbulence Lwg , the standard deviation σwg , and the (expected) mean airspeed of theaircraft. WDRYD1 does not take into account variations of the filter coefficients with theairspeed, as the influence of those variations is usually very small; if this limitation is notacceptable, use WDRYD2 instead.

EquationsFor a detailed discussion of the equations from the block WDRYD1 and the underlyingtheory, refer to section 4.2.

• Vertical turbulence velocity, [ms−1]:

wg(s) = Hwgw3(s) w3(s)

where w3 is a white noise signal, that is generated internally by a white-noise generatorwithin the block WDRYD1, and Hwgw3 is the transfer function of the vertical turbulencevelocity filter.

• Transfer function of the vertical turbulence filter:

Hwgw3(s) = σwg

√2Lwg

V1 +

√3

LwgV s(

1 +LwgV s)2

Note: the value of the airspeed V, used by WDRYD1, is kept constant during simulations.This value must be specified by the user; obviously, the most realistic result is obtainedby specifying the (estimated) mean velocity of the airplane. If very large variations inairspeed are anticipated, use the block WDRYD2 instead.

InputsNone.

Outputswg vertical turbulence velocity, wgwg time-derivative of vertical turbulence velocity, wg dot

ParametersWDRYD1 does not require any workspace parameters to be specified. The user mustspecify the scale length Lwg , the standard deviation σwg , and the estimated mean valueof the true airspeed for which the motions are evaluated in the mask dialog, which isopened after double-clicking the block WDRYD1.


out: wg and wg are usually combined with other turbulence velocities and their time-derivatives in a single vector that can be connected on the input side of the aircraftmodel (through the uwind port).

Type browse wdryd1 at the command-line for on-line help.


WDRYD2 Main FDC library / Wind and turbulence / Atmospheric turbulence models / WDRYD2

Wind and turbulence library / Atmospheric turbulence models / WDRYD2


DescriptionThe block WDRYD2 computes the vertical component of the turbulence velocity, which isaligned along the ZB-axis of the aircraft, together with its time-derivative, using a verticalDryden filter with coefficients that will vary with airspeed. The user must specify thelateral scale-length of the turbulence Lwg and the standard deviation σwg , but the filtercoefficients of WDRYD2 are computed ‘on-the-fly’, as a function of the airspeed. Sincethe resulting variations in filter characteristics are usually relatively small, the turbulencelibrary also offers the simplified block WDRYD1, which uses constant filter coefficients.

EquationsFor a detailed discussion of the equations from the block WDRYD2 and the underlyingtheory, refer to section 4.2.

• Vertical turbulence velocity, [ms−1]:

wg(s) = Hwgw3(s) w3(s)

where w3 is a white noise signal, that is generated internally by a white-noise generatorwithin the block WDRYD2, and Hwgw3 is the transfer function of the vertical turbulencevelocity filter.

• Transfer function of the vertical turbulence filter:

Hwgw3(s) = σwg

√2Lwg

V1 +

√3

LwgV s(

1 +LwgV s)2



Outputswg vertical turbulence velocity, wgwg time-derivative of vertical turbulence velocity, wg dot

ParametersWDRYD2 does not require any workspace parameters to be specified. The user mustspecify the scale length Lwg and the standard deviation σwg , which is opened after double-clicking the block WDRYD2.


model.

out: wg and wg are usually combined with other turbulence velocities and their time-derivatives in a single vector that can be connected on the input side of the aircraftmodel (through the uwind port).

Type browse wdryd2 at the command-line for on-line help.

Chapter 10

Radio-navigation block reference

This chapter provides a detailed description of the SIMULINK implementation of theVOR and ILS models from chapter 5. If you want to manipulate these blocks, or gaina better insight in the block structure, it is recommended to compare the internalblock equations with the descriptions from this chapter. The internal block equationshave been hidden behind a mask interface; refer to section 7.8 for more informationabout the mask interface of the FDC systems.

10.1 The radio-navigation blocklibrary

All radio-navigation blocks have been collected in the SIMULINK library NAVLIB,which is shown in figure 10.1. It can be accessed from the main FDC library (shownin figure 7.7 of chapter 7) by double-clicking the ‘ILS/VOR radio-nav library’ button,or by typing navlib in the MATLAB command-window. NAVLIB itself consists of twosublibraries: NAVLIB1, which contains the ILS models, and NAVLIB2, which containsthe VOR models. These sublibraries have been shown in figures 10.2 and 10.3.

Figure 10.1: Radio-navigation library NAVLIB

180 Chapter 10. Radio-navigation block reference

Figure 10.2: Sublibrary with ILS models

Figure 10.3: Sublibrary with VOR models

The remainder of this chapter (pages 181 to 192) provides detailed descriptionsof the individual blocks from the radio-navigation library. The blocks have beenlisted in alphabetical order; their locations have been referenced in relation tothe main FDC library and the radio-navigation library.

10.1. The radio-navigation blocklibrary 181

GSerr Main FDC library / ILS/VOR radio-nav / ILS signals / GSerr

Radio-navigation library / ILS signals / GSerr


DescriptionThe block GSerr computes steady-state errors in the glideslope signal. The errors areexpressed in terms of electrical currents, used to drive the glideslope deviation indicatorin the cockpit.

EquationsFor a detailed discussion of the equations from the block GSerr, refer to section 5.1.2.

• Glideslope signal with steady-state errors, [µA]:

igs,actual = KSgs

(igs,nominal + ∆igs

)The multiplication factor KSgs takes into account the offset in glideslope sensitivity Sgs,while the error ∆igs is caused by an offset in the nominal glideslope elevation angle γgs, i.e.by a glideslope misalignment. The signals are expressed in terms of cockpit instrumentcurrents.

Inputsigs,nominal nomimal glideslope current, igs (nominal)

Outputsigs,actual actual glideslope current, including steady-state errors, igs (actual)

ParametersThe user must specify the ILS performance category (1, 2, or 3; see figure 5.6 from chap-ter 5), the offset in glideslope sensitivity, and the glideslope misalignment. The offset-values are both expressed as a percentage of the maximum allowable error shown intable 5.2. The parameters can be entered in the mask dialog, which can be opened bydouble-clicking GSerr.

Connectionsin: igs,nominal is retrieved from the block ILS, which determines the nominal ILS signals.

out: igs,actual is in general added to a glideslope noise signal, obtained by GSnoise. Thissignal can e.g. be used as an input signal for an automatic approach controller.

Type browse gserr at the command-line for on-line help.


GSnoise1 (2) Main FDC library / ILS/VOR radio-nav / ILS signals / GSnoise1 (2)

Radio-navigation library / ILS signals / GSnoise1 (2)

TypeMasked subsystem blocks.

DescriptionThe blocks GSnoise1 and GSnoise2 determine glideslope noise signals. GSnoise1 is basedon a noise model from AGARD report R-632 [1], while GSnoise2 uses an alternative mo-del from NASA report CR-2022 [22]. These reports have also been referenced in the blockicons. The noise signals are expressed in terms of the electrical currents, used to drive theglideslope deviation indicator in the cockpit.

EquationsFor a detailed discussion of the equations from the blocks GSnoise1 and GSnoise2, referto section 5.1.2.

• Glideslope noise, [µA]:

∆i∗gs(s) = Hgs(s) w4(s)where ∆i∗gs is the glideslope noise, w4 is a white noise signal, generated internallywithin the block GSnoise1 or GSnoise2, and Hgs is the transfer function of the glide-slope noise filter.

• Transfer function of the glideslope noise filter according to AGARD R-632, used forGSnoise1:

Hgs(s) = σgs

√2Lgs

V1

1 + LgsV s

Note: the value of the airspeed V used by GSnoise1 is assumed to remain constantduring the simulations. This is not entirely accurate, but if this value is set equal to the(final) approach speed of the aircraft, the results are quite usable, keeping in mind thatthis equation only provides an approximation of actual glideslope noise anyhow. Lgsis the scale-length of the glideslope noise; σgs is the standard-deviation.

• Transfer function of the glideslope noise filter according to NASA CR-2022, used forGSnoise2:

Hgs(s) =3.9875

0.25 + sInputs

None.

Outputs∆i∗gs glideslope noise, D_igs*

ParametersFor the AGARD R-632 version (GSnoise1), the user must specify the scale length Lgs, thestandard deviation σgs, and the approach speed of the aircraft. The parameters can be setin the mask dialog, which is opened after double-clicking GSnoise1. The NASA CR-2022version (GSnoise2) doesn’t require any parameters to be entered.

Connectionsin: no connections.out: ∆i∗gs is meant to be added to the original glideslope current igs. If steady-state errors

are also taken into account, this summation must take place after sending the glide-slope current through the block GSerr first. The resulting signal can e.g. be used asan input signal for an automatic approach controller.

Type browse gsnoise at the command-line for on-line help.


ILS Main FDC library / ILS/VOR radio-nav / ILS signals / ILS

Radio-navigation library / ILS signals / ILS


DescriptionThe block ILS determines the nominal ILS signals for a given position of the aircraft. Theblock also computes some closely associated properties, which provide more informationabout the current position of the aircraft with respect to the runway and the glideslopeand localizer reference planes. The validity of the glideslope and localizer signals is veri-fied by an internal masked subsystem block, called ILStest.

EquationsFor a detailed discussion of the equations from the block ILS, refer to section 5.1.1.

• Glideslope and localizer deviations, expressed in terms of electrical currents throughthe ILS indicators in the cockpit, [µA]:

igs = Sgs εgs

iloc = Sloc Γloc

• Glideslope and localizer deviation angles, [rad]:

εgs = γgs + arctan( H f

Rgs

)Γloc = arcsin

(dlocRloc

)• Coordinates of the aircraft in the horizontal plane of the runway-fixed reference frame,

[m]:

x f = (xe − xRW) cos ψRW + (ye − yRW) sin ψRW

y f = −(xe − xRW) sin ψRW + (ye − yRW) cos ψRW

• Height of the aircraft above aerodrome level, [m]:

H f = H − HRW

• Distance from the aircraft to the glidepath, measured perpendicular to the nominalglidepath, [m]:

dgs = (Rgs tan γgs + H f ) cos γgs

• Ground-distances from the aircraft to the glideslope and localizer transmitters, [m]:

Rgs =√

(xgs − x f )2 + (y f − ygs)2

Rloc =√

y f2 + (xloc − x f )2

• Two flags, which show whether the position of the airplane allows accurate receptionof the glideslope and localizer signals, are determined with logical Boolean expressions,derived from the glideslope and localizer coverage diagrams from figures 5.5 and 5.3 inchapter 5. These flags are called GS_flag and LOC_flag, respectively; they are set equalto 1 if the signals are reliable, and 0 if they are not. These flags are computed in theinternal masked subsystem block ILStest; type browse ilstest at the command-linefor more information about this block.

Inputsuils = [ xe ye H ]T aircraft coordinates and altitude, uils


Outputsyils1 = [ igs iloc ]T nominal currents through ILS indicators, yils1

yils2 = [ εgs Γloc ]T angles between nominal and current ILS planes, yils2

yils3 = [ x f y f H f dgs Rgs Rloc ]T distances defining the aircraft’s approach position, yils3

yils4 = [ GS_flag LOC_flag ]T flags defining the validity of the ILS signals, yils4

ParametersThe following parameters can be defined in the mask dialog of ILS, which can be openedby double-clicking this block:

• the runway heading ψRW ,

• the coordinates xRW , yRW , and HRW of the origin of the runway-fixed referenceframe, measured with respect to the Earth-axes,

• the distance xloc from the runway threshold to the localizer antenna, measured alongthe runway centerline (see figure 5.1),

• the distance xgs from the threshold to the position on the runway centerline that isperpendicular to the glideslope antenna (see figure 5.1),

• the distance ygs from the glideslope antenna to the position on the runway centerlinethat is perpendicular to the glideslope antenna (see figure 5.1),

• the nominal glideslope angle γgs.

Connectionsin: uils is a subset of the state vector x from the nonlinear aircraft model.

out: in the example system ILS example, the outputvector yils1 is sent through the steady-state error blocks GSerr and LOCerr, which both express ILS offset errors in termsof electrical currents for the cockpit indications. The other output vectors are nor-mally primarily used for evaluations of simulation results. ILS example sends alloutputvectors to the MATLAB workspace by means of To Workspace blocks.

Type browse ils at the command-line for on-line help.


ILS example Main FDC library / ILS/VOR radio-nav / ILS signals / ILS example

Radio-navigation library / ILS signals / ILS example

TypeMasked subsystem block (contents accessible without unmasking).

DescriptionThe subsystem ILS example demonstrates how the nominal ILS block ILS and the errorblocks GSerr, GSnoise1, LOCerr, and LOCnoise1 can be combined to build a completeILS simulation model. The subsystem has been masked to generate an appropriate block-icon, but its contents are accessible without unmasking (hence, its light-blue backgroundcolour). Slightly modified versions of this block have been included in the autopilot block-library APlib; see chapter 15 for more information.

Subsystems and/or blocksThe subsystem ILS example contains five masked subsystem blocks:

ILS computes the nominal ILS signals,

GSerr incorporates a steady-state error in the glideslope signal,

GSnoise1 computes glideslope noise,

LOCerr incorporates a steady-state error in the localizer signal,

LOCnoise1 computes localizer noise.

The disturbance models used in ILS example are all based upon ref.[1]. If you want toapply the alternative noise blocks GSnoise2 and LOCnoise2 it is necessary to update thissubsystem. Since noise will cause simulations to slow down considerably, the ILS blockli-brary also offers a version of ILS example without the glideslope and localizer noise.

The signals that leave the error blocks represent electrical glideslope and localizer cur-rents, needed to drive the cockpit instruments. In ILS example, these signals are convertedback to the error angles εgs and Γloc by multiplication with the factors 1/Kgs and 1/Kloc,respectively.


Outputsεgs glideslope deviation angle, including system offset and noise, epsilon_gs

Γloc localizer deviation angle, including system offset and noise, Gamma_loc

During simulations, the time-trajectories of the nominal ILS signals (excluding ILS offset-errors and noise!) and some interim results from the block ILS are collected in the MAT-LAB workspace variable yils. Each row from this matrix corresponds to the vector yils at acertain data-point:

yils = [ yils1T yils2

T yils3T yils4

T ]T

with:

yils1 = [ igs iloc ]T nominal currents through ILS indicators, yils1

yils2 = [ εgs Γloc ]T angles between nominal and current ILS planes, yils2

yils3 = [ x f y f H f dgs Rgs Rloc ]T distances defining the aircraft’s approach position, yils3

yils4 = [ GS_flag LOC_flag ]T flags defining the validity of the ILS signals, yils4

The flags in yils4 provide information about the validity of the ILS signals, based on the


ILS coverage depicted in figures 5.5 and 5.3 of chapter 5. See section 5.1.1 for more infor-mation about the nominal ILS signals and approach geometry.

Note: to plot the resulting time-trajectories of the ILS signals, it is necessary to create acompatible time-basis in the MATLAB workspace as well. This can be achieved by includ-ing a Clock block, which is connected to a To Workspace block, but in the special casewhere the subsystem ILS example is connected to the nonlinear aircraft model Beaver (seethe description of Beaver Level 1 in chapter 8) this is already taken care of within the air-craft model itself.

ParametersThe user must manually specify the parameters of ILS, GSerr, GSnoise1, LOCerr, and LOC-noise1 and the multiplication blocks 1/Sgs and 1/Sloc by double-clicking these blocks in-dividually.

For the ILS block, this includes setting the runway heading, Earth-coordinates of the ori-gin of the runway-fixed reference frame, the position of the glideslope and localizer an-tennas relatively to the runway threshold, and the nominal glideslope angle. For theGSerr and LOCerr blocks, it is necessary to define the ILS performance category, the offsetpercentages, and the nominal glideslope angle or the distance between the runway thresh-old and localizer antenna. The GSnoise1 and LOCnoise1 blocks require the definition ofa scale length, the standard deviation of the noise, and the final approach speed of theairplane. And finally, the multiplication factors 1/Kgs and 1/Kloc require the definition ofthe nominal glideslope angle and the distance from the threshold to the localizer antenna.

Note: some parameters have to be defined multiple times in different blocks within ILSexample; it is up to the user to make sure that all parameters are set consistently!



out: εgs and Γloc can e.g. be used as input signals for an automatic approach controller.This has been demonstrated in the systems Apilot2 and Apilot3, which will be dis-cussed in chapter 15 (these systems use slightly modified versions of ILS example,which have been included in the library APlib). The other signals are primarilyused to evaluate simulation results; yils is sent to the MATLAB workspace for post-simulation processing.

Type browse ilsxmpl at the command-line for on-line help.


LOCerr Main FDC library / ILS/VOR radio-nav / ILS signals / LOCerr

Radio-navigation library / ILS signals / LOCerr


DescriptionThe block GSerr computes steady-state errors in the localizer signal. The errors are ex-pressed in terms of electrical currents, used to drive the localizer deviation indicator inthe cockpit.

EquationsFor a detailed discussion of the equations from the block LOCerr, refer to section 5.1.2.

• localizer signal with steady-state errors, [µA]:

iloc,actual = KSloc (iloc,nominal + ∆iloc)

The multiplication factor KSloc takes into account the offset in the localizer sensitivity Sloc,while the error ∆iloc represents an offset in the localizer reference plane, i.e. a deviationfrom the extended runway centerline. The signals are expressed in terms of cockpit in-strument currents.

Inputsiloc,nominal nomimal localizer current, iloc (nominal)

Outputsiloc,actual actual localizer current, including steady-state errors, iloc (actual)

ParametersThe user must specify the ILS performance category (1, 2, or 3; see figure 5.6 from chap-ter 5), the offset in localizer sensitivity, the localizer misalignment, and the distance fromthe runway threshold to the localizer antenna. The offset-values are both expressed as apercentage of the maximum allowable error according to table 5.1. The parameters canbe entered in the mask dialog, which can be opened by double-clicking LOCerr.

Connectionsin: iloc,nominal is retrieved from the block ILS, which determines the nominal ILS signals.

out: iloc,actual is in general added to a localizer noise signal, obtained by LOCnoise. Thissignal can e.g. be used as an input signal for an automatic approach controller.

Type browse locerr at the command-line for on-line help.


LOCnoise1 (2) Main FDC library / ILS/VOR radio-nav / ILS signals / LOCnoise1 (2)

Radio-navigation library / ILS signals / LOCnoise1 (2)

TypeMasked subsystem blocks.

DescriptionThe blocks LOCnoise1 and LOCnoise2 determine localizer noise signals. LOCnoise1 isbased on a noise model from AGARD report R-632 [1], while LOCnoise2 uses an alterna-tive model from NASA report CR-2022 [22]. These reports have also been referenced inthe block icons. The noise signals are expressed in terms of the electrical currents, used todrive the localizer deviation indicator in the cockpit.

EquationsFor a detailed discussion of the equations from the blocks LOCnoise1 and LOCnoise2,refer to section 5.1.2.

• Localizer noise, [µA]:

∆i∗loc(s) = Hloc(s) w5(s)where ∆i∗loc is the localizer noise, w5 is a white noise signal, generated internally withinthe block LOCnoise1 or LOCnoise2, and Hloc is the transfer function of the localizernoise filter.

• Transfer function of the localizer noise filter according to AGARD R-632, used for LOC-noise1:

Hloc(s) = σloc

√2Lloc

V1

1 + LlocV s

Note: the value of the airspeed V used by LOCnoise1 is assumed to remain constantduring the simulations. This is not entirely accurate, but if this value is set equal to the(final) approach speed of the aircraft, the results are quite usable, keeping in mind thatthis equation only provides an approximation of actual localizer noise anyhow. Lloc isthe scale-length of the localizer noise; σloc is the standard-deviation.

• Transfer function of the localizer noise filter according to NASA CR-2022, used forLOCnoise2:

Hloc(s) =5 (1.5 + s)

(0.35 + s)(10 + s)Inputs

None.

Outputs∆i∗loc localizer noise, D_iloc*

ParametersFor the AGARD R-632 version (LOCnoise1), the user must specify the scale length Lloc,the standard deviation σloc, and the approach speed of the aircraft. The parameters canbe set in the mask dialog, which is opened after double-clicking LOCnoise1. The NASACR-2022 version (GSnoise2) doesn’t require any parameters to be entered.

Connectionsin: no connections.out: ∆i∗loc is meant to be added to the original localizer current iloc. If steady-state errors

are also taken into account, this summation must take place after sending the local-izer current through the block LOCerr first. The resulting signal can e.g. be used asan input signal for an automatic approach controller.

Type browse locnoise at the command-line for on-line help.


VOR Main FDC library / ILS/VOR radio-nav / VOR signals / VOR

Radio-navigation library / VOR signals / VOR


DescriptionThe block VOR computes the nominal VOR signals that will be received on board theaircraft if it flies at a certain position relatively to the VOR ground station. In addition,it computes the ground-distance to the VOR antenna, warning flags which alert the userif the aircraft flies outside the VOR range, and a flag that tells us whether the airplane isheading to or from the VOR station.

EquationsFor a detailed discussion of the equations from the block VOR, refer to section 5.2.1.

• VOR radial that corresponds to the current position of the aircraft, [rad]:

QDR = arctan(

ye − yVORxe − xVOR

)• Deviation from the desired VOR bearing, [rad]:

ΓVOR = CD −QDR

• Ground-distance from the aircraft to the VOR station, [m]:

RVOR =√

(xe − xVOR)2 + (ye − yVOR)2

• A Cone of Silence flag (‘C.O.S.-flag’) is set equal to 1 if the airplane flies inside the Coneof Silence region, i.e. if:

arctan(

H − HVORRVOR

)> 90 − (40 to 60)

In practice, the smallest cone-size has been used; this corresponds to an opening angleof 2 ∗ 40. See figure 5.12 in chapter 5 for more details.

• A Range flag is set to 1 if the aircraft flies outside the area where the VOR signals canreliably be received, i.e. if:

RVOR > Range

where:

Range = 1000(−2.3570 · 10−6(H − HVOR)2 + 5.7087 · 10−2(H − HVOR) + 80.8612

)• A To/From flag is set to 1 if the aircraft is heading towards the VOR station, i.e. if:

|ψ−QDR| > 90

Inputsuvor = [ xe ye H ]T aircraft coordinates and altitude, uvor

ψ heading of the aircraft, psi

Outputsyvor1 = ΓVOR nominal VOR bearing, excluding system offset, yvor1yvor2 = RVOR ground distance from aircraft to VOR station, yvor2yvor3 = [ C.O.S.-flag Range-flag ]T flags specifying validity of VOR signals, yvor3yvor4 = ToFrom To/From flag, yvor4

ParametersThe user must specify the coordinates of the VOR station measured in the horizontalplane, relative to the initial position of the aircraft. Also, the elevation of the VOR station


and the Course Datum (the reference VOR bearing which the aircraft is supposed to track)must be entered. This can be done after double-clicking the block VOR.

Connectionsin: uvor is a subset of the state vector x from the nonlinear aircraft model. Also, the

heading ψ corresponds to one of the state variables from x.

out: in the example system VOR example, the outputsignal yvor1 is sent through thesteady-state error block VORerr. The other outputs are normally primarily used forevaluations of simulation results. VOR example sends the combined outputvectoryvor to the MATLAB workspace by means of a To Workspace block.

Type browse vor at the command-line for on-line help.


VORerr Main FDC library / ILS/VOR radio-nav / VOR signals / VORerr

Radio-navigation library / VOR signals / VORerr


DescriptionThe block VORerr incorporates a steady-state error in the nominal VOR signal.

Note: contrary to the ILS steady-state errors, the result is expressed in terms of the VORdeviation angle, not an electrical current. Also, the FDC toolbox does not include VORnoise models.

EquationsThe steady-state error is implemented by multiplying the nominal VOR signal with a gainvalue that is slighty offset from the nominal value 1. Some experimental measurementsof overall VOR accuracy have been given in section 5.2.3.

• VOR signal with steady-state error, [rad]:

ΓVOR,actual = KVORerr · ΓVOR,nominal

The multiplication factor KVORerr takes into account the offset in the measured VOR bear-ing. It is equal to 1 + ε

100 with ε the overall percentile VOR system error, specified by theuser.

InputsΓVOR,nominal nomimal VOR bearing, Gamma_VOR (nominal)

OutputsΓVOR,actual indicated VOR bearing, includes system offset, Gamma_VOR (actual)

ParametersThe user must specify the overall VOR system error, expressed in a percentage of thenominal value. This figure can be entered after double-clicking the block VORerr.

Connectionsin: ΓVOR,nominal is retrieved from the block VOR, which determines the nominal VOR

signals.

out: ΓVOR,actual can e.g. be used as an input signal for an automatic VOR-tracking con-troller.

Type browse vorerr at the command-line for on-line help.


VOR example Main FDC library / ILS/VOR radio-nav / VOR signals / VOR example

Radio-navigation library / VOR signals / VOR example

TypeMasked subsystem block (contents accessible without unmasking).

DescriptionThe subsystem VOR example demonstrates how the blocks VOR and VORerr can be com-bined to build a complete VOR simulation model. The subsystem has been masked togenerate an appropriate block-icon, but its contents are accessible without unmasking(hence, its light-blue background colour). A slightly modified version of this block hasbeen included in the autopilot blocklibrary APlib; see chapter 15 for more information.

Subsystems and/or blocksThe subsystem VOR example contains two masked subsystem blocks:

VOR computes the nominal VOR signal,

VORerr incorporates a steady-state error in the VOR signal.


OutputsΓVOR VOR bearing, including system offset, Gamma_VOR

During simulations, the time-trajectories of the VOR signals and some interim resultsfrom the block VOR are collected in the MATLAB workspace variable yvor. Each row fromthis matrix corresponds to the vector yvor at a certain data-point, which is defined as:

yvor = [ yvor1 yvor2 yvor3T yvor4 ]T

with:

yvor1 = ΓVOR nominal VOR bearing, excluding system offset, yvor1yvor2 = RVOR ground distance from aircraft to VOR station, yvor2yvor3 = [ C.O.S.-flag Range-flag ]T flags specifying validity of VOR signals, yvor3yvor4 = ToFrom To/From flag, yvor4

C.O.S. is an abbreviation for Cone of Silence, which has been discussed in section 5.2.2. In-formation about the range of the VOR signals (i.e. the VOR coverage) can also be foundthere. For information about the To/From flag, see section 5.2.1.

Note: to plot the resulting time-trajectories of the VOR signals, it is necessary to createa compatible time-basis in the MATLAB workspace as well. This can be achieved by in-cluding a Clock block, which is connected to a To Workspace block, but in the special casewhere the subsystem VOR example is connected to the nonlinear aircraft model Beaver(see the description of Beaver Level 1 in chapter 8) this is already taken care of within theaircraft model itself.

ParametersThe user must manually specify the parameters of VOR and VORerr by double-clickingthese blocks individually. For the VOR block, this includes setting the Earth-axes X and Y-coordinates of the VOR transmitter relative to the aircraft at the start of the simulation (t =0), the altitude of the VOR transmitter above sea level, and the ‘Course Datum’, which isthe reference radial set on the VOR deviation indicator in the cockpit. See section 5.2.1for more details about these parameters. In the VORerr block, the percentile VOR systemerror must be set — some guidelines have been provided in section 5.2.3.




out: ΓVOR can e.g. be used as an input signal for an automatic VOR-tracking controller.This has been demonstrated in the systems Apilot2 and Apilot3, which will be dis-cussed in chapter 15 (these systems use a slightly modified version of VOR examplefrom the library APlib). The other signals are primarily used to evaluate simulationresults; yvor is sent to the MATLAB workspace for post-simulation processing.

Type browse vorxmpl at the command-line for on-line help.

Chapter 12

Support functions reference

The FDC toolbox includes several support utilities that assist the user in interactingwith the simulation models and analytical tools, taking care of tasks such as toolboxinitialisation, directory selection, data handling, on-line help display, and screen for-matting. In addition, some model-specific functions help with the definition of mo-del parameters and the presentation of simulation results. Some of the more genericsupport utilities may be useful for other applications too.

This chapter provides a detailed overview of all FDC support functions. With afew exceptions, all programs discussed here are located in the PROGRAMS subdirec-tory of the FDC toolbox. See the previous chapter for a description of the analyticalfunctions of the FDC toolbox; see chapter 15 for information about the support utili-ties for the autopilot models.

12.1 A brief overview of the support utilities

Although the support functions perform a quite diverse number of tasks, we canroughly distinguish five main categories:

1. Toolbox initialisation functionsInitialisation of the toolbox is handled by the utility FDC, which calls the func-tions FDCINIT and FDC_SPLASH and displays a welcome message. FDCINITappends the FDC directories to the MATLAB path, and provides a simple userinterface to change these directories when required, e.g. in order to enhancethe toolbox with new models or tools; FDC_SPLASH displays a splash-screenfor the FDC toolbox.

2. Directory functionsThe function FDCDIR assists in obtaining full pathnames of arbitrary FDC sub-directories. DATADIR and HELPDIR provide quick pointers to the DATA andHELP subdirectories, using FDCDIR to build the respective directory paths.

3. Data load functionsThe function FDCLOAD is used to retrieve FDC datafiles in general. DATLOAD,LINLOAD, MATLOAD, and TRILOAD apply this utility to retrieve datafiles withextensions .DAT, .LIN, .MAT, and .TRI, respectively.

208 Chapter 12. Support functions reference

4. Generic helper functionsBROWSE displays HTML helpfiles in the default web browser or the MAT-LAB help browser, NEWMSGBOX displays simple message boxes, NUM2STR2converts numericals to strings, SCREENSIZE returns screen dimensions in sev-eral units, and TXTMENU displays menus of choices in the MATLAB command-window.

5. Model-specific helper functionsMODBUILD is used to generate the datafile AIRCRAFT.DAT, which contains theaircraft model parameters. FIXSTATE can be used to initialize the xfix block inthe SIMULINK model of the aircraft (see chapter 8), RESULTS re-orders aircraftsimulation results in the MATLAB workspace, and RESPLOT is a quick anddirty plotting function to visualise those results.

In the next sections these support functions will be described in more detail. Typehelp fname , helpwin fname , or browse fname to obtain on-screen help for the func-tion fname in the MATLAB command-window, the MATLAB help window, or yourweb browser (or alternatively: the MATLAB help browser), respectively.

12.2 Toolbox initialisation functions

The toolbox initialisation is handled by the startup utility FDC. It calls two other sup-port functions: FDC_SPLASH, which displays a splash-screen, and FDCINIT, whichmaintains a list of FDC directories to be appended to MATLAB search path and al-lows the user to modify this list if required.

12.2.1 FDC

The startup utility FDC organises the initialisation of the FDC toolbox. A detailedexplanation of all steps involved in the installation and initialisation of the toolboxhas already been given in section 7.4, but in short the initialisation procedure comesdown to running FDC by navigating to the FDC root-directory (using CD or CHDIR),typing fdc at the command-line, and validating (and possibly altering) the list ofdirectories shown in the command window.

FDC will first call FDC_SPLASH, which displays the splash-screen from figure 7.2,and next FDCINIT, which manages the list of FDC directories and appends them tothe MATLAB search path (figures 7.3 to 7.5). Finally, the welcome message from fig-ure 7.6 will be shown to indicate that the software is ready. The source file FDC.Mis located in the FDC root-directory, to provide easy access; FDC_SPLASH.M and FD-CINIT.M are located in the PROGRAMS subdirectory.

The modifications made to the MATLAB search path by FDCINIT remain effectiveuntil MATLAB itself is closed; they are not stored permanently. For this reason, theinitialisation routine FDC needs to be run every time the toolbox is to be used afterstarting a new MATLAB session. If the toolbox is used frequently, it may be conve-nient to permanently include the FDC root-directory to the MATLAB path, so thatFDC can be started right away by typing fdc, without having to navigate to the FDCroot-directory first.

12.2. Toolbox initialisation functions 209

$FDCROOT$ aircraft

apilot

data

doc

examples

help

navigate

programs

tools

wind

Figure 12.1: Default FDC directory structure

12.2.2 FDCINIT

Since the toolbox has been organised over several subdirectories, it is necessary forthe FDC directories to be appended to the MATLAB path, in order to obtain directcommand-line access to all functions, models, and helpfiles. The function FDCINIThandles this task, and it provides a simple user-interface to accommodate changesin the FDC directory structure, which may be useful should the toolbox ever be reor-ganised or enhanced in the future.

Figure 12.1 shows the default directory structure of the FDC toolbox. See sec-tion 7.6 for an explanation of the purpose of these directories. $FDCROOT$ representsthe default location of the root-directory of the FDC toolbox, which is equal to:

$FDCROOT$ = $MATLABROOT$\TOOLBOX\FDC14

with $MATLABROOT$ being the root-directory of MATLAB itself. By default, FDCINITuses this directory list for the toolbox initialisation; these are the default directoriesto be appended to the MATLAB path.

If the directory list does not correspond to the actual directory structure, it can bemodified by the user, using the relevant menu options from FDCINIT. For instance, insection 7.4 it was explained how the FDCINIT menu options can be used to specify adifferent FDC root-directory, should the toolbox be installed to a non-default location.Similar options are available to modify the list of FDC subdirectories.

FDCINIT will append the FDC directories to the MATLAB path after the user con-firms the directory definitions. The confirmed list will be stored in the file FDC.INI

in the directory PROGRAMS (the location that also holds the file FDCINIT.M). Eachnext time FDCINIT is started, it will use the list from FDC.INI instead of the defaultlist from figure 12.1. The default list will be used if the file FDC.INI cannot be found;deleting this file makes FDCINIT behave as if it was run for the first time.


Notice that FDCINIT will not verify if specified directories actually exist. Therefore,if the user uses the options to add, remove, or rename (sub-) directories, a mismatchbetween the actual structure of the toolbox and the directory list used by FDCINITwill occur. It is the responsibility of the user to ensure that the directory list used byFDCINIT corresponds to the actual situation.

Although the options to change the directories provide flexibility, the mandatorydirectory verification during initialisation may become rather inconvenient if youdon’t intend to change the directory structure often. For this reason, FDCINIT offersan option to suppress the directory-check for future sessions. To restore the directorymodification options afterward, it is necessary to delete the file FDC.INI. Figure 7.5shows the directory verification process and the ‘suppress’ option in action.

12.2.3 FDC_SPLASH

FDC_SPLASH displays the splash screen for the FDC toolbox, which was shown ear-lier in figure 7.2, until the user presses ‘Enter’ or clicks inside the splash-screen withthe mouse pointer. It is relatively easy to modify this function to display other kindsof graphics, so re-using the splash-screen code for other purposes is quite possible.The source-file FDC_SPLASH.M can be found in the directory PROGRAMS.

12.3 Directory functions

Some FDC functions require access to specific subdirectories. To assure flexibilityand maintainability of the code, especially with regard to future changes and en-hancements, a dedicated function FDCDIR is used to determine the full pathnamesof FDC directories. The functions DATADIR and HELPDIR handle the special cases oflocating the FDC data and help directories, respectively.

12.3.1 FDCDIR

The utility FDCDIR generates full pathnames for FDC directories. In practice, thisfeature is primarily used to locate the DATA and HELP directories of the FDC toolbox,but it can handle other subdirectories too. This offers the flexibility that is requiredto deal with the FDCINIT feature to change the FDC root- and subdirectories.

Usage:

D = fdcdir returns the root-directory of the FDC toolbox into the string variable D.

D = fdcdir(NAME) returns the complete path of the FDC subdirectory specified inthe string variable NAME.

D = fdcdir(NAME1,NAME2) returns the complete path of the FDC sub-subdirectoryspecified in the string variable NAME2, which itself is contained in the FDC sub-directory specified in the string variable NAME1.

More input arguments are allowed to specify deeper subdirectory levels, which maybe useful for future toolbox enhancements — currently, this option is not yet verypractical. Notice that all input arguments must be string variables.

12.4. Data load functions 211

Examples:

Let’s assume that the FDC root-directory as specified in FDC.INI (which was gener-ated by the function FDCINIT) is:

c:\matlab\toolbox\fdc14

(using MS Windows path separators for convenience; replace these by the relevantsymbology if you use a different operating system).

Then:D = fdcdir will return:

D = “c:\matlab\toolbox\fdc14”D = fdcdir(’models’) will return:

D = “c:\matlab\toolbox\fdc14\models”and:

D = fdcdir(’models’,’aircraft’) will return:D = “c:\matlab\toolbox\fdc14\models\aircraft”.

FDCDIR will verify whether the specified path actually exists; a warning messagewill be displayed if the path cannot be found. Since ..\fdc14\models\aircraft is nota standard FDC directory, the above examples will in fact cause this path warningmessage to be displayed, unless this directory was created by the user.

12.3.2 DATADIR, HELPDIR

In practice, the FDCDIR utility is mainly used for referencing the DATA and HELP

directories of the FDC toolbox. The complete path to these directories can be ob-tained by calling FDCDIR with the input argument ’data’ or ’help’, respectively:fdcdir(’data’) or fdcdir(’help’).

However, to simplify this even further, and also to get rid of this last part of di-rectory hard-coding, two simple ‘wrapper functions’ DATADIR and HELPDIR werecreated to take care of these FDCDIR calls. All other FDC functions that need toknow the location of these directories will simply call these wrapper functions, in-stead of hard-coding the actual pathname or calling FDCDIR directly. If you evercreate additional FDC functions that require access to these directories, it is highlyrecommended to use the same strategy.

DATADIR can be run by simply typing datadir at the command-line, which willyield the text string “$FDCROOT$\DATA” ($FDCROOT$ being the FDC root-directory).HELPDIR can be called by typing helpdir at the command-line, which will return thestring “$FDCROOT$\HELP”. Should the location of these directories ever be changedin the future (for whatever reason), the only files that need to be changed to reflectthis change will be DATADIR.M and HELPDIR.M.

12.4 Data load functions

The FDC toolbox uses a separate data directory (the subdirectory DATA) to store vari-ous kinds of information, such as model parameters, trimmed flight conditions, and


system matrices of linearized models. Although different file-extensions will be usedto distinguish different kinds of data, all datafiles will use the MATLAB data formatwhich is normally used for MAT-files.

Model parameter files can be recognized by the extension .DAT, linearized modeldatafiles use the extension .LIN, and trimmed flight conditions use the extension.TRI. A support function FDCLOAD allows quick retrieval of arbitrary datafiles fromthe data-directory, while some dedicated functions are available to retrieve files of aspecific type (e.g. DATLOAD for DAT-files).

12.4.1 FDCLOAD

The utility FDCLOAD retrieves datafiles from the FDC data-directory, using a graph-ical user-interface that is built on the UIGETFILE command of MATLAB. The data-directory is used as starting point to browse through the datafiles; the exact locationof this directory is retrieved using the function DATADIR (see section 12.3.2).

Usage:

fdcload(’ext’) opens a file browser, listing all files with extension ext that arepresent in the data directory, and loads the selected file into the base workspace.

fdcload(’ext’,’datatype’) additionally allows the specification of a short descrip-tion of the data type, which will be shown in the title bar of the file browser win-dow (see for instance figure 12.2, where the specified ’datatype’ description is’model-definition data’).

In both cases, the user can select a file from the list, or navigate to a different directoryto select a file from elsewhere. It is allowed to use wildcards ? and *, and the file-extension may have more than three characters. Double extensions are possible too,e.g. ’ext1.ext2’. In addition, a default filename can be specified by replacing ’ext’by [filesep ’filename.ext’], where ’filename.ext’ is the required default file.Notice that there is no initial protection against specifying a non-existing filename;a warning message will be displayed only when the user actually tries to open anon-existing file from the load dialog window.

If the selected file does exist, it will be downloaded into the base workspace whenthe user clicks the ‘Open’ button. Nothing will happen if the ‘Cancel’ button isclicked instead or if the load dialog window is closed. Regardless of the specifiedextension, the datafile must use the MATLAB file-format (i.e. the format normallyused for MAT-files); FDCLOAD uses the LOAD command with the -mat option. FD-CLOAD does not yet support ASCII datafiles. To change this load behaviour, it willbe necessary to edit the FDCLOAD.M file accordingly.

12.4.2 DATLOAD, LINLOAD, MATLOAD, and TRILOAD

The following default file-extensions are used to store specific types of FDC data:

• DAT-files, used to store model definition data (e.g. aircraft model parameters),

• LIN-files, used to store system matrices of linearized aircraft models,

• TRI-files, used to store trimmed flight conditions.

12.4. Data load functions 213

Figure 12.2: File browser window that is displayed when using DATLOAD

In addition, MAT-files may be used to store general MATLAB data. The functions DAT-LOAD, LINLOAD, TRILOAD, and MATLOAD have been designed to simplify the hand-ling of these datafiles. They each call FDCLOAD for their respective file-extension,which means that an appropriately configured file-browser will be displayed, allow-ing the user to select a file for loading into the base MATLAB workspace.

Usage:

datload will open a file browser, listing all available DAT-files in the FDC data-directory. The user must select a file from the list; no default file is specified. It isstill possible to select a different filetype and/or navigate to a different directory,using the selection options from the file browser.

datload(’fname’) does the same, but pre-selects the file fname.dat. The file, exten-sion, and directory can be overruled via the file browser.

linload, matload, and triload do the same for LIN-, MAT-, and TRI-files, respec-tively, again allowing optional pre-selection of a specific file.

Example:

Figure 12.2 shows the file browser that will be displayed after typing datload at thecommand-line.1 In this example, the file AIRCRAFT.DAT has been selected by the user(and thus highlighted in the file list); this file will be loaded into the base workspaceif the user subsequently clicks on the ‘Open’ button. An almost similar situationwill be seen when typing datload(’aircraft’), except that in that case the filenameAIRCRAFT.DAT will be highlighted in the ’File name’ field, instead of the file-list.

1The figure shows what the file browser will look like on a Windows system. The lay-out will differfor other operating systems, but the functionality of the file browser will be roughly the same.


12.5 Generic helper functions

A collection of helper functions assist with other support tasks, such as displayingon-line help information, screen formatting, string formatting, and showing messageboxes. These helper functions are generic in nature, which means that they may bere-used for other purposes than the FDC toolbox too.

12.5.1 BROWSE

The function BROWSE displays HTML files using the default web browser or theMATLAB help browser. It provides a convenient way to implement an on-line helpsystem for MATLAB toolboxes and SIMULINK blocksets, based on HTML formattingand linking. Although it was specifically designed to deal with FDC helpfiles, it canalso be used to display HTML files from other sources. In comparison to the standardMATLAB WEB command, BROWSE provides a more user-friendly way to handle thenames of the requested helpfile and its source directory.

By default, the standard web browser is used instead of the MATLAB help browser.One reason for this choice is that early versions of the MATLAB help browser mayhave problems with modern web technologies such as Cascading Style Sheets, butthe browser choice in general is mainly a matter of personal preference. To use theMATLAB help browser instead, an optional argument -mlhelp must be included inthe function call; see the examples below.

BROWSE builds on the WEB command of MATLAB. Depending on your MAT-LAB version, WEB may not support browsers other than Netscape 4 or Internet Ex-plorer version 4 and later. If your browser is not supported, it is recommended toalways use the optional argument -mlhelp when using BROWSE. It is also possibleto change the default browser choice for the function BROWSE by editing the fileBROWSE.M accordingly.

Usage:

browse name or browse(’name’) opens the specified HTML file in the standard webbrowser

browse name -mlhelp or browse(’name’,’-mlhelp’) opens the HTML file in theMATLAB help browser (this switch is functional only for MATLAB release 12 andlater, as earlier MATLAB releases did not yet contain a help browser).

Example:

Consider the helpfile C:\TOOLBOX\HELPFILES\FILENAME.HTML. In order to displaythis file in the web browser, the following entries for ’name’ are valid:

• the full path, including the filename and the file-extension:C:\TOOLBOX\HELPFILES\FILENAME.HTML

• a part of the pathname, including the filename and the file-extension:HELPFILES\FILENAME.HTML

• the filename and file-extension only: FILENAME.HTML

12.5. Generic helper functions 215

• the full path, including the filename, but excluding the file-extension:C:\TOOLBOX\HELPFILES\FILENAME

• a part of the pathname, including the filename, but excluding the extension:HELPFILES\FILENAME

• the filename only, excluding the file-extension: FILENAME

The directory in which the helpfile is located must be present in the MATLAB searchpath. An error message will be shown if the specified file cannot be found. Suitablefile-extensions are .htm, .html, .HTM, and .HTML; all other extensions will be disre-garded and will result in a ’file not found’ error, even if the file does exist! For instance,if a file README.TXT can be read from the MATLAB path, browse(’readme.txt’) willstill yield a ’file not found’ error, because BROWSE will search for README.TXT.HTM

and README.TXT.HTML (both upper and lower-case), not README.TXT.

12.5.2 NEWMSGBOX

The function NEWMSGBOX is an alternative for MATLAB’s MSGBOX function. LikeMSGBOX it displays short messages in a dialog window, but NEWMSGBOX uses adifferent default font (improving readability) and it lacks the options to display anicon, specify the window style, or specify the text-interpreter.

Usage:

newMsgBox(Message) creates a message box that automatically wraps the Message-string to fit an appropriately sized dialog window. Message may be a string vector,string matrix or cell array.

newMsgBox(Message,Title) allows the user to specify the title of the message box.

newMsgBox(Message,Title,Font) allows the user to specify both the title and thefont settings for the message box. Font is a structure that contains the font def-initions; valid fields are (default values for NEWMSGBOX are wrapped in curlybraces):

Font.FontAngle [ normal | italic | oblique]Font.FontUnits [ inches | centimeters | normalized | points | pixels | data ]Font.FontWeight [ light | normal | demi | bold ]Font.FontName requested fontname | default GUI fontname Font.FontSize requested fontsize | default GUI fontsize

(The default GUI fontname and fontsize can be observed from the FactoryUIControl-FontName and FactoryUIControlFontSize screen-properties, respectively; see the MAT-LAB documentation for more information.)

12.5.3 NUM2STR2

NUM2STR2 is a variant of MATLAB’s NUM2STR function, which converts numbersto strings. It differs from NUM2STR in that it allows the user to specify the numberof characters used for the string representation.


Usage:

T = num2str2(X,C) returns a string T with C characters. X is the number to be con-verted to a string. In general, the number of decimal places will be equal to C− 2(which equals the number of characters minus the space reserved for possiblesigns or decimal points). If a number does not fit, it is rounded to a value whichdoes fit in C characters. If necessary, an exponent will be created, still within thereserved space of C characters. In that case the number of decimal places willbe reduced (displaying an exponent typically takes four characters, e.g. ‘E+25’).Leading spaces will be used for numbers that require less than C characters.

Note: values of C smaller than 6 are not accepted and will be automatically con-verted to C = 6! This prevents problems that may occur when trying to show verylarge numbers in too few characters. However, you may still encounter strangeresults if you reserve a very small space for large numbers.

T = num2str2(X) returns a string T with 6 characters.

12.5.4 SCREENSIZE

The utility SCREENSIZE is used to quickly obtain the current screen dimensions andexpress them in several units of measurements. It is particularly useful for the posi-tioning of figures and graphical user-interface windows.

Usage:

s = screensize returns the screen dimensions in pixels,

s = screensize(units) returns the screen dimensions in the units of measurementrepresented by the input string units.

Valid values of the string variable units are ’inches’, ’centimeters’, ’normalized’,’points’, ’pixels’ and ’characters’. Notice that the quotes must be included.The current screen dimensions are returned into the vector s, which is defined asfollows:

s = [left, bottom, width, height]

where left and bottom are the coordinates of the bottom left point of the screen, andwidth and height represent the screen width and -height, expressed in the requestedunits of measurement. For pixel units, the coordinate pair [left,bottom] will always beequal to [1,1]; for all other units of measurement, this pair will be equal to [0,0].

12.5.5 TXTMENU

The utility TXTMENU can be used to display a menu of choices for user input inthe MATLAB command window. The function mimics the behavior of the MENUcommand from older MATLAB versions, which did not yet provide graphical user-interface functions. TXTMENU differs from the MENU command in MATLAB ver-sion 4 or later in that it will always use the command-window regardless of thegraphical capabilities of the workstation.

12.6. Model-specific helper functions 217

Usage:

choice = txtmenu(header, item1, item2, ..., item_n) displays a header string,followed in sequence by the menu-item strings: item1, item2, ... , item_n. Thenumber of the selected menu-item will be returned into the scalar variable choice.There is no upper limit to the total number of menu items.

choice = txtmenu(header, itemlist) where itemlist is a string cell array is also avalid syntax.

Example:

K = txtmenu(’Choose a colour’,’Red’,’Blue’,’Green’) will display the follow-ing menu in the command window:

Choose a colour:1) Red2) Blue3) Green

Select a menu number:

The number entered by the user will be returned into the variable K. For instance,choosing Blue from the example menu above will return K = 2.

12.6 Model-specific helper functions

The support functions discussed in the previous sections were quite generic in na-ture; they can easily be adapted for other purposes than the FDC toolbox if desired.In addition, the toolbox includes some specialised support utilities which assist withthe definition of aircraft model parameters and the post-processing of aircraft simu-lation results. Helper functions for the autopilot models and open-loop examplefunctions will be treated later in their respective chapters.

12.6.1 MODBUILD

The MATLAB macro MODBUILD is used to build a datafile containing aerodynamic,propulsive, geometrical, and mass-distribution parameters for the SIMULINK modelof the Beaver dynamics. To maintain flexibility, these parameters have not been hard-wired within the SIMULINK model itself, but are read from the MATLAB workspaceeach time the model is initialised. Obviously this makes it necessary to load the para-meters into the MATLAB workspace before applying analytical tools (e.g. simulation,linearisation, or trimming).

For the Beaver model, the parameters have been sorted into four variables:

1. the matrix AM (‘Aerodynamic Model’), which contains the aerodynamic para-meters, i.e., the stability and control derivatives of the Beaver,

2. the matrix EM (‘Engine Model’), which contains the propulsive stability andcontrol derivatives,


3. the vector GM1 (‘Geometry & Mass distribution’), which contains the basicgeometrical properties (wing span, wing area, mean aerodynamic chord, etc.),the mass of the airplane, and the moments and products of inertia1,

4. and the matrix GM2, which contains the inertia coefficients.

The exact definitions of these variables can be found in appendix C.

The purpose of MODBUILD is to build these variables and save them to a datafile.By default, the model parameters will be stored in AIRCRAFT.DAT in the subdirec-tory DATA. The saved data can easily be retrieved by means of the utility DATLOAD,which has been described in section 12.4.2. Since the default FDC distribution al-ready includes AIRCRAFT.DAT, it will normally not be necessary to run MODBUILD,unless the datafile is inadvertently deleted. Please do not be mislead by the nameMODBUILD, the utility does not actually ‘build’ complete models, it merely definestheir parameters!

If it is desired to change the values of one or more model parameters (includ-ing mass and/or mass-distribution), the source file MODBUILD.M must be edited,as MODBUILD does not feature a user-interface to change parameter values interac-tively. However, this is less of an inconvenience than it may seem, because the useris assisted in identifying the individual parameters by the comment lines in MOD-BUILD.M, and changing parameters usually won’t be required very often.2 The fileMODBUILD.M has been included in the AIRCRAFT directory, to reflect its close rela-tion to the aircraft model itself.

It should be realized that the parameter structure used for the SIMULINK model ofthe Beaver is only one possible implementation of many. Obviously, there is a directrelation between the structure of the aircraft-dependent parts in this simulation mo-del (see chapter 8) and the shape of the parameter matrices. Models of other aircraftmay require different data structures. For instance, many models use a much moreelaborate set of aerodynamic tables than the Beaver model.

Theoretically, it might be possible to create stringent guidelines for the shapesof data structures, to streamline future model enhancements. However, this has not(yet) been considered for the FDC toolbox, as flexibility is deemed more important.The current SIMULINK implementation of the aircraft model uses a generic overallframework with a series of aircraft-dependent and aircraft-independent blocks thatfunction as ‘black boxes’.

The exceptions to this rule (‘no formal definition of data structures’) are the geo-metry and mass-distribution variables GM1 and GM2, because they are used for thegeneric aircraft-independent parts of the aircraft model. The shape of these varia-bles is in fact stipulated by the structure of the subsystem Aircraft Equations of Motion,which basically forms the core of the aircraft simulation model.

1The airplane’s mass and the moments and products of inertia are treated as model parameters, asthese properties are assumed to remain constant during the motions of interest.

2If MODBUILD.M is edited to implement new parameter values, it is recommended to save this macroto a new file, e.g. MODBUILD1.M. If some parameters are changed more frequently, it may be moreconvenient to include some degree of user-interaction in the MODBUILD program.


Since the mass and mass-distribution are assumed to be constant during simulations,MODBUILD also computes the inertia coefficients from equation (2.29) by substitut-ing the pre-specified values of the moments and products of inertia into the aircraft-independent equations from table 2.2. Future versions of the toolbox may featurecontinuous computation of the geometrical and/or mass properties during simula-tions, which will make it possible to simulate vehicles with non-constant geometryor significant sudden changes in mass and/or mass-distribution, e.g. airplanes witha variable wing-sweep or airplanes that drop significant loads in-flight.

In order to implement a different aircraft model within this framework, we mustadapt or replace the aircraft-dependent parts, (e.g. the aerodynamic and propulsivemodels), perhaps changing some signal lines too.

There are no formal requirements for the data structure of the parameters forthese aircraft-dependent blocks: any data format that is supported by MATLAB andSIMULINK may be used, be it scalar constants, matrices, vectors, arrays, structures,or any combination of these. While it may be useful to use the current implemen-tations of Aeromod and Engmod (and the corresponding parameter definitions) as aguideline or starting point, this is not required.

However, it is recommended to re-use at least the MODBUILD.M code that definesGM1 and GM2, changing only the figures for the lengths, wing-surface, mass, andmoments and products of inertia. Re-using this code not only saves time, but it alsoensures that the data structure of GM1 and GM2 will remain compatible with theaircraft-independent parts in the SIMULINK model.

12.6.2 FIXSTATE

The utility FIXSTATE assists with the definition of a vector xfix in the MATLAB work-space, which is used as a multiplication factor by the block xfix in the aircraft model(see chapter 8). This block is used to constrain state variables to their initial valuesfor analytical purposes.

Normally the state variables in the aircraft model are simply determined by theequations of motion, but in some cases it may be useful to artificially force certainstates to remain equal to their initial values. For instance, we may want to neglectlongitudinal-lateral cross-coupling effects when studying the fundamental aircraftmodes, or emulate an ideal ‘Speed Hold’ flight control law by artificially fixing thevalue of the airspeed.

To this means, the block xfix performs an element-by-element multiplication ofthe time-derivative of the state vector, x, and a gain vector of the same length, xfix.The elements of xfix are identical to either one or zero, meaning: the actual derivativeis either taken into account or completely disregarded. See chapter 8 for a detaileddescription of the block xfix.

FIXSTATE offers four user choices, as shown in figure 12.3:

1. Fix asymmetrical state variables. This causes the variations in asymmetricalstate variables β, p, r, ψ, and ϕ to be neglected, which effectively constrains theairplane to symmetrical motions only. In addition, FIXSTATE will ask whetherthe lateral Earth-coordinate ye needs to be fixed as well.


Figure 12.3: Main menu of FIXSTATE

2. Fix symmetrical states. This causes the variations in the symmetrical state va-riables V, α, q, and θ to be neglected, which effectively constrains the airplane toasymmetrical motions only. In addition, FIXSTATE will ask whether it shouldfix the longitudinal Earth coordinate xe and the altitude H too.

3. Fix arbitrary states. After selecting this option, FIXSTATE will ask the user tospecify a vector with the element numbers of the state variables to be fixed.With the state vector being x = [ V α β p q r ψ θ ϕ xe ye H ]T, we can forinstance fix θ and xe by specifying the vector [8 10], as θ and xe are the eighthand tenth elements of x, respectively.

4. Don’t fix any states. This option resets the default value of xfix, being a unityvector of length 12, taking into account all state derivatives in order to allow allaircraft states to vary freely. The same effect can be achieved by deleting xfixfrom the workspace altogether.

After specifying the states to be fixed, FIXSTATE will try to re-initialize the aircraftmodel. This is only possible if the initial value of the state vector xinco is present inthe workspace. Such initial conditions can be loaded from datafile with TRILOADutility, computed in advance using the trim routine ACTRIM, or entered manually. Ifxinco cannot be found, a warning message will be displayed.

FIXSTATE needs to be run (or xfix needs to be defined manually) prior to simu-lations or other analysis requiring one or more aircraft states to be constrained totheir initial values. For the common situation in which all states are allowed to varyfreely, it will not be necessary to explicitly define xfix, as the block xfix within theaircraft model will automatically use the default value of ones(1,12) if xfix hasn’tbeen defined.


12.6.3 RESULTS

During simulations of the Beaver model, the time-trajectories of the input and out-put signals are collected in the matrices In and Out. The definitions of these varia-bles can be found in appendix D. The MATLAB macro RESULTS extracts individualinput- and output-trajectories from these matrices, using easy-to-understand varia-ble names that closely resemble the symbols from appendix A (e.g. ‘alpha’ for the an-gle of attack α, or ‘deltar’ for the rudder deflection δr). This simplifies post-simulationanalysis, as a command such as plot(time,deltae) is much easier to remember thanthe equivalent plot(time,In(:,1)).

RESULTS will only work correctly if the matrices In and Out correspond to thedefault definitions from appendix D. If the input/output definitions in the aircraftsimulation model are changed, e.g. in order to add more observation variables, im-plement additional input signals, or rearrange the output matrix, it will be necessaryto adapt the RESULTS program too. RESULTS is not able to detect changes in thedefinitions of the matrices In and Out itself and it does not offer any internal error-checking mechanisms to protect against incorrect sizing or definition of the outputmatrices. The source file RESULTS.M is located in the PROGRAMS subdirectory.

12.6.4 RESPLOT

RESPLOT is a very simple MATLAB script that plots time-trajectories of the most im-portant input and output signals of the Beaver model. These signals are: the airspeedV, the angle of attack α, the sideslip angle β, the altitude H, the angular velocities p,q, and r, the Euler angles ψ, θ, and ϕ, the control surface deflections δe, δa, and δr, andthe wind velocity components uw, vw, and ww.

The purpose of RESPLOT is to offer a quick overview of the simulation resultsonly; advanced plotting functions or other visualisation tools are not provided. Tochange the appearance of the plots, or display other results, the RESPLOT.M source-file must be edited. RESPLOT.M can be found in the PROGRAMS directory.

Before running RESPLOT, all relevant time-trajectories need to be present in theMATLAB workspace. This can be ensured by first running RESULTS (after running asimulation involving the Beaver model). RESPLOT does not include error-checkingroutines to verify the availability of the required variables, it just quits with a harderror if those variables cannot be found in the workspace.

Appendix A

Symbols and definitions

This appendix defines the symbols used in this report, and all relevant referenceframes and sign conventions. The units of measurements usually conform to S.I.conventions. Only in some incidental cases, usually involving equations obtainedfrom other literature, non-standard units have been applied. If this is the case, theapplied units will be mentioned specifically in the main text.

Due to the very large number of variables, it could not always be avoided to usethe same symbols for multiple purposes, but most of the times this is not a seriousproblem, because the meaning of a particular symbol usually follows directly fromthe context in which it is used. In the few cases where there is a real chance ofsymbols getting mixed-up, these particular symbols may be overlined, to providethe necessary distinction.

A list of variable names and acronyms used in the FDC toolbox has been includedin appendix E. Several important aircraft model parameters have been listed in ap-pendix B, while appendix C explains the format which was used to implement theaircraft model parameters in SIMULINK.

A.1 List of symbols

a [ ms−1 ] speed of soundax,k [ g ] kinematic acceleration along XB-axisay,k [ g ] kinematic acceleration along YB-axisaz,k [ g ] kinematic acceleration along ZB-axisAx [ g ] output of accelerometer (specific force) in c.g. along XB-axisAy [ g ] output of accelerometer (specific force) in c.g. along YB-axisAz [ g ] output of accelerometer (specific force) in c.g. along ZB-axisb [ m ] wing-spanc [ m ] mean aerodynamic chordCD [ rad ] course datum (selected VOR bearing)C1 [ – ] engine model parameterC2 [ – ] engine model parameterCl [ – ] non-dimensional moment about XB-axis (rolling moment)Cm [ – ] non-dimensional moment about YB-axis (pitching moment)Cn [ – ] non-dimensional moment about ZB-axis (yawing moment)CX [ – ] non-dimensional force along XB-axisCY [ – ] non-dimensional force along YB-axis

286 Appendix A. Symbols and definitions

CZ [ – ] non-dimensional force along ZB-axisD [ N ] total aerodynamic dragdgs [ m ] distance from aircraft to nominal glideslope linedloc [ m ] distance from aircraft to extended runway centerlinedpt [ – ] ∆pt

12 ρV2 = non-dimensional pressure increase across propeller

FB body-fixed reference frame, see section A.7.1FE Earth-fixed reference frame, see section A.7.1FM measurement reference frame, see section A.7.1FR special body-fixed reference frame for the Beaver, see section A.7.1FS stability reference frame, see section A.7.3FV vehicle-carried vertical reference frame, see section A.7.1FW flight-path reference frame, see section A.7.1Fx [ N ] total external force along XB-axis, see figure 2.1Fy [ N ] total external force along YB-axis, see figure 2.1Fz [ N ] total external force along ZB-axis, see figure 2.1fpa [ g ] flight-path accelerationg [ ms−2 ] acceleration of gravityh [ m ] pressure altitudeh [ s ] step-size for numerical integrationH [ m ] geopotential altitudeH f [ m ] height above aerodrome levelHRW [ m ] runway elevation above sea leveli [ – ] counter or iteration numberigs [ µA ] glideslope current (ILS)Ii [ kg m2 ] inertia coefficient (i = 1, 2, . . . , 6, see table 2.2)iloc [ µA ] localizer current (ILS)Ix [ kg m2 ] moment of inertia along XB-axisIy [ kg m2 ] moment of inertia along YB-axisIz [ kg m2 ] moment of inertia along ZB-axisJxy [ kg m2 ] product of inertia in XBYB-planeJxz [ kg m2 ] product of inertia in XBZB-planeJyz [ kg m2 ] product of inertia in YBZB-planek [ – ] time-step for discrete systems, t ≡ ktsK... gain factors for autopilot model, see table 14.3L [ Nm ] total rolling moment, see figure 2.1L [ N ] total aerodynamic liftLg [ m ] general scale length for atmospheric turbulenceLu [ m ] scale length for turbulence velocity along XB-axisLv [ m ] scale length for turbulence velocity along YB-axisLw [ m ] scale length for turbulence velocity along ZB-axism [ kg ] mass of the aircraftM [ – ] Mach numberM [ Nm ] total pitching moment, see figure 2.1Ma [ kg kmol−1 ] molecular weight of the airM0 [ kg kmol−1 ] molecular weight of the air at sea leveln [ RPM ] engine speedN [ Nm ] total yawing moment, see figure 2.1p [ rad s−1 ] angular rate of roll, see figure 2.1P [ Nm s−1 ] engine power

A.1. List of symbols 287

Pl , Pm,Pn, Ppp,Ppq, Ppr,Pqq, Pqr,Prr

inertia coefficients for p-equation, see table 2.2

ps [ Nm−2 ] ambient or free-stream pressurepz [ ′′Hg ] manifold pressureq [ rad s−1 ] angular rate of pitch, see figure 2.1qc [ Nm−2 ] impact pressureqdyn [ Nm−2 ] dynamic pressure

Ql , Qm,Qn, Qpp,Qpq, Qpr,Qqq, Qqr,Qrr

inertia coefficients for q-equation, see table 2.2

r [ rad s−1 ] angular rate or yaw, see figure 2.1R [ JK−1kg−1 ] Ra/M0, specific gas constant of airRa [ JK−1kmol−1 ] universal gas constantRc [ − ] Reynolds number with respect to cRe [ m−1 ] Reynolds number per unit lengthRgs [ m ] ground distance from aircraft to glideslope transmitter (ILS)Rloc [ m ] ground distance from aircraft to localizer transmitter (ILS)

Rl , Rm,Rn, Rpp,Rpq, Rpr,Rqq, Rqr,Rrr

inertia coefficients for r-equation, see table 2.2

S [ m2 ] wing areaSgs [ µA rad−1 ] sensitivity of the glideslope system (ILS)Sloc [ µA rad−1 ] sensitivity of the localizer system (ILS)t [ s ] timets [ s ] sampling time (step-width for discrete systems)T [ K ] ambient or free-stream temperatureTt [ K ] total temperatureu [ ms−1 ] velocity component along XB-axisug [ ms−1 ] component of the turbulence velocity along XB-axisuw [ ms−1 ] wind velocity component along XB-axisuwe [ ms−1 ] wind velocity component along XE-axisv [ ms−1 ] velocity component along YB-axisvg [ ms−1 ] component of the turbulence velocity along YB-axisvw [ ms−1 ] wind velocity component along YB-axisvwe [ ms−1 ] wind velocity component along XE-axisV [ ms−1 ] true airspeed, see figure 2.1Vc [ ms−1 ] calibrated airspeedVe [ ms−1 ] equivalent airspeedVw [ ms−1 ] wind velocityVw9.15 [ ms−1 ] wind velocity at 9.15 m altitude (reference velocity)V∆δa [ V ] command signal to actuators (change in deflection of the ailerons)V∆δe [ V ] command signal to actuators (change in elevator deflection)V∆δr [ V ] command signal to actuators (change in rudder deflection)w [ ms−1 ] velocity component along ZB-axisw1, w2, w3 [ − ] independent white noise signals


wg [ ms−1 ] component of the turbulence velocity along ZB-axisww [ ms−1 ] wind velocity component along ZB-axiswwe [ ms−1 ] wind velocity component along XE-axisW [ N ] aircraft weightXa [ N ] aerodynamic force along XB-axisxe [ m ] X-coordinate in Earth-fixed reference frame FEx f [ m ] X-coordinate in runway-fixed reference frame FFXgr [ N ] gravity force along XB-axisXp [ N ] propulsive force along XB-axisYa [ N ] aerodynamic force along YB-axisye [ m ] Y-coordinate in Earth-fixed reference frame FEy f [ m ] Y-coordinate in runway-fixed reference frame FFYgr [ N ] gravity force along YB-axisYp [ N ] propulsive force along YB-axisZa [ N ] aerodynamic force along ZB-axisze [ m ] Z-coordinate in Earth-fixed reference frame FEz f [ m ] Z-coordinate in runway-fixed reference frame FFZgr [ N ] gravity force along ZB-axisZp [ N ] propulsive force along ZB-axisα [ rad ] angle of attack, see figure 2.1β [ rad ] sideslip angle, see figure 2.1γ [ rad ] flight-path angleγ [ – ] ratio of specific heats of airγgs [ rad ] nominal glide-path angle on final approach (ILS glide-path)Γgs [ rad ] angle between localizer reference plane and the line through the ground

position of the aircraft and the glideslope antennaΓloc [ rad ] angle between localizer reference plane and the line through the ground

position of the aircraft and the localizer antennaΓVOR [ rad ] angle between selected and actual VOR radialδa [ rad ] deflection of ailerons (δa = δaright − δaleft), see figure A.5δe [ rad ] deflection of elevatorδ f [ rad ] deflection of flapsδr [ rad ] deflection of rudder∆ increment∆pt [ Nm−2 ] increase of total pressure over the propeller∆δa [ rad ] change in deflection of the ailerons∆δe [ rad ] change in elevator deflection∆δr [ rad ] change in rudder deflectionεgs [ rad ] glideslope error angle above/below the nominal ILS glide-pathθ [ rad ] pitch angleλ [ Km−1 ] temperature gradient (∂T/∂h)µ [ rad ] aerodynamic angle of rollµ [ kg m−1s−1 ] dynamic viscosityρ [ kg m−3 ] air densityσ standard deviationσgs [ µA ] standard deviation of glideslope noiseσloc [ µA ] standard deviation of localizer noiseσu [ ms−1 ] standard deviation of turbulence velocity in XB-directionσv [ ms−1 ] standard deviation of turbulence velocity in YB-directionσw [ ms−1 ] standard deviation of turbulence velocity in ZB-directionϕ [ rad ] roll angleΦ [ rad ] bank angle

A.2. Vectors 289

χ [ rad ] azimuth angleψ [ rad ] yaw angleψw [ rad ] wind direction (wind from the North: ψw = π)ψRW [ rad ] runway headingω [ rad s−1 ] angular frequencyω0 [ rad s−1 ] natural frequency of undamped systemωn [ rad s−1 ] natural frequency of damped systemΩ [ rad m−1 ] spatial frequency

A.2 Vectors

a body-axes acceleration vectorCaero vector with non-dimensional aerodynamic force and moment coefficientsCprop vector with non-dimensional engine force and moment coefficients (‘propulsive’)F resulting force vector acting on rigid body; F = [Fx Fy Fz]T

h resulting angular momentum of rigid body about c.g.; h = [hx hy hz]T

M resulting moment vector about c.g. of rigid body; M = [L M N]Tr position vectoru... input vectorsV true airspeed vectorVw wind velocity vectorx state vectory... output vectorsΩ rotational velocity vector

A.3 Matrices

A system matrix of linear state-space systemB input matrix of linear state-space systemC output matrix of linear state-space system due to xD output matrix of linear state-space system due to uTP→Q transformation matrix from a reference frame FP to a reference frame FQΘ transformation matrix for first Euler rotation from FE to FBΦ transformation matrix for second Euler rotation from FE to FBΨ transformation matrix for second Euler rotation from FE to FB

A.4 Functions

f(t) general vector-equation for the time-derivatives of the state variablesg(t) general vector-equation for the output variablesH(ω) frequency response of forming filterS(ω) power spectral density functionS(Ω) power spectral density function

A.5 Indices and subscripts

0 nominal value0 value at sea levela ailerons


a relative to the surrounding atmosphere (used for velocity components)aero aerodynamic forces and moments or force and moment coefficientsc.g. center of gravitydpt stability derivative with respect to non-dimensional pressure increase across propellere elevatore relative to Earth axes (used for velocity components)f flapsf referenced to runway-fixed reference frame FRW , f stands for ‘field’grav gravity force componentsgs related to glideslope deviationk ‘kinematic’ (used for accelerations)loc related to localizer deviationp stability derivative with respect to non-dimensional rolling speedq stability derivative with respect to non-dimensional pitching speedr stability derivative with respect to non-dimensional yawing speedr rudderRW runway, used for defining runway parametersprop engine forces and moments or force and moment coefficients (‘propulsive’)VOR related to VOR signalsw wind velocity and wind velocity components along body axeswind force components due to non-steady atmospherewe wind velocity components along Earth axesα stability derivative with respect to angle of attackα2 stability derivative with respect to α2

α3 stability derivative with respect to α3

αδ f stability derivative with respect to αδ fα dpt2 stability derivative with respect to α dpt2

α2dpt stability derivative with respect to α2dptβ stability derivative with respect to sideslip angleβ2 stability derivative with respect to β2

β3 stability derivative with respect to β3

β stability derivative with respect to non-dimensional sideslip rateδa stability derivative with respect to deflection of aileronsδaα stability derivative with respect to δaαδe stability derivative with respect to deflection of elevatorδeβ2 stability derivative with respect to δeβ2

δ f stability derivative with respect to deflection of flapsδr stability derivative with respect to deflection of rudderδrα stability derivative with respect to δrα

A.6 Abbreviations

AFCS Automatic Flight Control SystemALH Altitude Hold mode of the autopilotALS Altitude Select mode of the autopilotCACSD Computer Aided Control System DesignCAS Calibrated AirspeedCD Course Datumc.g. center of gravityDHC De Havilland of Canada Ltd.DME Distance Measuring Equipment (radio-navigation)

A.7. Reference frames and sign conventions 291

DUT Delft University of TechnologyFCC Flight Control ComputerFCS Flight Control SystemFDC Flight Dynamics and ControlGA Go Around mode of autopilotGPS Global Positioning System (satellite navigation)GS Glideslope mode of autopilotHH Heading Hold / Heading Select mode of the autopilotIAS Indicated AirspeedILS Instrument Landing System (radio-navigation)IRS Inertial Reference SystemLOC Localizer mode of the autopilotMLS Microwave Landing System (radio-navigation)NAV VOR Navigation mode of the autopilotNDB Non-Directional Beacon (radio-navigation)PAH Pitch Attitude Hold mode of the autopilotODE Ordinary Differential EquationRAH Roll Attitude Hold mode of the autopilotSTOL Short Take-off and LandingTAS True AirspeedVOR Very high frequency Omnidirectional RangeVTOL Vertical Take-off and Landing

A.7 Reference frames and sign conventions

A.7.1 Definitions

Many different reference frames have been used throughout this report. The mostimportant onces have been listed below:

Body-fixed reference frame FB: This is a right-handed orthogonal reference systemwhich has its origin OB in the center of gravity of the aircraft. The XBOBZB planecoincides with the aircraft’s plane of symmetry if it is symmetrical, or it is locatedin a plane, approximating what would be the plane of symmetry if it is not [14].The XB-axis is directed toward the nose of the aircraft, the YB-axis points to theright wing (‘starboard’), and the ZB-axis points toward the bottom of the aircraft.

Stability reference frame FS: This is a special body-fixed reference frame, used inthe study of small deviations from a nominal flight condition. The referenceframes FB and FS differ in the orientation of their respective X-axes. The XS-axisis chosen parallel to the projection of the true airspeed vector V on the OBXBZB-plane (if the aircraft is symmetrical this is the plane of symmetry), or parallel toV itself in case of a symmetrical nominal flight condition. The YS-axis coincideswith the YB-axis.

Flight-path or wind reference frame FW : This reference frame, also called the windreference frame, has its origin in the center of gravity of the aircraft. The XW-axisis aligned with the velocity vector of the aircraft and the ZW-axis coincides withthe ZS-axis.

Earth-fixed reference frame FE: This reference frame, also called the topodetic refer-ence frame [14] is a right-handed orthogonal system which is considered to be


fixed in space. Its origin can be placed at an arbitrary position, but will be chosento coincide with the aircraft’s center of gravity at the start of a flight test manoeu-vre. The ZE-axis points downwards, parallel to the local direction of gravity. TheXE-axis is directed to the North, the YE-axis to the East.

Vehicle-carried vertical reference system FV : This reference system has its origin atthe center of gravity of the aircraft. The XV-axis is directed to the North, the YV-axis to the East, and the ZV-axis points downwards (along the local direction ofgravity). These reference axes are always parallel to the Earth-fixed reference axes,although the origin OV moves relatively to the Earth-fixed reference frame.

Measurement reference frame FM: This is a left-handed orthogonal reference framethat is used for correcting stability and control derivatives of the aircraft if posi-tion of the center of gravity differs from the one used during the flight tests. Forthe Beaver aircraft, the origin OM lies in a point, resulting from the perpendic-ular projection of the foremost point of the wing chord, parallel to the OBXBZB-plane [34]. The XMOMZM-plane coincides with the OBXBZB-plane. The positiveXM-axis points to the tail of the aircraft, the positive YM-axis points to the leftwing (‘port’), and the positive ZM-axis points upwards.

Special body-fixed reference frame for the Beaver, FR: This is a special referenceframe for the Beaver aircraft. It is identical to FB with one exception: its originOR is placed in a body-fixed reference point, which has been selected to coincidewith a c.g. position that was actually used during one flight. It has the followingcoordinates in FM: x = 0.5996 m, y = 0 m, z = −0.8815 m, see ref.[34]. FR is usedonly to define the moments and products of inertia for the aircraft condition onwhich the aerodynamic model was based; see table B.5 in appendix B.

Runway-fixed reference frame, FRW : This reference frame is used to define the geo-metry of the final approach to a runway. Its origin lies on the runway threshold,and it is aligned in the direction of the runway centerline. The XRW-axis coincideswith the runway centerline, pointing in the direction of landings and take-offs.ZRW is directed downwards and YRW is directed points to the right, as seen froman aircraft on final approach. See also figures 5.9 and 5.7 from chapter 5.

A.7.2 Summary of the application of the reference systems

The equations for translational and angular velocities, which were derived in chap-ter 2, have been referenced to the body axes FB. The wind reference frame FW is oftenused to express aerodynamic forces and moments (the stability reference frame FS isclosely related).

The position of the airplane has been defined with respect to the Earth-fixed refer-ence frame FE, while the definition of the aircraft attitude in terms of the Euler anglesψ, θ, and ϕ required the introduction of the vehicle-carried vertical reference frameFV . The runway-fixed reference frame is used for the definition of the final approachgeometry, i.e. the position of the airplane in relation to the landing runway.

Finally, two special body-fixed reference frames FM and FR are used to definethe reference flight condition for the Beaver model in table B.5 of appendix B; thesereference frames are not relevant for other purposes.


X (north)

Y (east)

Y (east)X (north)

Z (down)

Z (down)

E

V

V

E

V

E

g

c.g.

r

Figure A.1: Relationship between the vehicle-carried vertical reference frame FV and theEarth-fixed reference frame FE

A.7.3 Relationships between the reference frames

In figure A.1 the relationship between the Earth-fixed and vehicle-carried verticalreference systems is shown. As can be seen from this figure, FE and FV differ only inthe position of their respective origins.

The relationship between the vehicle-carried vertical and the body-axes has beenshown in figure A.2. The Euler angles ψ, θ, and ϕ define the orientation of FB with re-spect to FV , hence they define the attitude of the aircraft relatively to the surface of theEarth. Each of these Euler rotations can be expressed by a separate transformationmatrix:

TΨ =

cos ψ sin ψ 0− sin ψ cos ψ 0

0 0 1

(A.1)

TΘ =

cos θ 0 − sin θ0 1 0

sin θ 0 cos θ

(A.2)

TΦ =

1 0 00 cos ϕ sin ϕ0 − sin ϕ cos ϕ

(A.3)

The combined transformation from FV to FB then becomes:

TV→B = TΦ · TΘ · TΨ =

=

cos ψ cos θ sin ψ cos θ − sin θcos ψ sin θ sin ϕ− sin ψ cos ϕ sin ψ sin θ sin ϕ + cos ψ cos ϕ cos θ sin ϕcos ψ sin θ cos ϕ + sin ψ sin ϕ sin ψ sin θ cos ϕ− cos ψ sin ϕ cos θ cos ϕ

(A.4)


t -

?

Horizontal plane

ZV

XV

YV

ψ

ψX′

Y′

• A rotation by ψ about the ZV-axisto the intermediate position X′Y′ZV

t

ZV

XV

YV

ψ

ψ

1

-

?

Z′

X′

Y′

XB

θ

θ

• A rotation by θ about the Y′-axisto the intermediate position XBY′Z′

t

ZV

XV

YV

ψ

ψ

1

-

?

Z′

X′

Y′

XB

θ

θ

AAAAAAAAAAAAAU

ϕ

ϕ

YBZB

• A rotation by ϕ about the XB-axisto the final position XBYBZB

Figure A.2: Relationship between the vehicle-carried vertical reference frame FV and thebody-fixed reference frame FB


t

ZV

XV

YV

χ

χ

X′

Y′

• A rotation by χ about the ZV-axisto the intermediate position X′Y′ZV

?

-

Horizontal plane

t

ZV

XV

YV

χ

χ

X′

Y′

• A rotation by γ about the Y′-axisto the intermediate position XWY′Z′

:

-

?

γ

γ

Z′

XW

t

ZV

XV

YV

χ

χ

X′

Y′

• A rotation by µ about the XW-axisto the final position XWYWZW

:

-

?

γ

γ

Z′

XW

/

BBBBBBBBBBBBBBBN

µ

µ

ZW

YW

Figure A.3: Relationship between the vehicle-carried vertical reference frame FV and theflight-path reference frame FW


c.g.

αo

βo

αo

V

XB

XS

XW

BZ

S WZ = Z

Y = YB S

WYoβ

Figure A.4: Relationship between the body-fixed reference frame FB, flight-path referenceframe FW and stability reference frame FS

δ (+)r

δ (+)e

δaleft

( )δaright

(+)

δaleft

δarightδ

a =

Figure A.5: Sign conventions for control surface deflections


Thus, we find the following relation between a vector yB in the body reference frameand yV in the vehicle-carried vertical reference frame:

yB = TV→B · yV (A.5)

The orientation of the flight-path axes with respect to the vehicle-carried verticalaxes can also be expressed in terms of Euler angles, denoted by χ, γ, and µ. This isshown in figure A.3. The Euler angles ψ, θ, and φ define the orientation body axesFB in relation to the vehicle-carried vertical reference frame FV ; the angles χ, γ, andµ define the orientation of the flight-path axes FW in relation to FV .

Figure A.4 shows the relationships between the body, flight-path, and stabilityreference frames. These three reference systems all have their origin in the aircraft’scenter of gravity. The XW-axis is aligned with the velocity vector of the aircraft. Theorientation of the flight-path axes with respect to the body-fixed reference frame isdefined by the angle of attack α and the sideslip angle β. The stability referencesystem is displaced from the flight-path axes by a rotation β and from the body axesby a rotation −α.

For the orientation of the runway-fixed reference frame relatively to the Earth-fixed reference frame, refer to section 5.1.1. This section also shows how the aircraftcoordinates can be expressed in terms of the runway-axes.

A.7.4 Sign conventions for deflections of control surfaces

Figure A.5 shows the positive directions of control surface deflections. To summa-rize:

• The positive elevator deflection is measured downwards; a positive value of δeresults in a pitch-down moment for the aircraft.

• The deflections of the rudder and ailerons are positive if they force the aircraftto turn to the left. If one aileron deflection is positive, the deflection of theopposite aileron consequently will be negative. The ‘total’ aileron deflection isdefined as: δa = δa right − δa left .

• The flap angle is positive if the flaps deflect downwards (which they alwaysdo), similar to the elevator deflection. A positive value of δ f results in an in-crease in lift and drag of the aircraft.

Please be aware that other literature may use different definitions, especially forthe aileron deflection (some resources use the mean deflection of the left and rightailerons, rather than the total deflection).

Appendix B

Beaver model parameters

This appendix provides the values of several Beaver model parameters, as well assome general data for this aircraft. A description of the mathematical model itselfcan be found in chapter 3. Appendix C will explain the format that was used toimplement these parameters in the MATLAB/SIMULINK environment.

B.1 General aircraft data

From the late 1950’s until the end of 1993, the Faculty of Aerospace Engineeringof Delft University of Technology has operated a De Havilland DHC-2 Beaver air-craft, specially equipped as ‘flying laboratory’ for flight research experiments. TheBeaver is a high-winged, seven-seat, all metal aircraft. It is powered by a singlePratt & Whitney radial piston engine of 450 horsepower, which drives a two-bladedconstant-speed propeller. A picture of the aircraft has been shown in figure B.1; somebasic technical data has been presented in table B.1.

The aircraft has a fixed undercarriage. Under normal circumstances, the flapset-tings ‘up’ (0), ‘climb’ (15), and ‘take-off’ (35) are used in flight. Other possibleflapsettings are ‘landing’ (50) and ‘full’ (58), but those are rarely applied in prac-tice, due to the short take-off and landing (STOL) flight characteristics of the Beaver.The flight model data from ref.[34] were based on measurements in actual flights,which were made during the 1977-1978 period. Table B.2 lists some typical flightconditions for the Beaver.

B.2 Flight envelope

Figure B.2 shows the flight envelope of the Beaver, including the manoeuvre pointsthat were used for the flight-test measurements from ref.[34]. The flight envelopewas obtained from ref.[6]. Notice that the reported maximum altitude of 10000 feetis not in agreement with the value from table B.1, which was obtained from ref.[29];most likely the 10000 feet ceiling is an operational restriction caused by the lack ofa built-in oxygen supply system that would be necessary for prolonged operationabove 10000 feet. In addition, the reported ‘never-exceed speed’ Vne according tofigure B.2 is higher than the maximum speed from table B.1; the latter value probablyrepresenting the maximum operational speed Vmo.

300 Appendix B. Beaver model parameters

B.3 Aerodynamic and engine model parameters

Section 3.3 presented models of the nonlinear aerodynamic and propulsive forces forthe Beaver, see equations (3.3) and (3.7). These models are valid over a wide rangeof flight conditions, roughly covered by the flight envelope boundaries of figure B.2.The corresponding model parameters have been listed in tables B.3 and B.4, respec-tively. See ref.[34] for more details on how these parameters were obtained.

Manufacturer De Havilland Aircraft of Canada Ltd.Serial no. 1244Type of aircraft Single engine, high-wing, seven seat, all-metal aircraftWing span b 14.63 mWing area S 23.23 m2

Mean aerodynamic chord c 1.5875 mWing sweep 0

Wing dihedral 1

Wing profile NACA 64 A 416Fuselage length 9.22 mHeight 2.74 mMax. take-off weight 22800 NEmpty weight 14970 NEngine Pratt and Whitney Wasp Jr. R-985Max. power 450 Hp at n = 2300 RPM, pz = 26"HgPropeller Hamilton Standard, two-bladed metal regulator propellerDiameter of the propeller 2.59 mTotal contents of fuel tanks 521 lContents fuselage front tank 131 lContents fuselage center tank 131 lContents fuselage rear tank 95 lContents wing tanks 2 x 82 lMost forward admissible c.g. position 17.36% c at 16989 N; 29.92% c at 22800 NMost backward admissible c.g. position 40.24% cMaximum speed 71.4 m/sec ?

Cruising speed 58 m/sec ?

Initial climb gradient 1020 f t/NM = 17% ?

Ceiling 5486 m

Table B.1: General aircraft data of the DHC-2 Beaver, PH-VTH. These data were obtainedfrom refs.[34] and [29]; the latter figures have been marked by a star symbol: ?.

Figure B.1: The De Havilland DHC-2 Beaver aircraft

B.3. Aerodynamic and engine model parameters 301

10 20 30 40 50 60 70 80 900

2000

4000

6000

8000

10000

12000

V [ m/s ] H [ ft ] 5510

3506 4506 5506

3004

3502 4502 5502 6002

flight envelope manoeuvre point V = V = s ne 26.75 80.25

Figure B.2: The flight envelope of the De Havilland DHC-2 Beaver aircraft

Flight condition δ f [deg] n [RPM] pz ["Hg] V [kts] H [ft/min]

Take-off 35 2350 36.5 70 800/900Climb 15/0 2000 30.0 70 700/800Cruise 0 1800 28.0 100 0 (level flight)Descend 0 1800 15.0 120 -1000Approach 15 2000 15.0 80 -400/-500

Table B.2: Typical flight conditions for the Beaver (the given values are an average of nor-mally applied flap deflections, engine settings, and airspeeds); see ref. [34].

302 Appendix B. Beaver model parameters

CX CY CZ

parameter value parameter value parameter value

0 −0.03554 0 −0.002226 0 −0.05504

α 0.002920 β −0.7678 α −5.578

α2 5.459 pb2V −0.1240 α3 3.442

α3 −5.162 rb2V 0.3666 qc

V −2.988qcV −0.6748 δa −0.02956 δe −0.3980

δr 0.03412 δr 0.1158 δeβ2 −15.93

δ f −0.09447 δrα 0.5238 δ f −1.377

αδ f 1.106 βb2V −0.1600 αδ f −1.261

Cl Cm Cn


0 0.0005910 0 0.09448 0 −0.003117

β −0.06180 α −0.6028 β 0.006719pb2V −0.5045 α2 −2.140 pb

2V −0.1585rb2V 0.1695 qc

V −15.56 rb2V −0.1112

δa −0.09917 δe −1.921 δa −0.003872

δr 0.006934 β2 0.6921 δr −0.08265

δaα −0.08269 rb2V −0.3118 qc

V 0.1595

δ f 0.4072 β3 0.1373

Table B.3: Coefficients in the aerodynamic model of the Beaver, valid within the 35-55 ms−1

TAS range

CX CY CZ


dpt 0.1161 − − dpt −0.1563

α · dpt2 0.1453

Cl Cm Cn


α2 · dpt −0.01406 dpt −0.07895 dpt3 −0.003026

dpt ≡ ∆pt12 ρV2

= C1 + C2P

12 ρV3

with:

C1 = 0.08696

C2 = 191.18

Table B.4: Coefficients in the engine forces & moments model of the Beaver, valid within the35-55 ms−1 TAS range

B.3. Aerodynamic and engine model parameters 303

xc.g. = 0.5996 [m] in FM

yc.g. = 0.0 [m] in FMzc.g. = -0.8851 [m] in FMIxx = 5368.39 [kg m2] in FRIyy = 6928.93 [kg m2] in FRIzz = 11158.75 [kg m2] in FRJxy = 0.0 [kg m2] in FRJxz = 117.64 [kg m2] in FRJyz = 0.0 [kg m2] in FRm = 2288.231 [kg]h = 1828.8 [m] (= 6000 [ft])ρ = 1.024 [kg m−3]

Table B.5: Aircraft data on which the aerodynamic model of the Beaver is based (FM is the‘measurement reference frame’, which has been defined in section A.7.1)

Appendix C

Data structure of the FDC modelparameters

This appendix explains the data-format that was used to implement the parametersof the Beaver dynamics model in MATLAB/SIMULINK. The numerical values of theseparameters has been presented in appendix B; a detailed description of the SIMU-LINK model itself can be found in chapter 8.

C.1 Defining the model parameters in the MATLAB workspace

The aircraft model from the FDC toolbox reads its model data from the MATLAB

workspace. The exact structure of this data is highly dependent of the aircraft underconsideration; for the Beaver, most parameters have been stored in three parametermatrices and one parameter vector. The parameters must be present in the MAT-LAB workspace before running a simulation of the airplane model, or applying ananalytical SIMULINK or FDC function to this model.

This data-structure may not be suited for the implementation of different aircraftmodels within the FDC structure. Although any suitable data-structure can be used,it is recommended not to change the definitions of the vector GM1 and matrix GM2,which contain mass-distribution data and information about the airplane’s geome-try, except for enhancing the model for non-constant mass and/or mass-distribution.This is due to the fact that these two matrices are used by aircraft-independent subsys-tems as well, contrary to the aerodynamic and propulsion parameter matrices AMand EM, which are used by aircraft-dependent blocks only.

The parameters can be loaded from the file AIRCRAFT.DAT, which can normallybe found in the DATA subdirectory, using the utility DATLOAD (see section 12.4.2). Ifthis datafile has somehow inadvertently been deleted, it can be re-created by runningthe program MODBUILD (see section 12.6.1). The definitions of the parameter vectorand matrices for the Beaver model will be given below; the numerical values of theparameters have been listed in appendix B, along with some general informationabout the Beaver aircraft.

To change the values of the parameters, e.g. in order to implement a model of adifferent aircraft, the easier method is to create a customized copy of MODBUILD.M.Since this MATLAB macro has been heavily documented, it shouldn’t be too diffi-

306 Appendix C. Data structure of the FDC model parameters

cult to identify the aircraft-dependent parameters that need to be changed, and thegeneric aircraft-independent code that determines the inertia coefficients from ta-ble 2.2 of chapter 2. It is recommended to save the altered parameters to a newdatafile, such as AIRCRAFT1.DAT, BOEING747.DAT, or something similar. See sec-tion 12.6.1 for more details about MODBUILD.

C.2 Definition of the parameter matrices for the Beaver model

Aerodynamic model

The stability and control derivatives used by the aerodynamic model of the Beaveraircraft have been combined in the parameter matrix AM. The definition of AM hasbeen given in table C.2, while the numerical values of these coefficients can be foundin table B.3 from appendix B. The numerical values have been implemented in MOD-BUILD, which generates the datafile AIRCRAFT.DAT. See section 3.3.1 for more detailsabout the aerodynamic model itself.

Engine forces & moments model

The coefficients used by the propulsion model of the Beaver aircraft have been com-bined in the parameter matrix EM. The definition of EM has been given in table C.2,while the numerical values of these coefficients can be found in table B.4 from appen-dix B. The numerical values have been implemented in MODBUILD. See section 3.3.2for more details about the propulsion model itself.

Weight & balance and geometrical data

In the current implementation of the aircraft model, the mass of the airplane and itsmass-distribution are assumed to remain constant during the relatively short time-intervals considered in most simulations. These values have therefore been imple-mented as system parameters for the nonlinear aircraft model.

The parameter vector GM1 contains the mass, moments and products of inertia,mean aerodynamic chord, wing span, and wing area. The definition of GM1 has beengiven in table C.3, while the numerical values of these parameters can be found intables B.1 and B.5 from appendix B. These numerical values have been implementedin MODBUILD.

The parameter matrix GM2 contains the inertia coefficients from table 2.2 in chap-ter 2, with numerical values that correspond to the moments and products of inertiafrom the vector GM1. The definition of GM2 has also been given in table C.3. Theequations from table 2.2 have been implemented in MODBUILD, to obtain the numer-ical values of these parameters.

C.2. Definition of the parameter matrices for the Beaver model 307

AM =

CX0 CY0 CZ0 Cl0 Cm0 Cn0

CXα 0 CZα 0 Cmα 0

CXα2 0 0 0 Cm

α2 0

CXα3 0 CZ

α3 0 0 0

0 CYβ0 Clβ

0 Cnβ

0 0 0 0 Cmβ2 0

0 0 0 0 0 Cnβ3

0 CYp 0 Clp 0 Cnp

CXq 0 CZq 0 Cmq Cnq

0 CYr 0 Clr Cmr Cnr

0 0 CZδe0 Cmδe

0

CXδ f0 CZδ f

0 Cmδ f0

0 CYδa0 Clδa

0 Cnδa

CXδrCYδr

0 Clδr0 Cnδr

CXαδ f0 CZαδ f

0 0 0

0 CYδrα0 0 0 0

0 0 0 Clδaα0 0

0 0 CZδe β2 0 0 0

0 CYβ0 0 0 0

T1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

1 2 3 4 5 6

Table C.1: Coefficients of the aerodynamic model of the Beaver

EM =

CXdpt 0 CZdpt 0 Cmdpt 0

0 0 0 0 0 Cndpt

CXαdpt2 0 0 0 0 0

0 0 0 Clα2dpt

0 0

T1

2

3

4

1 2 3 4 5 6

Table C.2: Coefficients of the engine forces & moments model of the Beaver

308 Appendix C. Data structure of the FDC model parameters

GM1 =[

c b S Ixx Iyy Izz Jxy Jxz Jyz m]T

1

1 2 3 4 5 6 7 8 9 10

GM2 =

Pl Pm Pn Ppp Ppq Ppr Pqq Pqr Prr

Ql Qm Qn Qpp Qpq Qpr Qqq Qqr Qrr

Rl Rm Rn Rpp Rpq Rpr Rqq Rqr Rrr

T

1

2

3

1 2 3 4 5 6 7 8 9

Table C.3: Beaver geometry and mass-distribution

Appendix D

Data structure of the FDC modeloutput signals

During simulations, several signals from the simulation models are logged in theMATLAB workspace; these results can later be used for post-simulation analysis,such as trajectory plotting, or they can be saved to file. In this appendix, the data-format for this output logging will be described, and an overview of the input andoutput signals used in the top-level of the aircraft model will be provided. See chap-ter 8 (in particular, the description of the Beaver Level 1 system) for more informationabout the aircraft model input/output structure; see chapter 10 for more informationabout the radio-navigation models.

D.1 Aircraft model signal logging

During simulations that involve the nonlinear aircraft model Beaver (or one of itssubsystem equivalents; see chapter 8 for more information), all input and outputsignals are logged in the workspace variables In and Out, respectively. In addition, amatching time-axis is logged in the variable time. The reason for including the inputsignals is that these do not necessarily have to be pre-determined by the user; theymay also be generated by external systems, such as an autopilot controller.

The workspace variables In and Out are matrices. The number of rows is equal tothe length of the vector time, which corresponds with the total number of logged datapoints. Each column represents a time-trajectory of an individual input or outputsignal. In total, there are twelve logged input signals, and 89 logged output signals,which have been ordered in the sequence shown in tables D.3 and D.2.

After performing a simulation, it is possible to plot an individual input or out-put trajectory, using the command: plot(time,In(:,i )), or plot(time,Out(:,i )),where i represents the column number of the required signal. Notice that the utilityRESULTS can convert these matrices into human-legible variables for all individualinput and output trajectories, while the macro RESPLOT can be used to providea quick graphical overview of the time-trajectories stored in In and Out. See sec-tions 12.6.3 and 12.6.4 for more information.

The logged signals from the aircraft model correspond to the inputs and outputsof the subsystem Beaver Level 2, the main level of the aircraft model. The inputs

310 Appendix D. Data structure of the FDC model output signals

are also equal to those of the top-level of the aircraft model (Beaver Level 1), butthe outputs from the top-level only comprise a small subset of the 89 output signalslogged in Out. This has been explained in more detail in the descriptions of BeaverLevel 1 and Beaver Level 2 in the reference chapter 8. Table D.1 shows the definitionof the resulting output vector from the aircraft model. This vector provides the neces-sary connection between the aircraft model and external systems; the current choiceof signals provides enough information for the Beaver autopilot simulations fromchapter 15.

The information from tables D.3, D.2, and D.1 can also be displayed in your web-browser or the MATLAB help browser (depending on your MATLAB-setup) by typingbrowse inputs or browse outputs on the command-line. More information aboutthe utilities RESULTS and RESPLOT is available in the command-window by typ-ing help results/help resplot, or in the webbrowser or MATLAB help browserby typing browse results/browse resplot.

D.2 Radio navigation signal logging

During simulations involving the ILS example system ILS example, all importantresults are stored in the workspace variable yils. Simulations involving the VORexample system VOR example will store output information in yvor.

These variables are again matrices, which have a similar structure as the matricesIn and Out from the aircraft model. The ILS and VOR example systems do not createa separate time-axis, as this task is normally already done by the aircraft model (ifILS example and/or VOR example are used in combination with a model that doesnot take care of this task, it is necessary to include the required time signal yourself,e.g. by incorporating an additional Clock block, connected to a To Workspace block.

Tables D.4 and D.5 show the definitions of the matrices yils and yvor; the corre-sponding column-numbers are displayed underneath the symbols. See the descrip-tion of the systems ILS example and VOR example in chapter 10 for more information.

Inputs: δe δa δr δ f n pz uw vw ww uw vw ww1 2 3 4 5 6 7 8 9 10 11 12

Outputs: V α β p q r ψ θ ϕ xe ye H1 2 3 4 5 6 7 8 9 10 11 12

H pb2V

qcV

rb2V

13 14 15 16

Table D.1: Definition of the input and output signals of the aircraft model (see the descrip-tion of ‘Beaver Level 1’ in chapter 8 for more information)

D.2. Radio navigation signal logging 311

Sub- Output signals from the aircraft model, logged in the matrix Outvector

x V α β p q r ψ θ ϕ xe ye H1 2 3 4 5 6 7 8 9 10 11 12

x V α β p q r ψ θ ϕ xe ye H13 14 15 16 17 18 19 20 21 22 23 24

ybvel u v w25 26 27

yuvw u v w28 29 30

ydlpb2V

qcV

rb2V

31 32 33

yfp γ fpa χ Φ34 35 36 37

ypow dpt P38 39

yacc Ax Ay Az ax,k ay,k az,k40 41 42 43 44 45

Caero CXa CYa CZa Cla Cma Cna46 47 48 49 50 51

Cprop CXp CYp CZp Clp Cmp Cnp52 53 54 55 56 57

FMaero Xa Ya Za La Ma Na58 59 60 61 62 63

FMprop Xp Yp Zp Lp Mp Np64 65 66 67 68 69

Fgrav Xgr Ygr Zgr70 71 72

Fwind Xw Yw Zw73 74 75

yatm ρ ps T µ g76 77 78 79 80

yad1 a M qdyn81 82 83

yad2 qc Ve Vc84 85 86

yad3 Tt Re Rc87 88 89

Table D.2: Logged output signals from the aircraft model. The time-trajectories of these 89output signals are stored in the 89 corresponding columns of the matrix Out.

312 Appendix D. Data structure of the FDC model output signals

Sub- Input signals from the aircraftvector model, logged in the matrix In

uaero δe δa δr δ f1 2 3 4

uprop n pz5 6

uwind uw vw ww uw vw ww7 8 9 10 11 12

Table D.3: Logged input signals for the aircraft model. The time-trajectories of these twelveinput signals are stored in the twelve corresponding columns of the matrix In.

Sub- Output signals from the system ILS example,vector logged in the matrix yils

yils1 igs iloc1 2

yils2 εgs Γloc3 4

yils3 x f y f H f dgs Rgs Rloc5 6 7 8 9 10

yils4 LOC_flag GS_flag11 12

Table D.4: Logged output signals from the ILS example model. The time-trajectories of theseoutput signals are stored in the corresponding columns of the matrix yils.

Sub- Output signals from the system VOR example,vector logged in the matrix yvor

yVOR1 ΓVOR1

yVOR2 RVOR2

yVOR3 Cone of silence flag Range flag3 4

yVOR4 To/From flag5

Table D.5: Logged output signals from the VOR example model. The time-trajectories ofthese output signals are stored in the corresponding columns of the matrix yvor.

Appendix F

The Open Software License v. 2.1

This Open Software License (the “License”) applies to any original work of author-ship (the “Original Work”) whose owner (the “Licensor”) has placed the followingnotice immediately following the copyright notice for the Original Work:

Licensed under the Open Software License version 2.1

1. Grant of Copyright License. Licensor hereby grants You a world-wide, royalty-free, non-exclusive, perpetual, sublicenseable license to do the following:

• to reproduce the Original Work in copies;• to prepare derivative works (“Derivative Works”) based upon the Origi-

nal Work;• to distribute copies of the Original Work and Derivative Works to the pub-

lic, with the proviso that copies of Original Work or Derivative Works thatYou distribute shall be licensed under the Open Software License;

• to perform the Original Work publicly; and• to display the Original Work publicly.

2. Grant of Patent License. Licensor hereby grants You a world-wide, royalty- free,non-exclusive, perpetual, sublicenseable license, under patent claims owned orcontrolled by the Licensor that are embodied in the Original Work as furnishedby the Licensor, to make, use, sell and offer for sale the Original Work andDerivative Works.

3. Grant of Source Code License. The term “Source Code” means the preferredform of the Original Work for making modifications to it and all availabledocumentation describing how to modify the Original Work. Licensor herebyagrees to provide a machine-readable copy of the Source Code of the Origi-nal Work along with each copy of the Original Work that Licensor distributes.Licensor reserves the right to satisfy this obligation by placing a machine- read-able copy of the Source Code in an information repository reasonably calcu-lated to permit inexpensive and convenient access by You for as long as Licen-sor continues to distribute the Original Work, and by publishing the addressof that information repository in a notice immediately following the copyrightnotice that applies to the Original Work.

322 Appendix F. The Open Software License v. 2.1

4. Exclusions From License Grant. Neither the names of Licensor, nor the names ofany contributors to the Original Work, nor any of their trademarks or servicemarks, may be used to endorse or promote products derived from this OriginalWork without express prior written permission of the Licensor. Nothing in thisLicense shall be deemed to grant any rights to trademarks, copyrights, patents,trade secrets or any other intellectual property of Licensor except as expresslystated herein. No patent license is granted to make, use, sell or offer to sellembodiments of any patent claims other than the licensed claims defined inSection 2. No right is granted to the trademarks of Licensor even if such marksare included in the Original Work. Nothing in this License shall be interpretedto prohibit Licensor from licensing under different terms from this License anyOriginal Work that Licensor otherwise would have a right to license.

5. External Deployment. The term “External Deployment” means the use or distri-bution of the Original Work or Derivative Works in any way such that the Orig-inal Work or Derivative Works may be used by anyone other than You, whe-ther the Original Work or Derivative Works are distributed to those persons ormade available as an application intended for use over a computer network.As an express condition for the grants of license hereunder, You agree that anyExternal Deployment by You of a Derivative Work shall be deemed a distribu-tion and shall be licensed to all under the terms of this License, as prescribedin section 1(c) herein.

6. Attribution Rights. You must retain, in the Source Code of any Derivative Worksthat You create, all copyright, patent or trademark notices from the SourceCode of the Original Work, as well as any notices of licensing and any de-scriptive text identified therein as an “Attribution Notice.” You must causethe Source Code for any Derivative Works that You create to carry a prominentAttribution Notice reasonably calculated to inform recipients that You havemodified the Original Work.

7. Warranty of Provenance and Disclaimer of Warranty. Licensor warrants thatthe copyright in and to the Original Work and the patent rights granted hereinby Licensor are owned by the Licensor or are sublicensed to You under theterms of this License with the permission of the contributor(s) of those copy-rights and patent rights. Except as expressly stated in the immediately pro-ceeding sentence, the Original Work is provided under this License on an “ASIS” BASIS and WITHOUT WARRANTY, either express or implied, including,without limitation, the warranties of NON-INFRINGEMENT, MERCHANTA-BILITY or FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK ASTO THE QUALITY OF THE ORIGINAL WORK IS WITH YOU. This DISCLAI-MER OF WARRANTY constitutes an essential part of this License. No licenseto Original Work is granted hereunder except under this disclaimer.

8. Limitation of Liability. Under no circumstances and under no legal theory, whe-ther in tort (including negligence), contract, or otherwise, shall the Licensor beliable to any person for any direct, indirect, special, incidental, or consequen-tial damages of any character arising as a result of this License or the use ofthe Original Work including, without limitation, damages for loss of goodwill,work stoppage, computer failure or malfunction, or any and all other commer-

323

cial damages or losses. This limitation of liability shall not apply to liabilityfor death or personal injury resulting from Licensor’s negligence to the extentapplicable law prohibits such limitation. Some jurisdictions do not allow the ex-clusion or limitation of incidental or consequential damages, so this exclusionand limitation may not apply to You.

9. Acceptance and Termination. If You distribute copies of the Original Work or aDerivative Work, You must make a reasonable effort under the circumstancesto obtain the express assent of recipients to the terms of this License. Noth-ing else but this License (or another written agreement between Licensor andYou) grants You permission to create Derivative Works based upon the Origi-nal Work or to exercise any of the rights granted in Section 1 herein, and anyattempt to do so except under the terms of this License (or another writtenagreement between Licensor and You) is expressly prohibited by U.S. copy-right law, the equivalent laws of other countries, and by international treaty.Therefore, by exercising any of the rights granted to You in Section 1 herein,You indicate Your acceptance of this License and all of its terms and conditions.This License shall terminate immediately and you may no longer exercise anyof the rights granted to You by this License upon Your failure to honor theproviso in Section 1(c) herein.

10. Termination for Patent Action. This License shall terminate automatically andYou may no longer exercise any of the rights granted to You by this License asof the date You commence an action, including a cross-claim or counterclaim,against Licensor or any licensee alleging that the Original Work infringes apatent. This termination provision shall not apply for an action alleging patentinfringement by combinations of the Original Work with other software orhardware.

11. Jurisdiction, Venue and Governing Law. Any action or suit relating to this Li-cense may be brought only in the courts of a jurisdiction wherein the Licensorresides or in which Licensor conducts its primary business, and under the lawsof that jurisdiction excluding its conflict-of-law provisions. The applicationof the United Nations Convention on Contracts for the International Sale ofGoods is expressly excluded. Any use of the Original Work outside the scopeof this License or after its termination shall be subject to the requirements andpenalties of the U.S. Copyright Act, 17 U.S.C. §101 et seq., the equivalent lawsof other countries, and international treaty. This section shall survive the termi-nation of this License.

12. Attorneys Fees. In any action to enforce the terms of this License or seekingdamages relating thereto, the prevailing party shall be entitled to recover itscosts and expenses, including, without limitation, reasonable attorneys’ feesand costs incurred in connection with such action, including any appeal ofsuch action. This section shall survive the termination of this License.

13. Miscellaneous. This License represents the complete agreement concerning thesubject matter hereof. If any provision of this License is held to be unenforce-able, such provision shall be reformed only to the extent necessary to make itenforceable.

324 Appendix F. The Open Software License v. 2.1

14. Definition of “You” in This License. “You” throughout this License, whetherin upper or lower case, means an individual or a legal entity exercising rightsunder, and complying with all of the terms of, this License. For legal entities,“You” includes any entity that controls, is controlled by, or is under commoncontrol with you. For purposes of this definition, “control” means (i) the power,direct or indirect, to cause the direction or management of such entity, whetherby contract or otherwise, or (ii) ownership of fifty percent (50%) or more of theoutstanding shares, or (iii) beneficial ownership of such entity.

15. Right to Use. You may use the Original Work in all ways not otherwise restric-ted or conditioned by this License or by law, and Licensor promises not tointerfere with or be responsible for such uses by You.

This license is Copyright ©2003-2004 Lawrence E. Rosen. All rights reserved. Permis-sion is hereby granted to copy and distribute this license without modification. Thislicense may not be modified without the express written permission of its copyrightowner.

Bibliography

[1] Anon. Approach and Landing Simulation. AGARD report 632, Ames, 1975.

[2] Anon. International Standards and Recommended Practices. Annex 10, VolumeI, Part I: Equipment and Systems and Attachment C to Part I, ICAO, Montreal,Canada, 1968.

[3] Anon. Using Matlab. The Mathworks, Natick, MA, USA, edition 1999 or later.

[4] Anon. Using Simulink. The Mathworks, Natick, MA, USA, edition 1999 or later.

[5] Abbink, F.J.: Vliegtuiginstrumentatie I/II. Lecture Notes D-34 (in Dutch), DelftUniversity of Technology, Faculty of Aerospace Engineering, Delft, 1984.

[6] Abidin, Z.: Adaptive Self-Tuning Flight Control Systems – The Multiple ModelApproach. PhD-thesis, Delft University of Technology, Faculty of Aerospace En-gineering, Delft, The Netherlands, 1998.

[7] Bauss, W. (ed.): Radio Navigation Systems for Aviation and Maritime Use.AGARDograph 63, Pergamon Press, UK, 1963.

[8] Bosch, P.P.J. van den, Klauw, A.C. van der: Modeling, Identification, and Simu-lation of Dynamical Systems. CRC Press, Florida, USA, 1994.

[9] Brandt, A.P., Broek, P.Ph. van der: Vliegeigenschappen 2. Lecture Notes D-34(in Dutch), Delft University of Technology, Faculty of Aerospace Engineering,Delft, 1984.

[10] Chen, Chi-Tsong: Linear system theory and design. Holt, Rinehart and WinstonInc., USA, 1984.

[11] Brockhaus, R.: Flugregelung (in German). Springer-Verlag, Berlin, 1993.

[12] Colgren, R.D.: A Workstation for the integrated design and simulation of flightcontrol systems. Lockheed Aeronautical Systems Company, Burbank, Califor-nia, USA, 1988.

[13] Cook, J.M., Zyda, M.J., Pratt, D.R., McGhee, R.B.: NPSNET: Flight Simula-tion Dynamic Modeling Using Quaternions. Naval Postgraduate School, De-partment of Computer Science, Monterey, California, USA, 1994. In: Presence,Volume 1, No. 4, pp. 404-420.

[14] Duke, E.L., Antoniewicz, R.F., Krambeer, K.D.: Derivation and Definition of aLinear Aircraft Model. NASA Reference Publication 1207, USA, 1988.

[15] Etkin, B., Reid, L.D.: Dynamics of Flight – Stability and Control. Wiley, NewYork, USA, 3nd edition, 1996.

330 BIBLIOGRAPHY

[16] Fogarty, L.E., Howe, R.M.: Computer mechanization of six degree-of-freedomflight equations. NASA Contractor Report 1344, USA, 1969.

[17] Forsythe, G.E., Malcolm, M.A., Moler, C.B.: Computer methods for Mathemati-cal Computations. Prentice Hall, Englewood Cliffs, New Jersey, USA, 1977.

[18] Gear, C.W.: Numerical Initial Value Problems in Ordinary Differential Equa-tions. Prentice Hall, Englewood Cliffs, New Jersey, USA, 1971.

[19] Gerlach, O.H.: Mathematical model of external disturbances acting on an air-craft during an ILS approach and landing. Report VTH-159, Delft University ofTechnology, Faculty of Aerospace Engineering, Delft, The Netherlands, 1970.

[20] Gerlach, O.H.: Lecture Notes on Aircraft Stability and Control. Lecture NotesD-26, Delft University of Technology, Faculty of Aerospace Engineering, Delft,The Netherlands, 1981.

[21] Hoogstraten, J.A., Moesdijk, B. van de: Modular programming structure ap-plied to the simulation of non-linear aircraft models. In: IMACS ConferenceProceedings on Simulation in Engineering Sciences, Nantes, France, 1983.

[22] Johnson, W.A., McRuer, D.T.: Development of a Category II Approach SystemModel. NASA Contractor Report 2022, Washington D.C., USA, 1972.

[23] Kendal, B.: Manual of Avionics. BSP Professional Books, UK, 2nd edition, 1987.

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

[25] McLean, D.: Automatic Flight Control Systems. Prentice Hall, Hertfordshire,UK, 1990.

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

[27] Mulder, J.A., Vaart, J.C. van der: Aircraft Responses to Atmospheric Turbulence.Lecture Notes D-47, Delft University of Technology, Faculty of Aerospace Engi-neering, Delft, The Netherlands, edition 1992.

[28] Rauw, M.O.: A SIMULINK environment for Flight Dynamics and Control analy-sis – Application to the DHC-2 Beaver (2 parts). MSc-thesis, Delft University ofTechnology, Faculty of Aerospace Engineering, Delft, The Netherlands, 1993.

[29] Rossiter, S.: The Immortal Beaver: The World’s Greatest Bush Plane. Douglas &McIntyre, Canada, 1997.

[30] Ruijgrok, G.J.J.: Elements of Airplane Performance. Delft University Press, Delft,The Netherlands, 1990.

[31] Stengel, R.F., Sircar, S.: Computer-Aided Design of Flight Control Systems.AIAA-91-2677-CP, Princeton, New Jersey, USA, 1991.

[32] Shampine, L.F., Rechelt, M.: The MATLAB ODE Suite. USA, 1997. In: SIAMJournal on Scientific Computing, Volume 18, pp. 1-22, number 1.

[33] Stevens, B.L., Lewis, F.L.: Aircraft Control and Simulation. John Wiley & SonsInc., 1992.

BIBLIOGRAPHY 331

[34] Tjee, R.T.H., Mulder, J.A.: Stability and Control Derivatives of the De HavillandDHC-2 Beaver Aircraft. Report LR-556, Delft University of Technology, Facultyof Aerospace Engineering, Delft, The Netherlands, 1988.

[35] Tomlinson, B.N., Padfield, G.D., Smith, P.R.: Computer-Aided control law re-search – from concept to flight test. In: AGARD Conference Proceedings onComputer Aided System Design and Simulation, AGARD CP-473, London,1990.

[36] Vegte, J. van de: Feedback Control Systems. Prentice Hall, London, UK, 2nd

edition, 1990.

[37] Wever, P.N.H.: Ontwerp en implementatie van de regelwetten van het au-tomatisch besturingssysteem van de De Havilland DHC-2 Beaver. MSc-thesis(in Dutch, not publicly published), Delft University of Technology, Faculty ofAerospace Engineering, Delft, The Netherlands, 1993.

[38] Witzenburg, M. van: De automatische verwerking van – en simulatie met –vliegproefgegevens ter beoordeling van de prestaties van de digitale automatis-che piloot van de DHC-2 Beaver. MSc-thesis (in Dutch, not publicly published),Delft University of Technology, Faculty of Aerospace Engineering, Delft, TheNetherlands, 1995.

a simulink toolbox for flight dynamics and control analysis

Documents