A Simulink Toolbox For Flight Dynamics and Control Analysis

FDC 1.
4 A S IMULINK Toolbox for Flight Dynamics and Control Analysis
DRAFT VERSION 7
Marc Rauw May 25, 2005
The Flight Dynamics and Control Toolbox for M ATLAB and S IMULINK is distributed via the Internet, together with this FDC report, which is available in PostScript and PDF format. If you wish to make a hard-copy of the report, it is advised to download the PostScript version and send it to a PostScript printer or a software PostScript interpreter such as G HOSTSCRIPT (see http://www.ghostscript.com for more information).
A This document was created with M IKTEX in L TEX 2 format. The vector gures were drawn in TEXCAD (part of the EMTEX package for MS-DOS), M ATLAB, S IMULINK, and M AYURA D RAW. The screenshots were created with I RFAN V IEW and the wonderful JPEG 2 PS tool. The Postscript graphics were prepared with the DVI-driver DVIPS, G HOSTSCRIPT and GS VIEW; the PDF version was created with G HOSTSCRIPT and A DOBE A CROBAT.
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 Software 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, version 1.0, the terms of which are incorporated in appendix G. Please read it before using this material - your use of this material signies 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: rauw@dutchroll.com. For the most actual information about the FDC toolbox, see the Dutchroll homepage: http://www.dutchroll.org or http://www.dutchroll.com.
Contents
Preface 1 Flight control system development 1.1 Automatic ight control systems . . . . . . 1.2 The FCS design cycle . . . . . . . . . . . . . 1.3 Taking a closer look at the FCS design cycle 1.4 FCS design environments . . . . . . . . . . 1.5 FCS design and the FDC toolbox . . . . . . vii 1 1 3 4 7 8 11 11 11 12 12 14 18 18 19 20 20 21 21 23 25 27 27 27 28 28 31 32 32 33 34 38 38
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Rigid body equations of motion 2.1 General rigid-body equations of motion . . . . . . . . . . . . . . . . 2.1.1 General force equation for a rigid body . . . . . . . . . . . . 2.1.2 General moment equation for a rigid body . . . . . . . . . . 2.1.3 Angular momentum around the center of gravity . . . . . . 2.1.4 Resulting general equations of motion for a rigid body . . . 2.2 Expressing translational motions in ight-path axes . . . . . . . . . 2.2.1 Advantages of relating translations to ight-path axes . . . 2.2.2 Expressing forces and velocities in terms of ight-path axes 2.2.3 Derivation of the V-equation . . . . . . . . . . . . . . . . . . 2.2.4 Derivation of the -equation . . . . . . . . . . . . . . . . . . 2.2.5 Derivation of the -equation . . . . . . . . . . . . . . . . . . 2.3 Equations of motion in nonsteady atmosphere . . . . . . . . . . . . 2.4 Kinematic relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5 Assembling the state equations . . . . . . . . . . . . . . . . . . . . . The aircraft model 3.1 General structure of the ight simulation model . . . . . . . 3.2 The nonlinear aircraft dynamics . . . . . . . . . . . . . . . . . 3.3 External forces and moments . . . . . . . . . . . . . . . . . . 3.3.1 Aerodynamic Forces & Moments . . . . . . . . . . . . 3.3.2 Engine Forces & Moments . . . . . . . . . . . . . . . . 3.3.3 Gravitational forces . . . . . . . . . . . . . . . . . . . . 3.3.4 Forces and moments due to nonsteady atmosphere . 3.4 Converting the implicit state equations to explicit equations 3.5 Atmosphere and airdata variables . . . . . . . . . . . . . . . 3.6 Additional observation variables . . . . . . . . . . . . . . . . 3.6.1 Body-axes velocity rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ii
CONTENTS
3.7 4
3.6.2 Kinematic accelerations and specic forces . . . . . . . . . . . . 3.6.3 Flight-path related variables . . . . . . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39 40 40 43 43 46 46 48 49 51 55 55 56 63 66 66 68 69 70 71 73 73 74 75 77 83 84 87 87 88 89 90 91 91 92 93 93 96 99 99 100 100 101
External atmospheric disturbances 4.1 Deterministic disturbances . . . . . . . . . . . . . . . . . 4.2 Stochastic disturbances . . . . . . . . . . . . . . . . . . . 4.2.1 Stochastic properties of atmospheric turbulence 4.2.2 Power spectra of atmospheric turbulence . . . . 4.2.3 Filter design for atmospheric turbulence . . . . 4.2.4 Turbulence intensity and scale . . . . . . . . . . Radio-navigation, sensors, actuators 5.1 The Instrument Landing System . . . . . . . . . . 5.1.1 Nominal ILS signals . . . . . . . . . . . . . 5.1.2 Steady-state ILS offset errors and ILS noise 5.2 The VOR navigation system . . . . . . . . . . . . . 5.2.1 Nominal VOR signals . . . . . . . . . . . . 5.2.2 VOR coverage and the Cone of Silence . . 5.2.3 VOR accuracy . . . . . . . . . . . . . . . . . 5.3 Other ight navigation systems . . . . . . . . . . . 5.4 Sensors, Actuators, Flight Control Computer . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
Analytical tools 6.1 Numerical integration methods . . . . . . . . . . . . . . . . . . . . . . 6.1.1 The type of problems considered . . . . . . . . . . . . . . . . . 6.1.2 Stability, errors, and order of a numerical integration method 6.1.3 Main categories of numerical integration methods . . . . . . . 6.1.4 Stiff differential equations . . . . . . . . . . . . . . . . . . . . . 6.2 System linearisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 Steady-state trimmed ight . . . . . . . . . . . . . . . . . . . . . . . . 6.3.1 Denition of steady-state ight . . . . . . . . . . . . . . . . . . 6.3.2 Specication of the ight condition . . . . . . . . . . . . . . . . 6.3.3 Remaining control and state variables . . . . . . . . . . . . . . 6.3.4 The rate-of-climb constraint . . . . . . . . . . . . . . . . . . . . 6.3.5 The coordinated turn constraint . . . . . . . . . . . . . . . . . 6.3.6 Combined constraints . . . . . . . . . . . . . . . . . . . . . . . 6.3.7 The resulting steady-state trimmed-ight algorithm . . . . . . 6.4 Miscellaneous simulation issues . . . . . . . . . . . . . . . . . . . . . . 6.4.1 Algebraic loops . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.2 Obtaining state-models from transfer functions . . . . . . . . Getting started with the FDC toolbox 7.1 Objectives of the FDC toolbox . . . . . . 7.2 System requirements . . . . . . . . . . . 7.3 License Agreement . . . . . . . . . . . . 7.4 Installation and initialisation of FDC 1.4
. . . . . . . . . . . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
CONTENTS
iii
7.5 7.6 7.7 7.8 7.9 7.10 7.11 7.12 7.13 8
Uninstalling FDC 1.4 . . . . . . . . . . . . . . . . The FDC directory structure . . . . . . . . . . . . The FDC model libraries . . . . . . . . . . . . . . Taking a closer look at the aircraft model . . . . Linking to S IMULINK libraries . . . . . . . . . . . Summary of the model and library structure . . Colour conventions for the FDC models . . . . . Some cautions . . . . . . . . . . . . . . . . . . . . About the block and function reference chapters
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
105 106 106 108 109 113 113 114 115
Aircraft model block reference 117 8.1 The aircraft model and its subsystem equivalents . . . . . . . . . . . . . 117 8.2 The aircraft model block libraries . . . . . . . . . . . . . . . . . . . . . . 120 Wind and turbulence block reference 165 9.1 The wind and turbulence blocklibrary . . . . . . . . . . . . . . . . . . . 165
10 Radio-navigation block reference 179 10.1 The radio-navigation blocklibrary . . . . . . . . . . . . . . . . . . . . . 179 11 FDC implementation of the analytical tools 11.1 The trimming facility . . . . . . . . . . . . . . . . . . . . . . . 11.1.1 Program structure of ACTRIM . . . . . . . . . . . . . . 11.1.2 Using ACTRIM in practice . . . . . . . . . . . . . . . . 11.2 The linearization facility . . . . . . . . . . . . . . . . . . . . . 11.2.1 Program structure of ACLIN . . . . . . . . . . . . . . . 11.2.2 Using ACLIN in practice . . . . . . . . . . . . . . . . . 11.3 The routine SYSTPROP to compute linear system-properties 11.4 Programs for post-processing simulation results . . . . . . . 11.4.1 The routine RESULTS . . . . . . . . . . . . . . . . . . 11.4.2 The routine RESPLOT . . . . . . . . . . . . . . . . . . 12 Support functions reference 12.1 A brief overview of the support utilities . . . . . . . . 12.2 Toolbox initialisation functions . . . . . . . . . . . . . 12.2.1 FDC . . . . . . . . . . . . . . . . . . . . . . . . 12.2.2 FDCINIT . . . . . . . . . . . . . . . . . . . . . . 12.2.3 FDC_SPLASH . . . . . . . . . . . . . . . . . . . 12.3 Directory functions . . . . . . . . . . . . . . . . . . . . 12.3.1 FDCDIR . . . . . . . . . . . . . . . . . . . . . . 12.3.2 DATADIR, HELPDIR . . . . . . . . . . . . . . . . 12.4 Data load functions . . . . . . . . . . . . . . . . . . . . 12.4.1 FDCLOAD . . . . . . . . . . . . . . . . . . . . . 12.4.2 DATLOAD, LINLOAD, MATLOAD, and TRILOAD 12.5 Generic helper functions . . . . . . . . . . . . . . . . . 12.5.1 BROWSE . . . . . . . . . . . . . . . . . . . . . . 12.5.2 NEWMSGBOX . . . . . . . . . . . . . . . . . . . 12.5.3 NUM2STR2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 196 196 198 201 201 202 203 204 204 205 207 207 208 208 209 210 210 210 211 211 212 212 214 214 215 215
iv
CONTENTS
12.5.4 SCREENSIZE . . . . . . 12.5.5 TXTMENU . . . . . . . . 12.6 Model-specic helper functions 12.6.1 MODBUILD . . . . . . . 12.6.2 FIXSTATE . . . . . . . . 12.6.3 RESULTS . . . . . . . . 12.6.4 RESPLOT . . . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
216 216 217 217 219 221 221
13 Using the FDC toolbox for open-loop analysis 221 13.1 Non-linear responses to deterministic inputs OLOOP1 . . . . . . . . . 221 13.1.1 Structure of the system OLOOP1 . . . . . . . . . . . . . . . . . . 221 13.1.2 Performing simulations with OLOOP1 . . . . . . . . . . . . . . . 224 13.1.3 Analyzing simulation results . . . . . . . . . . . . . . . . . . . . 225 13.2 Non-linear responses to stochastic inputs OLOOP2 . . . . . . . . . . . 225 13.2.1 Structure of the system OLOOP2 . . . . . . . . . . . . . . . . . . 225 13.2.2 Performing simulations with OLOOP2 and analyzing the results 226 13.3 Linear responses to deterministic inputs OLOOP3 . . . . . . . . . . . 227 13.3.1 Structure of the system OLOOP3 . . . . . . . . . . . . . . . . . . 227 13.3.2 Performing simulations with OLOOP3 and analyzing the results 228 13.4 Trim-demo: trimmed-ight elevator deection curve . . . . . . . . . . 231 14 Beaver autopilot Theory 14.1 Basic autopilot functions . . . . . . . . . . . . . . . . . . . . . 14.2 The longitudinal autopilot modes . . . . . . . . . . . . . . . . 14.2.1 Pitch Attitude Hold mode . . . . . . . . . . . . . . . . 14.2.2 Altitude Hold mode . . . . . . . . . . . . . . . . . . . 14.2.3 Altitude Select mode . . . . . . . . . . . . . . . . . . . 14.2.4 Longitudinal part of the Approach mode: Glideslope 14.2.5 Longitudinal part of the Go Around mode . . . . . . 14.3 The lateral autopilot modes . . . . . . . . . . . . . . . . . . . 14.3.1 Roll Attitude Hold mode with turn-coordinator . . . 14.3.2 Heading Hold/Heading Select mode . . . . . . . . . 14.3.3 Lateral part of the Approach mode: Localizer . . . . 14.3.4 VOR navigation mode . . . . . . . . . . . . . . . . . . 14.3.5 Lateral part of the Go Around mode . . . . . . . . . . 14.4 Turn-compensation . . . . . . . . . . . . . . . . . . . . . . . . 14.4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 14.4.2 Correction of the pitch rate in turns . . . . . . . . . . 14.4.3 Correction for the loss of lift in turns . . . . . . . . . . 14.4.4 Total turn-compensation . . . . . . . . . . . . . . . . . 14.5 The signal limiters . . . . . . . . . . . . . . . . . . . . . . . . . 239 239 241 241 242 243 243 245 246 246 247 249 250 251 253 253 253 253 254 256 261 261 261 262 263
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
15 Beaver autopilot Simulation models 15.1 Implementing separate control laws in S IMULINK . . . . . . . . . . 15.1.1 Structure of the control-law simulation models . . . . . . . . 15.1.2 S IMULINK implementation of the Pitch Attitude Hold mode 15.1.3 S IMULINK implementation of the Roll Attitude Hold mode .
. . . .
. . . .
CONTENTS
15.1.4 Using the PAH and RAH simulation models in practice . . . . . 15.2 Integral autopilot simulation model . . . . . . . . . . . . . . . . . . . . 15.2.1 General structure of the autopilot simulation model . . . . . . . 15.2.2 Implementation of the symmetrical autopilot modes . . . . . . 15.2.3 Implementation of the asymmetrical autopilot modes . . . . . . 15.2.4 Implementation of the Mode Controller . . . . . . . . . . . . . . 15.2.5 Implementation of atmospheric disturbances . . . . . . . . . . . 15.2.6 Blocks to obtain small-deviation signals from the aircraft model 15.2.7 Additional blocks on the input side of the aircraft model . . . . 15.2.8 Additional blocks on the output side of the aircraft model . . . 15.3 Performing simulations with the autopilot models . . . . . . . . . . . . 15.3.1 Autopilot model initialization . . . . . . . . . . . . . . . . . . . . 15.3.2 Examples of non-linear autopilot simulations . . . . . . . . . . . A Symbols and denitions A.1 List of symbols . . . . . . . . . . . . . . . . . . . . . . . . . . A.2 Vectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.3 Matrices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.4 Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.5 Indices and subscripts . . . . . . . . . . . . . . . . . . . . . . A.6 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . A.7 Reference frames and sign conventions . . . . . . . . . . . . A.7.1 Denitions . . . . . . . . . . . . . . . . . . . . . . . . . A.7.2 Summary of the application of the reference systems A.7.3 Relationships between the reference frames . . . . . . A.7.4 Sign conventions for deections of control surfaces .
266 268 268 271 272 273 275 275 276 278 279 279 281 285 285 289 289 289 289 290 291 291 292 293 297 299 299 299 300
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
B Beaver model parameters B.1 General aircraft data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.2 Flight envelope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.3 Aerodynamic and engine model parameters . . . . . . . . . . . . . . .
C Data structure of the FDC model parameters 305 C.1 Dening the model parameters in the M ATLAB workspace . . . . . . . 305 C.2 Denition of the parameter matrices for the Beaver model . . . . . . . 306 D Data structure of the FDC model output signals 309 D.1 Aircraft model signal logging . . . . . . . . . . . . . . . . . . . . . . . . 309 D.2 Radio navigation signal logging . . . . . . . . . . . . . . . . . . . . . . . 310 E Denitions of variables and acronyms from FDC 1.4 E.1 Variables and acronyms from the graphical models . . . E.1.1 Aircraft model (system Beaver) . . . . . . . . . . . E.1.2 Autopilot models (systems APILOT1 to APILOT3) E.1.3 Radio-navigation models (library NAVLIB) . . . . E.1.4 Wind and turbulence models (library WINDLIB) . F The Open Software License v. 2.1 313 313 313 316 318 319 321
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
vi
CONTENTS
G Common Documentation License Bibliography
325 329
Chapter 1
Flight control system development

During the last decades, active ight control technology has dramatically changed the way aircraft are designed and own. Flight control systems with mechanical linkages have been replaced by full authority, y-by-wire, digital control systems. As a consequence, the ying qualities of modern aircraft are largely determined by a set of control laws in the heart of a computer system. Modern computer assisted control system design (CACSD) software provides a wide variety of user-friendly analytical tools that can assist in ight control system (FCS) design and analysis. A typical example is the M ATLAB / S IMULINK software environment from The Mathworks, which offers advanced modelling and simulation capabilities and easy access to control system design tools. The Mathworks and other vendors offer several specialized toolboxes for a wide range of control system design methods. A prerequisite for successful FCS design is the availability of sophisticated mathematical models of the airplane, the environment it has to operate in, and elements from the control system itself. The FDC toolbox tries to offer such models for the M ATLAB / S IMULINK environment, and several tools and utilities to access those models. This chapter provides an overview of ight control systems in general, and offers some insight in the FCS design process, in order to put the objectives behind the FDC toolbox into the right perspective.
1.1
Automatic ight control systems
A major factor in Wright brothers success in achieving the rst powered ight in December 1903 has been the emphasis they placed on making their aircraft controllable by the pilot, rather than inherently stable. However, the difculties of controlling early aircraft and the progress toward longer ight times, expanded ight-envelopes, and bigger aircraft created a need for the development of power-driven aerodynamic control surfaces, stability augmentation systems, and automatic pilot systems. This evolution of ight control systems has been parallelled by the development of closedloop control theories and major achievements in computer technologies [33]. Since the term automatic ight control systems can be used to describe a wide variety of controllers, categorizing them into different categories can be benecial. The rst class of automatic controllers are the Stability Augmentation Systems (SAS).
Chapter 1. Flight control system development
These systems are used to damp and stabilize high-frequency rotational modes of the aircraft, making it easier for pilots to control the aircraft. Common types of SAS are roll dampers, pitch dampers, and yaw dampers. If an augmentation system is intended to control a rotational mode and to provide the pilot with a particular type of response to the control inputs, it is known as a 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 to a conventional control system with a direct mechanical linkage between the control actuators and the control column, are often called control wheel steering systems (CWS). If the connection is achieved by means of electrical (or optical) wires, such controllers are usually called y-by-wire systems. Although the slow modes of an aircraft (phugoid and spiral) are more easily controllable by a pilot, it still is undesirable for a pilot to have to pay continuous attention to controlling these modes, especially during longer ights. Therefore, an automatic controller is often needed to provide pilot relief. An autopilot is an automatic control system that provides both pilot relief functions and special functions such as automatic landing. Typical autopilot functions are attitude hold, altitude hold, turncoordination, heading select, automatic approach, and VOR navigation. Modern aircraft also allow the autopilot to be coupled to a ight management system (FMS), which offers ight path optimisation and wide-area navigation through the use of inertial reference system and global positioning system guidance and navigation. In summary, we can conclude that the main function of an FCS is to contribute to the safe, comfortable, and economic operation of the aircraft, such that the intended ight missions can be accomplished and unexpected events can be handled. A modern FCS consists of three main components [24]: (i) sensors, which provide the ight control computers information on air data, inertial data, and cockpit data, (ii) the ight control computers themselves, which are used to evaluate the ight control 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 external disturbances such as gusts and turbulence, and to provide robustness against modelling errors. Fly-by-wire systems allow the pilot to control aircraft states, in contrast to the conventional direct control of aerodynamic control surfaces and engines. This offers enhanced exibility for the control laws, which provides new opportunities to increase the overall safety level. For example, error-tolerant control laws can provide ight envelope protection, and help the pilot to successfully achieve critical ight manoeuvres and to recover from unusual attitudes. The use of a modern FCS can also be benecial from an economic point of view: fuel consumption can sometimes be reduced by relaxing static stability, counteracted by the application of active control, and the weight of y-by-wire systems is often lower than that of conventional control systems. Furthermore, y-by-wire systems make it possible to give different aircraft of different sizes almost the same feel, allowing the creation of a large aircraft family that will signicantly reduce pilot training costs. Most importantly, modern ight control systems have contributed to improved dynamical behaviour. Certain military aircraft cannot be own without a stability augmentation system; they use the open-loop instability, which is related to the
1.2. The FCS design cycle
agility of the aircraft, to obtain better performance and improved manoeuvrability of the closed-loop system. For civil aircraft, active ight control systems can provide gust suppression and auto-trimming, in order to achieve improved ride quality. A disadvantage of these techniques is that the costs and efforts involved to develop an advanced FCS have escalated over the years. The danger exists that the economical benets described above are nullied by higher design and maintenance costs, while the increasing complexity of modern ight control systems can potentially have a negative effect on safety. Clever use of modern FCS design techniques and optimisation of the design tools will be necessary to counteract these disadvantages [24].
1.2
The FCS design cycle
Regardless of the level of complexity, it is always possible to divide the control system design process into a number of distinct phases. A practical division is given in ref.[26] (a reference, which, albeit somewhat outdated with respect to the available computer hardware and software tools, is still valuable for this discussion): 1. Establish the system purpose and overall system requirements. System purpose can be equated with mission or task denitions, while the system requirements can be separated in (i) operational requirements, derived from the functions needed to accomplish the mission phases and (ii) implied requirements, derived from the characteristics of the interconnected components of the control system and the environment in which they operate. 2. Determine the characteristics of unalterable elements, command-signals, and external disturbances. The characteristics of some parts of the system cannot easily be changed by the designer. Often the vehicle itself, its control surface actuators and sometimes also its sensors are unalterable.1 Moreover, the structure of the commands and disturbances is a direct consequence of the mission requirements 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 different sensed motion quantities and/or the application of different control theories. Then it is possible to evolve competing candidate systems for selection on the basis of certain desirable properties. 4. Select the best system. The competing designs can be compared on the basis of (i) design qualities, which include dynamic performance (speed of response, bandwidth, etc.) and physical characteristics (volume, weight, power consumption, etc.), and (ii) design quantities, which include safety, reliability, maintainability, cost, etc. An optimum system is one that has some best combination of these features.
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 as being unalterable. In this report, all hardware is considered to be given, so we will concentrate on issue of developing appropriate control laws to make a given aircraft y a certain mission.
1 If
5. Study the selected system in detail. The selected system must be evaluated for all normal and abnormal operating conditions. At each step in the FCS validation the assumptions made earlier in the FCS design process must be checked for validity. If necessary, a new iteration of the design should be started from the point where the wrong assumption was made. This scheme reects the FCS design process within a manufacturing environment. In a research context, the design process may have to be modied somewhat, as the research and manufacturing tasks are clearly different: whereas the task of research is to determine what is required and to produce a clear and comprehensive denition of the requirements, the manufacturing task is to make and deliver a reliable and effective product [35]. Consequently, the rst FCS design phase in particular will often be different in a research environment, because the system requirements are often poorly understood or may even be the objective of the research itself. In addition, the design tools may still be immature, and their development may itself be an objective of the research. See for instance the development of the FDC toolbox in the context of the Beaver autopilot studies. The design, simulation, and implementation of control laws within a research context will be similar to the manufacturing task, although more exibility of the tools will sometimes be required. For instance, it should be possible to rapidly alter the control laws within the ight control computers of the aircraft in order to evaluate different solutions to typical control system design problems with a minimum of programming efforts. In the research environment, step 4 does not necessarily need to include the selection of a best system since it may be useful to evaluate competing control solutions, if necessary even all the way up to evaluation in real ight, just to gain more knowledge about their advantages and disadvantages. A typical example of this can be found in ref.[24], which treats a GARTEUR design challenge of robust ight control systems. Finally, the requirements with respect to fail-safety of the FCS may be less restrictive in a research context than for manufacturing. For instance, during the autopilot design project for the DHC-2 Beaver laboratory aircraft, a single ight control computer (a luggable 80286 Compaq PC, coupled to a 16-bit ROLM-1603 generalpurpose computer that handled the I/O functions; see refs.[6], [28], [37], and [38]) was used, whereas production aircraft normally apply multiple FCCs that constantly monitor eachothers command signals.
1.3
Taking a closer look at the FCS design cycle
Lets explore the individual design phases a little further. Figure 1.1 visualizes the rst step in the FCS design process: the denition of the mission, which imposes requirements upon the shape of the ight-path and the velocity along this ight-path. This translates into the control problem depicted in gure 1.2: how to generate appropriate deections of aerodynamic control surfaces or changes in engine power or thrust such that this mission can be fullled. The classical approach to the FCS design problem is to start with the complete set of non-linear equations of motion, and then make assumptions which enable these equations to be linearized about some local equilibrium point. Getting familiar with
1.3. Taking a closer look at the FCS design cycle
Mission
Flight-path ( t )
Control Surface Deflections ( t )
Figure 1.1: Denition of the aircrafts mission
Specify Control Problem
Design Control Laws
Achieve Specified Behaviour
Model Real World

Figure 1.2: The general ight control problem
the dynamical behaviour by means of trimming, stability and control analysis, and nonlinear open-loop simulations (for stable aircraft), and understanding the inuences of the modelling assumptions is very important, and linear simulation of the aircraft model may also be required at this stage [24]. The next step is to dene the controller architecture. In the initial phase of the FCS design, control system design tools based upon linear system theory can be applied to linearized models of the aircraft and its subsystems; modern CACSD software provides the required computer support. Although the linear control system design and analysis techniques will provide insight in the essential behavior of the FCS, only relatively small deviations from the equilibrium state are permitted before the results start to deviate from those of the real aircraft. Luckily the main purpose of many FCS control laws is to keep the deviations from the equilibrium state as small as possible, e.g. in order to maintain a certain altitude or heading, but there are other control laws which require large deviations from nominal values, e.g. selecting a new reference heading or altitude which differs con-
siderably from the original value. For this reason, detailed nonlinear simulations will be required, in order to validate (and possibly enhance) the results from the linear analysis and design phase. Gain scheduling functions need to be implemented, to ensure that the FCS will work well over the compete range of the ight-envelope for which it is designed, taking into account a suitable safety margin. Also, signal limiters will be required to deal with certain physical limitations (e.g. the maximum deection of control surfaces) and for safety reasons. If a robust design is to be achieved, much attention should be given to understanding nonlinearities and model uncertainties. This off-line analysis, which should cover a wide range of velocities and altitudes and all possible aircraft congurations, can be performed on a single PC or workstation, using an integrated design and simulation environment such as M ATLAB / S IMULINK. Off-line in this context means that the analysis does not have to be performed in real-time and does not yet include piloted ight-simulation. In a later stage the control system will have to be evaluated in a real-time pilot-in-the-loop simulation environment, to enable test-pilots to assess the handling qualities of the automatically controlled aircraft. In particular, the pilotaircraft interaction should be examined thoroughly, especially if the pilot will be actively involved in the aircraft control loop (e.g. for y-by-wire systems). Based upon these results it is possible to select the best solution if there are more feasible methods to fulll the mission requirements. If the results of the on-line and off-line analysis are completely satisfactory the next step in the design process will be the implementation of the control laws in the ight control computer(s) of the aircraft. The actuators and sensors in the aircraft must be installed (if that hasnt been done already), thoroughly tested, and calibrated. For some purposes, e.g. aircraft certication, it may even be useful to test the complete control system in an Iron Bird test-stand arrangement with hardware-in-the-loop simulation capabilities. Special care has to be taken to prevent errors due to the conversion of control laws when moving from one design phase to the next. In particular, the transfer of control laws from the simulation environment to the ight control computers of the aircraft needs to be carefully veried, to ensure that the control laws used in ight match those analyzed on the ground.1 In order to reduce the risks of such conversion errors, it would be benecial to be able to couple at least the complete FCC software, but preferably also its hardware, to the real-time ight-simulator and/or off-line design environment. After successfully concluding the simulations and ground tests of the hardware and FCC software, the FCS can be evaluated in real ight. In an ideal world this phase would only be a straightforward verication of the previous results, but in practice it will often be necessary to return to a previous stage in the FCS development for xing errors or ne-tuning the control laws. It also may be necessary to update the mathematical models if deciencies in these models are found during the in-ight
the Beaver autopilot studies some dramatic examples of conversion errors were encountered, luckily for a large part before the ight-tests were started. Still, some minor errors remained undiscovered until the actual ight-tests! References [28], [37], and [38] provide ample food for thought for future FCS projects.
1 During
1.4. FCS design environments
evaluations. Quantitative results from the ight tests need to evaluated on-ground to conrm the correct control behavior. Obviously, the off-line CACSD environment that was used for the FDC design can also provide the required computer support for this post-ight analysis. The iterative nature of this FCS development cycle should be acknowledged: at any stage in the process, the discovery of a fault, design error, or previously unrecognized uncertainty might require the return to a previous design stage. Figure 1.3 summarizes the FCS design process. It illustrates the different design stages from ref.[26] and the more detailed divisions presented in refs.[12], [31] and [35], and it clearly acknowledge the iterative nature of the whole process. On the left-hand side of the gure 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 development phases as straightforward as possible, in order to reduce the number of transition errors which inevitably will arise if the tools for the different phases are not compatible (Murphys Law), and also to reduce the time needed for the FCS development. For this reason, there is a need for an integrated software environment that provides full access to all required mathematical models, as well as a large range of linear and nonlinear control system design and simulation tools, preferably from a single PC or workstation. The software tools for the off-line analysis should be able to effectively communicate with eachother, the tools for real-time pilot-in-the-loop simulations, and with the ight control computers of the actual aircraft. Access to the 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 environments. These papers particularly emphasize the need for multidisciplinary design in which aerodynamic, structural, propulsive, and control functions are considered all together. This is important, because modern ight controllers may excite structural modes of the aircraft and interact with the control-actuator dynamics, and because of the increasing need to integrate ight controls with engine controls and load-alleviation functions. Interactions between the aerodynamic, propulsive, and structural models must be taken into account, especially for modern aircraft that employ 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 attempts to bring the required tools and models together in the M ATLAB / S IMULINK environment. It basically provides easy access to the ight dynamics models and other relevant dynamic models, allowing the FCS designer to use M ATLAB (if necessary including a selection of the available control system design tools) for the initial FCS development, and use S IMULINK for the subsequent nonlinear off-line simulations. The toolbox itself provides an analytical software tool to trim aircraft models for steady-state ight. It applies S IMULINK functions to extract linear state-space de-
Linearized models
Linear FCS design
M
Trimming & Linearization
SIMULINK model-library with nonlinear aircraft model

Future: automatic transfer of models?
Nonlinear FCS validation & fine-tuning
Current scope of the FDC environment
Flightsimulator model-library with nonlinear aircraft model
Evaluation in real-time piloted flightsimulation
Future enhancements
Update sensor/actuator models
Implementing FCS hardware and software
Update aero/engine models
Evaluation in real flight
A
M S F A = = = = MATLAB SIMULINK Real-time flightsimulator Actual aircraft
Figure 1.3: FCS design cycle using M ATLAB and S IMULINK
scriptions of aircraft models and perform digital ight simulation. Several other M ATLAB toolboxes, from The Mathworks and others, can be used to perform a multitude 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 gure 1.3, above the dashed line on the right. Starting from the S IMULINK model library, it is possible to obtain linearized models. Using designated control system design tools from other M ATLAB toolboxes, controllers can be developed for the resulting linear systems. The resulting control laws can be evaluated in S IMULINK, by means of nonlinear simulations; the required models are again obtained from the FDC model library. However, the FDC toolbox does not (yet) offer any help to simplify the subsequent design steps, being evaluation in a real-time piloted ight simulator and eval-
1.5. FCS design and the FDC toolbox
Graphical SIMULINK system C-code generator Control Laws (block-diagram)
Graphical SIMULINK system
Control Laws (C-code)
Flight Simulator Control Laws (C-code)
Control Laws (C-code)
Flight Control Computer
} }
Off-line
Real-time
Figure 1.4: Portable control laws
uation in real ight. If the designer wants to move his control laws to these next levels, he or she will still have to convert the control laws and the dynamic models manually to the ightsimulator and/or the ight control computers of the airplane; the FDC toolbox does not provide any assistance for that task. This is obviously still a major obstacle in the FCS development process, because it increases the chance of encountering conversion errors, as explained earlier. The gure suggests that automatic transfer of complete simulation models from the S IMULINK environment to a ightsimulator might be feasible. However, it would probably 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 automatic conversion of the control laws only, using e.g. automatic code-generation software to translate S IMULINK models into a high-level programming language like C. Dedicated interface-subroutines that will optimize communications between the offline S IMULINK-environment and the on-line ightsimulator environment could help streamline these conversions. This concept of portable ight control laws has been illustrated in gure 1.4, assuming that the language C is used to implement the ight control laws in the ightsimulator and FCCs. The Mathworks offers several solutions which could be helpful for this purpose, such as the R EALTIME W ORKSHOP and the R EALTIME W ORKSHOP E MBEDDED C O DER , the latter of which targets real-time embedded processors, DSP boards, realtime operating systems, and PCs. Other useful third-party tools that could be applied to interface with the FDC models are S TATEFLOW, which can e.g. be used to create very complex mode-controller systems, the D IALS & G AUGES B LOCKSET, which allows a.o. graphical display of cockpit instruments during S IMULINK simulations,
10
and the V IRTUAL R EALITY T OOLBOX, which provides three-dimensional animation facilities for S IMULINK models. There are also several third-party products available that allow S IMULINK models to be coupled to specic experimental hardware setups. By integrating M ATLAB, S IMULINK, and other tools that allow easy interfacing with external simulation devices or FCCs, quick prototyping of ight control laws becomes feasible, and the transitions between off-line simulations, real-time simulations, and actual ight could be streamlined enormously. It is not likely that these functions will soon be integrated in future versions of the FDC toolbox, no matter how exciting those prospects may be. Any future work on this software will probably mainly be concentrated on optimizing and improving the existing tools and models, and widening the application areas of the toolbox within its current scope. However, it is hoped that this far-reaching vision of FDCs future will inspire others to develop their own add-ons or variants of the software, so that maybe 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 fundamental knowledge about the equations of motion is needed. In this chapter, the equations of motion of a rigid aircraft will be derived and expressed in the state-space form; a summary of these state equations will be given in section 2.5. The next chapter will build upon these equations to construct the nonlinear six-degree-of-freedom aircraft model. 1
2.1
General rigid-body equations of motion
The aircraft equations of motion will be derived from Newtons laws, which state the connection between force and motion. We start by deriving the general force and moments equations for a rigid body and dening the relations for the angular momentum. This results in six ordinary differential equations, representing the linear and angular accelerations in the body-xed 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 inuence of a force F. Both V and F are measured relatively to a right-handed orthogonal reference frame OXYZ. This reference frame may be moving with a constant linear velocity, relative to the xed position of the stars (a.k.a. inertial space), but it may not accelerate or rotate. Applying Newtons second law yields: F = m V (2.1) Applying this equation to all mass points of a rigid body and summing all contributions across this body yields: d Vm (2.2) dt Let the center of gravity of the rigid body have a velocity Vc.g. with components u, v, and w along the X, Y, and Z-axes of the right-handed reference frame. The velocity of each mass point within the rigid body then equals the sum of Vc.g. and
F = m dt
dV
1 The derivation of the rigid-body equations has been extensively discussed in literature. This chapter 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 of the mass point with respect to the c.g. is denoted by the vector r, the following vector equation is found: V = Vc.g. + r therefore: Vm = (Vc.g. + r)m = mVc.g. + dt rm d (2.4) (2.3)
In this equation, m denotes the total mass of the rigid body. In the center of gravity we can write:
r m = 0
so the equation for the total force F acting upon the rigid body, becomes: F = mVc.g.
(2.5) (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 the time-derivative of the angular momentum of the mass point relative to the c.g.: M = where: r = V Vc.g. 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 dened as: h (r V)m. Writing this out yields: Mc.g. = h (V Vc.g. ) Vm = h + Vc.g. Vm (2.10) The contributions of all mass points are once again summed across the whole rigid body, yielding: Mc.g. = h + Vc.g. Vm 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 of gravity. (2.11) (2.8) d (r V)m = (r V)m + (r V)m dt (2.7)
2.1.3
Angular momentum around the center of gravity
Consider a rigid body with angular velocity , with components p, q, and r about the X, Y, and Z axes of the right-handed reference frame respectively: = i p+jq+kr (2.13)
2.1. General rigid-body equations of motion
13
symbol Ixx Iyy Izz Jxy Jxz Jyz
denition (y2 + z2 ) m ( x2 + z2 ) m ( x2 + y2 ) m xy m xz m 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 velocity vector of a mass point of a rigid body that both translates and rotates becomes: V = Vc.g. + r h (2.14) hence, the angular momentum of the rigid body about the c.g. can be written as:
r (Vc.g. + r)m = r Vc.g. m + r ( r)m

(2.15) (2.16)
The rst term of the right hand side of equation (2.15) is equal to zero:
rm
Vc.g. = 0 =
and for the second term we can write:
r ( r)m
(r r) r( r) m =
r ( r) m (2.17)
(2.18)
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 The components of h along the X, Y, and Z axes will be denoted as h x , hy , and hz respectively, yielding: h x = p (y2 + z2 )m q xy m r xz m hy = p xy m + q ( x2 + z2 )m r yz m hz = p xz m q yz m + r ( x2 + y2 )m (2.19)
The summations appearing in these equations are dened as the inertial moments and products about the X, Y, and Z axes respectively; see table 2.1.1 Using these denitions, equations (2.19) can be written in vector notation as a product of the inertia tensor I with the angular velocity vector : h = I where I is dened as: Ixx Jxy Jxz I = Jyx Iyy Jyz Jzx Jzy Izz (2.20)
(2.21)
1 The summations across the body actually have to be written as integrals, but that further renement has been omitted here.
14
If the airplane is symmetrical, Jxy and Jyz are both identically zero, which would further 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 necessarily have to be symmetrical. So far, in this analysis of angular motion we have neglected the angular momentum of any spinning rotors, assuming that the airplane is a single rigid body. However, these effects can actually be quite signicant in practice. For example, a number of World War I aircraft had a single rotary engine that had a xed crankshaft and rotating cylinders; the gyroscopic effects caused by the angular momentum of the engine gave these aircraft tricky handling characteristics. The effects are also noticeable in maneuvering ight of a small jet with a single turbofan engine on the longitudinal axis [33]. Each rotor has an angular momentum relative to the body axes. This can be computed from equation (2.20) by interpreting the moments and products of inertia therein as those of the rotor with respect to the axes parallel to the airplane bodyaxes 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 the resultant relative angular momentum of all rotors is called h , with components h x , hy , and hz in FB , which are assumed to be constant, the total angular momentum of an airplane with spinning rotors can be obtained by simply adding h to the angular momentum of the airframe: h = I+h (2.22) The additional terms in the angular momentum cause certain extra terms, known as gyroscopic 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 xed to the body (OXYZ = OXB YB ZB ) the inertial moments and products from the equations (2.19) become constants. The reference frame itself then rotates with angular velocity . For an arbitrary position vector r with respect to the body reference frame we can then write: r r= +r (2.23) t Applying equation (2.23) to the general force and moment equations for a rigid body, (2.6) and (2.12), we nd: Vc.g. F=m + Vc.g. (2.24) t and: h Mc.g. = +h = I+h + I+h = t t = (2.25) (I ) + (I ) + h t The last term in this equation, h , contains the gyroscopic couples, which take into account the effect of spinning rotors. Notice that this derivation assumes the resulting angular momentum of the rotors to be constant.
15
symbol
denition Ixx Iyy Izz 2Jxy Jxz Jyz Ixx Jyz 2 Iyy Jxz 2 Izz Jxy 2 Iyy Izz Jyz 2 Jxy Izz + Jyz Jxz Jxy Jyz + Iyy Jxz Ixx Izz Jxz 2 Ixx Jyz + Jxy Jxz Ixx Iyy Jxy 2 I1 / | I | I2 / | I | I3 / | I | ( Jxz I2 Jxy I3 ) / | I | ( Jxz I1 Jyz I2 ( Iyy Ixx ) I3 ) / | I | ( Jxy I1 + ( Ixx Izz ) I2 Jyz I3 ) / | I | ( Jyz I1 Jxy I3 ) / | I | (( Izz Iyy ) I1 Jxy I2 + Jxz I3 ) / | I | ( Jyz I1 Jxz I2 ) / | I | I2 / | I | I4 / | I | I5 / | I | ( Jxz I4 Jxy I5 ) / | I | ( Jxz I2 Jyz I4 ( Iyy Ixx ) I5 ) / | I | ( Jxy I2 + ( Ixx Izz ) I4 Jyz I5 ) / | I | ( Jyz I2 Jxy I5 ) / | I | (( Izz Iyy ) I2 Jxy I4 + Jxz I5 ) / | I | ( Jyz I2 Jxz I4 ) / | I | I3 / | I | I5 / | I | I6 / | I | ( Jxz I5 Jxy I6 ) / | I | ( Jxz I3 Jyz I5 ( Iyy Ixx ) I6 ) / | I | ( Jxy I3 + ( Ixx Izz ) I5 Jyz I6 ) / | I | ( Jyz I3 Jxy I6 ) / | I | (( Izz Iyy ) I3 Jxy I5 + Jxz I6 ) / | I | ( Jyz I3 Jxz I5 ) / | I |
Table 2.2: Denition of inertia coefcients
|I| I1 I2 I3 I4 I5 I6
Pl Pm Pn Ppp Ppq Ppr Pqq Pqr Prr Ql Qm Qn Q pp Q pq Q pr Qqq Qqr Qrr Rl Rm Rn R pp R pq R pr Rqq Rqr Rrr
16
The vector-equations (2.24) and (2.25) form the basis for the development of the general rigid-body dynamic model. In order to make these equations usable for control system design and analysis, ight simulation, system identication, and other analytical tasks, they need to be rewritten in nonlinear state-space format. This can be achieved by moving the time-derivatives of the linear and angular velocities to the left-hand side of these equations: Vc.g. F = Vc.g. (2.26) t m = I1 Mc.g. I h (2.27) t These equations can be written-out into their components along the body-axes, using the following denitions for Vc.g. , , F, and Mc.g. : Vc.g. F Mc.g.
= = = =
iu ip iFx iL
+ + + +
jv jq jFy jM
+ + + +
kw kr kFz kN
This yields: Fx qw + rv m Fy + pw ru v = m Fz w = pv + qu m and: u =

p = Ppp p2 + Ppq pq + Ppr pr + Pqq q2 + Pqr qr + Prr r2 + Pl L + Pm M + Pn N + p q = Q pp p2 + Q pq pq + Q pr pr + Qqq q2 + Qqr qr + Qrr r2 + Ql L + Qm M + Qn N + q r = R pp p2 + R pq pq + R pr pr + Rqq q2 + Rqr qr + Rrr r2 + Rl L + Rm M + Rn N + r (2.29)
(2.28)
The last terms in equations (2.29) express the effects of the gyroscopic couples: p = qhz rhy q = rh x phz r = phy qh x Ppp , Ppq , . . . , Rn are inertia coefcients, which are derived from the matrix multiplications 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 the Earth if the following four restrictive assumptions are made: 1. the body is assumed to be rigid during the motions considered (attached spinning rotors are allowed, provided these are accounted for in the moment equations), 2. the mass of the body is assumed to be constant during the time-interval in which its motions are studied, (2.30)
17
3. the Earth is assumed to be xed 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 in which the motions of the rigid body are considered is xed to the Earth. If the equations are to be applied to a moving vehicle, the description of the vehicle motion under assumptions 3 and 4 are accurate for relatively short-term guidance and control analysis purposes only. The assumptions do have practical limitations when very long 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 vector Vc.g. will from this point onwards shortly be denoted as V. The body-axes components of this vector are u, v, and w, respectively, and the length of this vector is denoted as V. Likewise, the subscript c.g. will be omitted from the moment vector Mc.g. in the remainder of this report. In the next chapter, the dynamics of airplanes will be described in terms of the rigid-body equations of motion which we just derived. Figure 2.1 gives a graphical representation of the external forces and moments (Fx , Fy , Fz , L, M, and N), and the linear and rotational velocity components of the airplane (u, v, w, p, q, and r) in relation to its body-xed reference frame. The orientation of the body-axes in this gure conforms to the denition from section A.7.1 of appendix A. The gure also shows the graphical representation of the airspeed vector V, the angle of attack , and the sideslip angle , which dene the orientation of the ight-path axes in relation to the aircrafts body-axes.
XB-axis F,u x
L, r
c.g. Fy , v F,w z M, q N, p Z B-axis
YB -axis
Figure 2.1: Orientation of the linear and angular velocity components, external forces and moments, angle of attack, and sideslip angle in relation to the body-xed reference frame of the aircraft.
18
2.2
Expressing translational motions in ight-path axes
Although it seems logical to express translational velocities in terms of the body-axes velocity components u, v, and w, it is often more convenient to use the true airspeed V, angle of attack , and sideslip angle instead when considering aerodynamic problems. The latter variables express the translational motions in relation to the ight-path axes (the airspeed vector V coincides with the ight-path or wind-axis XW , while and dene the orientation of the ight-path reference frame FW in relation to the body-xed reference frame FB ; see section A.7.1 of appendix A).
2.2.1
Advantages of relating translations to ight-path axes
Since V, , and can be expressed in terms of u, v, and w, and vice-versa, it is possible to 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 forces and moments in terms of V, , and . For simulation purposes, we want the linear force equations to be re-written as a set of explicit ordinary differential equations (ODEs), moving all time-derivatives to one side of the equations and all other terms to the other side. This may be difcult to achieve, since the aerodynamic forces and moments may depend on the time-derivatives of the angle of attack and sideslip angle, while and themselves will not not available until after the force equations have been evaluated. In practice it is often possible to assume a linear relationship between these time-derivatives and the aerodynamic forces, which makes it relatively easy to convert the force equations to explicit ODEs (this has been demonstrated in section 3.4 for the Beaver model), provided the translational equations are written in terms of and instead of v and w. 2. A higher accuracy of the numerical computations can be achieved by relating the translational motions to the ight-path axes. For agile aircraft having an upper limit of the pitch rate q of about 2 rad s1 , and ying at high airspeeds (e.g. V = 600 m s1 ), 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 acceleration due to the external force along the ZB -axis (primarily gravity and aerodynamic lift) has an upper-limit of only a few gs. Hence, articial accelerations of much greater magnitude than the actual physical accelerations of the aircraft are introduced in the equations for u, v, and w, because of the high rotation rates of the body-axes. In practice this means less favourable computer scaling and hence poorer accuracy for a given computer precision if the simulation model is based upon body-axes velocity components [16]. Because of said advantages, we will later treat V, , and as state variables in the resulting nonlinear state-space model of the aircraft, while u, v, and w (and their time-derivatives) will be treated as output variables. The rst three variables are required to solve the equations of motion; the other ones provide useful additional information, that allows us to determine e.g. airplane drift due to wind and atmospheric turbulence.
2.2. Expressing translational motions in ight-path axes
19
-Z a L
V -Xa
Figure 2.2: Relationship between the aerodynamic forces in ight-path and body-axes
2.2.2
Expressing forces and velocities in terms of ight-path axes
Transforming the forces and velocities from body to ight-path axes is quite straightforward (see ref.[14] for a detailed description). From gure 2.1, we can observe that the body-axes velocity components are equal to: u cos cos v = V sin (2.31) w sin cos Hence: V = u2 + v2 + w2 w u (2.32) (2.33) v u2
= arctan = arctan
+ w2
(2.34)
20
Aerodynamic forces and moments are commonly expressed in terms of aerodynamic lift L, drag D, and sideforce Y, which are aligned along the ight-path axes ZW (in negative direction, i.e. upwards), XW , and YW , respectively. However, for simulation purposes, it is more convenient to use the body-axes force-components Xa , Ya , and Za instead. The relationship between these variables has been shown in gure 2.2. The body-axes components can be derived from the ight-path axes components by means of the following axis-transformation: D cos 0 sin Xa Ya = 01 0 Y (2.35) sin 0 cos Za L Notice the minus sign for the aerodynamic force component along the ZB -axis, which is 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: uu + vv + ww V= (2.36) V Substituting the denitions (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 rotational rates p, q, and r turn out to be identically zero, which becomes obvious after again substituting equation (2.31) for u, v, and w. The resulting equation becomes: 1 (2.38) V= Fx cos cos + Fy sin + Fz sin cos m
2.2.4
Derivation of the -equation
Differentiating equation (2.33) with respect to the time yields: uw uw = 2 u + w2 Using equation (2.31) we can re-write the denominator of this equation: u2 + w2 = V 2 v2 = V 2 (1 sin2 ) = V 2 cos2
(2.39) (2.40)
Substituting the u and w-relations from equation (2.31) and equation (2.40) into equation (2.39) yields: w cos u sin = (2.41) V cos Substituting equations (2.28) for u and w, and rewriting terms yields: 1 1 = ( Fx sin + Fz cos ) + pv cos + qu cos + qw sin rv sin V cos m (2.42) Using equations (2.31) for u, v, and w, we nd: 1 1 = ( Fx sin + Fz cos ) + q ( p cos + r sin ) tan V cos m
(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 ( u u + w w ) = 2 u2 + w2 V From equations (2.31) the following relations can be derived: u2 + w2 = V 2 cos2 uv = V 2 sin cos cos vw = V 2 sin cos sin These values substituted in equation (2.44) yield: 1 = (u cos sin + v cos w sin sin ) V Substituting equations (2.28) for u and w yields: 1 = V 1 ( Fx cos sin + Fy cos Fz sin sin ) + qw cos sin + m (2.47) (2.46) (2.45) (2.44)
rv cos sin + pw cos ru cos + pv sin sin qu sin sin

If we substitute equations (2.31), many terms can be cancelled and we nd: 1 = V 1 ( Fx cos sin + Fy cos Fz sin sin ) + p sin r cos m
(2.48)
2.3
Equations of motion in nonsteady atmosphere
The equations of motion are valid only if the body-axes velocity components are measured with respect to a non-rotating system of reference axes having a constant translational 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 xed to the surrounding atmosphere as 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 aircrafts velocity with respect to the surrounding atmosphere. If the wind velocity vector Vw is not constant during the time-interval over which the motions of the aircraft are studied it is not possible to x the reference frame to the surrounding atmosphere. This happens for instance during the approach and landing of an aircraft, because the wind velocity changes with altitude. Again using assumptions 3 and 4 of section 2.1.4, the most obvious choice of the reference frame in this case turns out to be the Earth-xed reference frame FE [19]. Let Ve be the velocity with respect to the Earth, V a the velocity with respect to the surrounding atmosphere, and Vw the wind velocity with respect to the Earth. Then we can write: Ve = V a + Vw (2.49)
22
or: ue = u a + uw ve = v a + vw we = w a + ww where ue , ve , and we are the components of V, u a , v a , and wa are the components of V a , and uw , vw , and ww are the components of Vw , all measured along the body-axes of the aircraft. The force equations now become: F=m Ve + Ve t (2.51) (2.50)
Rewriting equation (2.51) yields: Ve F = Ve t m For the individual components along the body-axes we thus nd: ue = (2.52)
Fx qwe + rve m Fy ve = + pwe rue (2.53) m Fz we = pve + que m In order to compute the aerodynamic forces and moments, it is necessary to know the values of Va (the true airspeed), , and .1 In a manner analogous to the derivation of V, , and in section 2.2, we can nd expressions for the time-derivatives of Va , a , and a : 1 Fx cos cos + Fy sin + Fz sin cos + Va = m (qww rvw + uw ) cos cos + ( pww ruw vw ) sin + ( pvw quw + ww ) sin cos a = 1 V cos 1 ( Fx sin + Fz cos ) + m (2.54)
( pvw quw + ww ) cos + (qww rvw uw ) sin +
+ q ( p cos + r sin ) tan

1 1 a = ( Fx cos sin + Fy cos Fz sin sin ) + V m + (qww rvw + uw ) cos sin + ( pww ruw vw ) cos + + ( pvw quw + ww ) sin sin + p sin r cos
(2.55)
(2.56)
The subscript a has been used here for reasons of clarity only, allowing us to make a clear distinction between the equations for a steady atmosphere and the equations
1 Notice
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 to the surrounding atmosphere, these subscripts will be omitted again in the remainder of this section. These expressions differ from equations (2.38), (2.43), and (2.48) in that they include additional terms that depend on the wind velocity components and their timederivatives. These terms can be expressed in terms of corrections of the external force components along the aircrafts body-axes, Fx , Fy , and Fz , This means that we can apply equations (2.38), (2.43), and (2.48) for steady as well as nonsteady atmosphere, as long as the force components are properly corrected for the wind, if necessary. These corrections 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 equations of motion it is also necessary to know the attitude of the aircraft relatively to the Earth, because some contributions to the external forces and moments depend upon those quantities. We also need to know the altitude of the aircraft, because the air pressure, temperature, and density change with altitude, affecting both the aerodynamic and propulsive forces and moments. And nally, we want to be able to track the ight 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 consecutive rotations, the Euler angles , , and , see gure A.2 from appendix A. As shown in section A.7.3, the rotations can be expressed by three transformation matrices T , T , and T . It is possible to express the total angular velocity of the aircraft expressed in terms of the derivatives with respect to time of the Euler angles:
T
p 1 0 q = 0 + 0 cos r 0 0 sin 1 0 0 + 0 cos sin 0 sin cos

T
0 sin cos cos 0 sin
0 + 0 0 sin 0 0 1 0 0 cos
T
(2.57)
This can be written as: p 1 0 sin q = 0 cos sin cos = TR r 0 sin cos cos
(2.58)
where TR is the matrix that transforms angular velocities in the Earth-xed axis system into body-axes angular velocities. Consequently, the time-derivatives of the Euler angles can be found by pre-multiplying equation (2.58) with TR 1 . This yields
24
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-xed reference frame is given by the coordinates xe , ye , and ze . To nd these coordinates, we need to resolve the body-axis velocity vector in the Earth-bound reference system FE : ue xe ye = TBE ve (2.60) we ze where TBE = TBV = TV B 1 is the transformation matrix from FB to FE , see the denition 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 coordinate ze . The relationship between the time-derivatives of H and ze is simple: H = ze Notice that the positive ZE -axis points downwards. The state equations (2.59) have the advantage of using physically meaningful variables, and they express the airplanes attitude using the minimum number of three rst-order differential equations. However, it should be noted that these equations also have some signicant 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 of occurrence, this may still cause signicant computational errors in the vicinity of this singularity. 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 may make it difcult to determine the attitude uniquely. And nally, the equations are linear 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 orientation of a rotated coordinate frame. These methods, which involve four, ve, or even six variables instead of the three Euler angles, aim to avoid the singularity of the Euler angle representation, and maximize the speed of computer processing in navigation applications. The most common of these methods is the so-called quaternion representation, which uses four variables. For a detailed discussion about this method, refer to 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.62)
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 equations that were derived from the basic force and moment equations: 1 V = Fx cos cos + Fy sin + Fz sin cos m 1 1 = ( Fx sin + Fz cos ) + q ( p cos + r sin ) tan V cos m 1 1 = ( Fx cos sin + Fy cos Fz sin sin ) + p sin r cos V m p = Ppp p2 + Ppq pq + Ppr pr + Pqq q2 + Pqr qr + Prr r2 + Pl L + Pm M + Pn N + p q = Q pp p2 + Q pq pq + Q pr pr + Qqq q2 + Qqr qr + Qrr r2 + Ql L + Qm M + Qn N + q r = R pp p2 + R pq pq + R pr pr + Rqq q2 + Rqr qr + Rrr r2 + Rl L + Rm M + Rn N + r (2.63) The variables V, , , p, q, and r, which represent the linear and angular velocities of the aircraft can be regarded as the state variables from this model. The state-space model would already be complete if the body-axes components of the external forces and moments could be treated as independent input variables, but unfortunately, the external forces and moments themselves depend on the motion variables of the aircraft. Because of this, the state variables need to be coupled back into the force and moments equations. As explained in section 2.4, the attitude of the airplane and its altitude are needed to determine the gravitational, aerodynamical, and propulsive forces and moments. This means that the model needs to be extended with the equations for the Euler angles and the altitude. The aircrafts horizontal coordinates relative to the surface of the Earth are not needed to solve the equations of motion, but they are included for practical purposes. This yields an additional six state equations: = q sin + r cos cos = q cos r sin
= p + (q sin + r cos ) tan = p + sin 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 H = ue sin (ve sin + we cos ) cos (2.64) with new state variables , , , xe , ye , and H. These twelve state variables are combined in the state vector x: x = [ V p q r xe ye H ] T and the resulting equations are combined in a single vector equation: x = f (x, Ftot (t), Mtot (t)) (2.66) (2.65)
26
If we also collect any external control inputs in the input vector u, and any external disturbances in the vector v, we can express the external forces and moments as nonlinear functions of x(t), u(t), and v(t). In addition, the forces and moments may possibly depend directly on time itself (e.g. the fuel-burn decreases the weight of the airplane in time). Hence: Ftot (t) = g1 (x(t), u(t), v(t), t) Mtot (t) = g2 (x(t), u(t), v(t), t) 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 but also on its time-derivative x, which causes equation (2.68) to become implicit, as x now appears on both sides of the equation: x ( t ) = f ( x ( t ), x ( t ), u ( t ), v ( t ), t ) 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 nd a numerical solution for this system, especially if f2 is a linear function. The practical consequences of this will be outlined for the dynamic model of the Beaver aircraft in section 3.4. The resulting state-space model can be used for any rigid body, and in particular any rigid vehicle. Based on this model, we can develop dynamic simulation models of aircraft, missiles, spacecraft, road-vehicles, or ships, by identifying the relevant control inputs and disturbances, and by further developing the equations (2.67) for the forces and moments. In the next chapter, a dynamic model of the DeHavilland Beaver airplane will be built on this foundation. (2.69) (2.67)
Chapter 3
The aircraft model

Having determined the basic equations of motion, we can now develop a simulation model of the complete aircraft. This chapter will rst outline the general structure of the overall simulation model, then focus on building the aircraft dynamics model by identifying the individual contributions to the forces and moments and by building the necessary airdata equations. Also, several additional observation variables will be included, in order to make the model suitable for a wide range of applications in ight simulation, ight dynamics analysis, and ight control system design.
3.1
General structure of the ight simulation model
Figure 3.1 shows the general closed-loop model of an automatically controlled aircraft that is affected by external disturbances. Most elements in this model are hardware related: the airframe and powerplant determine the aircraft dynamics, the ight control computer setup determines the discretization effects and computational delays, the actuator and sensor hardware determine which signals can be observed and what control inputs are physically possible, and the pilot interface limits the ways in which the pilot can interact with the control of the airplane and the autopilot. The mode-controller logic and the control laws of the ight control system are typically dened in software. This chapter will focus on building the aircraft dynamics model, which obviously forms the core of gure 3.1. The next chapter deals with external atmospheric disturbances, chapter 5 will include some relevant sensor and actuator models (focusing on the simulation of radio-navigation signals in particular), and chapter 14 will provide a detailed example of an automatic ight control system and its mode-controller for the Beaver aircraft.
3.2
The nonlinear aircraft dynamics
Figure 3.2 gives a graphical overview of the nonlinear rigid body dynamics of an aircraft. Together, all elements from this gure represent the nonlinear state-space system from equation (2.66). The state variables are obtained by integrating their time-derivatives with respect to time, taking into account the initial value of the state
28
Chapter 3. The aircraft model
External disturbances
Actuator dynamics
Aircraft dynamics
Sensor dynamics
Discretization effects, computational delay
AFCS control laws
Mode controller
Reference signals
h interface
Pilot-
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 variables are coupled back into the force and moment equations and the equations of motion themselves. All forces and moments must be expressed in components along the body-axes of the vehicle (denoted by the superscript B). Forces and moments which are expressed with respect to other reference frames must be transformed to body-axes components by pre-multiplying the force and moment vectors with the appropriate transformation matrix. In the gure, this is illustrated for the aerodynamic forces and moments, which are transferred from ight-path axes (superscript W) to body-axes, and for the gravitational forces, which are transferred from Earth axes (superscript E) to body-axes. Figure 3.2 forms the basis for the development of the 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 different contributions to the external forces and moments acting upon the rigid body. Obviously 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 inuence of nonsteady atmosphere. This comprises an in-ight model of a conventional aircraft. Other contributions can easily be included to the model, e.g. ground forces during taxiing, or a ground-effect model for aircraft that y close to the ground. Figure 3.2 shows the individual contributions to the total external forces and moments; the dashed box represents additional factors that are not taken into account in this report.
3.3.1
Aerodynamic Forces & Moments
The aerodynamic forces and moments depend upon the ight condition, dened by the state vector x and the aircraft conguration (i.e. the position of movable elements
uaero
- Aerodynamics -
FW aero MW aero
- T W B
FB aero MB aero
u prop
-
FB prop MB prop
B Ftot
Propulsion
3.3. External forces and moments
FE grav
Gravity
- T EB
FB grav
B Mtot
Equations of Motion
dt
x -
x = f(x, Ftot , Mtot )
u j wind
-
qdyn ,
Wind Corrections
B Fwind
M, ...
-
Atmosphere/ Airdata
Figure 3.2: Block-diagram of the general rigid body dynamics
29
30
on the airplane). For the DHC-2 Beaver aircraft, a sophisticated aerodynamic model has been determined from ight tests in 1988 [34]. This model expresses the aerodynamic forces and moments along the aircrafts body-axes in terms of polynomial functions of the aircraft states, the time-derivative of the state vector, and the ight control inputs: Faero = d p1 (x, x, uaero ) (3.1) where Faero is a vector of aerodynamic forces and moments, and p1 is a polynomial vector-function that yields non-dimensional force and moment coefcients. The input vector uaero gathers the positions of the elevator, ailerons, and rudder (the primary ight controls for the Beaver), and aps (the secondary ight controls). For the Beaver model, the x-term is linear and only takes into account the direct contribu to the aerodynamic side-force Ya . The pre-multiplication with the diagonaltion of matrix d converts these non-dimensional coefcients to dimensional forces and moments; d equals: d = qdyn S 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 V 2 , see section 3.5). 2 The polynomial functions from p1 , describing the aerodynamic force and moment coefcients in the body-xed reference frame are: qc CXa = CX0 + CX + CX2 2 + CX3 3 + CXq + CXr r + CX f + CX f f f V pb rb b CYa = CY0 + CY + CYp + CYr + CYa a + CYr r + CYr r + CY 2V 2V 2V qc CZa = CZ0 + CZ + CZ3 3 + CZq + CZe e + CZ 2 e 2 + CZ f + CZ f f f e V rb pb + Clr + Cla a + Clr r + Cla a Cla = Cl0 + Cl + Cl p 2V 2V rb qc + Cm f f Cma = Cm0 + Cm + Cm2 2 + Cmq + Cme e + Cm2 2 + Cmr V 2V rb qc pb Cna = Cn0 + Cn + Cn p + Cnr + Cna a + Cnr r + Cnq + Cn3 3 2V 2V V (3.3) The stability and control coefcients from these polynomial equations are constant for the entire ight-envelope of the Beaver; table B.3 in appendix B lists their values. Notice the cross-coupling between lateral motions and longitudinal forces and moments. For example, the gyroscopical effect of the propeller can be recognized in qc rb the factors Cmr 2V and Cnq V . 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 the gyroscopical precession of the propeller; Cnq is positive, which means that pitchingup also causes the aircraft to yaw to the right. This is consistent with a clockwiserotating propeller, which indeed corresponds to the lay-out of the Beaver engine. Also notice the contribution of to the aerodynamic side-force Ya , which explains why the time-derivative x appears on the right-hand side of the general polynomial equation (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 model shown here, which makes it easy to re-write the state equations as a set of explicit ODEs. This will be outlined for the Beaver aircraft in section 3.4. Table B.5 in appendix 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 the center 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 aircraft under consideration. For a piston-engined aircraft like the Beaver, the primary engine control inputs are the engine speed n, and the manifold pressure pz , which directly affect the engine power P. The engine power also varies with altitude due to changes in air-density. If the propeller is represented as an ideal pulling disc, it is possible to express changes in engine power and airspeed in terms of variations of the non-dimensional pressure increase in the propeller slipstream dpt [34]: dpt pt 1 2 2 V
= C1 + C2
P
1 3 2 V
(3.4)
The constants C1 and C2 have been given in ref [34]: C1 = 0.08696, and C2 = 191.18. P is measured in [kW kg1 s3 ]. For the Beaver aircraft, the engine power in [kW ] 1 V 3 can be calculated with the following expression1 : P = 0.7355
2
326.5 + (0.00412 ( pz + 7.4)(n + 2010) + + (n + 2010) + (408.0 0.0965 n) 1.0

0 (3.5)
where: pz n 0 = = = = manifold pressure [ Hg], engine speed [RPM], air-density [kg m3 ], air-density at sea level = 1.225 [kg m3 ].
The engine forces and moments, which include propeller slipstream effects, are written as polynomial functions of x and dpt in a similar way as the aerodynamic model [34]: Fprop = d p2 (x, dpt) (3.6) where the subscript prop denotes propulsive effects. The vector function p2 contains the polynomials for the non-dimensional propulsive force and moment coefcients;
factor 0.7355 converts from continental horse-power to kilowatt; this factor was used in several other software packages from the Faculty of Aerospace Engineering of Delft University of Technology (DUT), including the software that was used to control the engineering ight simulator of the Faculty during the 1980s and early 1990s. However, according to ref.[34], the conversion should be from brake horse power to kilowatt, which would require a factor of 0.7457 instead. Since it is not known whether ref.[34] or the software is correct, it was decided not to correct the discrepancy, in order to ensure that simulations created with the FDC toolbox could be directly compared to those obtained by other programs at DUT. If the conversion factor in equation (3.5) is incorrect, the engine power is in fact underestimated by 1.4%, which is deemed acceptable.
1 The
32
the actual forces and moments are again obtained by pre-multiplication with the vector d, see equation (3.2). The polynomial functions gathered in p2 , which describe the propulsive force and moment coefcients in the body-xed reference frame are: CX p = CXdpt dpt + CX dpt2 dpt2 CYp = 0 CZp = CZdpt dpt Cl p = Cl2 dpt 2 dpt Cm p = Cmdpt dpt Cn p = Cndpt3 dpt3 (3.7)
Table B.4 in appendix B lists the values of the stability and control coefcients from these polynomial equations. These coefcients are constant over the entire ight envelope of the Beaver.
3.3.3
Gravitational forces
The weight of the aircraft equals the aircrafts mass m times the local acceleration of gravity g. It is directed along the positive ZV axis (see the denition of the vehiclecentered vertical reference system FV in section A.7.1 of appendix A): V 0 V Fgrav = WV = mgV = mg 0 (3.8) 1 In this equation, the superscript V has been used to denote the applied reference frame FV . Using the transformation:
B V Fgrav = TV B Fgrav
(3.9)
where the transformation matrix is TV B dened according to equation (A.4) from appendix A, we nd the following equation for the gravity force components along the aircrafts body-axes: Xgr sin Fgrav = Ygr = mg cos sin (3.10) Zgr cos cos In this equation, g is the magnitude of the local acceleration of gravity, is the pitch angle of the vehicle, and is the roll angle of the vehicle. The superscript B has been omitted here for reasons of brevity. Obviously, the attitude of the vehicle, expressed in terms of the Euler angles and needs to be known to be able to determine the weight components along the body-axes; see section A.7.3 for the relevant denitions.
3.3.4
Forces and moments due to nonsteady atmosphere
In section 2.3 it was shown that corrections to the external force components along the aircrafts body-axes are needed whenever the aircraft is ying in nonsteady at-
3.4. Converting the implicit state equations to explicit equations
33
mosphere. These corrections are equal to: uw + qww rvw Xw Fwind = Yw = m vw pww + ruw ww + pvw quw Zw
(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 depend upon time-derivatives of state variables. This causes the general state equations (2.66) to become implicit, which results in the equation (2.69). In the case of the Beaver model, the aerodynamic sideforce was shown to be dependent on the time-derivative of the sideslip angle: rb b pb + CYr + CYa a + CYr r + CYr r + CY (3.12) 2V 2V 2V Notice the last term in this equation. The time-derivative of the sideslip angle was given by equation (2.48): CYa = CY0 + CY + CYp 1 Fx cos sin + Fy cos Fz sin sin + p sin r cos = (3.13) Vm which shows that depends on the sideforce Fy , which includes the aerodynamic contribution Ya = 1 V 2 S CYa . As a consequence, the time-derivative appears on 2 both sides of equation (3.13). Using these raw relations in a simulation model would result in a so-called algebraic loop. 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 increased number of computations would severely slow down simulations. A better solution is to search for an algebraic solution instead. In this particular case, it is easy to re-write the -equation such that it becomes to the side-force Fy can be written as a explicit. First of all, the contribution of separate term: =
1 b Fx cos sin + Fy cos Fz sin sin + 1 V 2 S CY 2V cos 2 Vm
+
(3.14)
+ p sin r 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: Sb 1 CY cos = 4m 1 = (3.15) Fx cos sin + Fy cos Fz sin sin + p sin r cos Vm Based upon these equations the following calculation sequence can be used in the simulation model: 1. compute the external forces and moments as usual, but neglect the contribution of to the aerodynamic side-force for the time being,
34
Chapter 3. The aircraft model 2. substitute the thus obtained forces and moments into the general equation, , and to obtain the value 3. compute the true value of with the expression = 1
Sb 4m CY
cos
Since the last step corrects the originally computed value to obtain the actual value of , the multiplication factor from step 3 represents a correction term. The correction is aircraft-dependent because it contains CY , whereas the equation for itself is applicable to all aircraft. Thus, the computation scheme allows us to separate the aircraft-dependent from the aircraft-independent terms, which is desirable in 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 terms of non-dimensional force coefcients, but to solve the equations of motion, we need to know their actual values. For the Beaver aircraft, this requires knowledge of the dynamic pressure. Other aircraft models often also take into account compressibility effects, which would require additional knowledge of the Mach number, and sometimes it may be necessary to account for scale-effects (e.g. in case of windtunnelderived models) which would require knowledge of the Reynolds number as well. These variables are closely related to the properties of the atmosphere, and the airspeed and altitude of the aircraft. Several related variables are needed to compare simulations with ight test measurements or windtunnel experiments; these variables also play an important role for aircraft instrumentation. In this report, these variables are referred to as atmosphere and airdata variables, or shortly airdata variables. Several airdata equations have been included in the aircraft model to allow the 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 (see for 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 where: h T0 = altitude above sea level [m], = air temperature at sea level = 288.15 [K], = temperature gradient in troposphere = 0.0065 [Km1 ]. (3.16)
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 T = (3.18) Ma
3.5. Atmosphere and airdata variables
35
where: R a = molar gas constant = 8314.32 [JK 1 kmol1 ], Ma = molecular weight of the air [kg kmol1 ]. Combining these equations and neglecting the altitude-dependency of the gravitational acceleration g yields: dps M a g0 = dh ps Ra T where: ps g0 = static air pressure, [Nm2 ], = gravitational acceleration at sea level = 9.80665 [ms2 ]. ps p0 g ln R
g R
(3.19)
To nd ps , equation (3.19) needs to be integrated, yielding: ln
T0 + h T0 T0 T
g R
(3.20)
This equation can be written as: ps = p0 h 1+ T0
(3.21)
R is the specic gas constant, which is dened as: R and: p0 = air pressure at sea level = 101325 [Nm2 ], 0 = air density at sea level = 1.225 [kg m3 ], M0 = molecular weight of the air at sea level = 28.9644 [kg kmol1 ]. Since the gravitational acceleration g was held constant during the integration of equation (3.19), this actually means that the geometrical altitude h in this equation must be replaced by the geopotential altitude H.1 In this report the slight distinction between 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 the remainder of the report to denote the altitude. Contrary to the pressure equation (3.21), where the acceleration g was assumed to be equal to g0 for all altitudes, the model does take into account changes in g with altitude for the computation of the aircrafts weight. The actual gravitational acceleration is then computed with the following equation, which is valid for a round Earth: g = g0 where: REarth = radius of the Earth = 6371020 [m]
1
R a (3.18) p0 = = 287.05 [JK 1 kg1 ] M0 0 T0
(3.22)
REarth REarth + h
(3.23)
The geopotential altitude H is dened as: H
h 0
g dh g0
36
The air density (in [kgm3 ]) is calculated from ps and T by means of the ideal gas law (3.18), which yields: ps Ma ps = (3.24) Ra T RT The aerodynamic and propulsive forces and moments that act upon the aircraft are functions of the dynamic pressure qdyn , which takes into account changes in airspeed and changes in air density: = qdyn 1 V 2 2 (3.25) This term originates from Bernoullis law, which states that the sum of the static pressure 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 is brought to a complete standstill (this pressure can be measured in the so-called stagnation 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 the Beaver. As a guideline, Bernoullis law is usually applied only for airspeeds up to 100 ms1 . For aircraft ying at higher airspeeds it is necessary to take into account the compressibility of the air, which causes the air density to vary from one location to the next. In this case, the energy law for adiabatic ow of an ideal gas is used [5]: p 1 2 + V = constant (3.27) 1 2
p where = Cv is the ratio of the specic heats of a gas with constant pressure (C p ) and constant volume (Cv ), respectively. For air, equals 1.4. It can be shown that the pressure and density of an isentropic ow are related as follows: ps = constant (3.28)
If we now dene the total conditions to be the pressure and density where the ow is brought to rest isentropically1 , we nd: pt = ps t
Tt T
(3.29)
Applying equation (3.27), the total pressure for a compressible airow is thus found to be: pt = ps 1 2 1+ V 2 ps
1
(3.30)
It is possible to re-write this relation using the Mach number M, which is dened as the ratio of the speed of the airow to the speed of sound: M= V a (3.31)
1 In an isentropic process, a gas is compressed and/or expanded gradually enough for the process to be reversible, which implies that its entropy does not change.
3.5. Atmosphere and airdata variables where V is the (local) airspeed and a is the speed of sound (in [ms1 ]): a= RT
37
(3.32)
The Mach number is an important property that appears in many of the isentropic ow equations; it is also used as main control variable for the velocity of jet aircraft at high altitudes. Substituting these relations in equation (3.30) yields: pt = ps 1 2 1+ M 2
1
(3.33)
Notice that equations (3.30) and (3.33) are only valid for Mach numbers smaller than one, as they are based on the assumption of isentropic behaviour. If the aircraft ies at 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 ow is governed by supersonic shock relations, which go beyond the scope of this report. For the Beaver aircraft it is not necessary to take into account these compressibility effects, although it can still be quite useful to know the value of the Mach number. For instance, if one wants to compare ight-test results with the simulations it is useful to compute the Mach-dependent impact pressure qc and total temperature Tt since those quantities can be measured in ight. The impact pressure is dened as the 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 Bernoullis equation (3.26), except in this case the compressibility of the ow is taken into account. It can be measured using a pitot static system that subtracts the static pressure from the 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 is brought to rest isentropically. This measured temperature is higher than the temperature that would be measured when the air is completely in rest (relative to the temperature sensor): Tt = T 1 + 1 2 M 2 (3.35)
Other important variables are the calibrated and equivalent airspeeds Vc and Ve , which are determined by the equations: Vc = 2 p0 1 0 = 0 qc 1+ p0 2qdyn 0
1
(3.36)
Ve = V
(3.37)
Equation (3.36) can be derived easily from equations (3.34) and (3.30), by substituting the conditions at sea level for and ps . This relation is often used to calibrate the airspeed indicators in the cockpit; the true airspeed differs from the indicated airspeed due to the calibration for sea level conditions, hence the terminology. The
38
equivalent airspeed does the same assuming that the airow is incompressible. Expression (3.37) is used to calibrate less sophisticated ight instruments that can be found in light aircraft that operate in airspeed regions where compressibility of the air is negligible. As explained earlier, it may also be necessary sometimes to take into account scale effects, 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. Often the Reynolds number is related to the mean aerodynamic chord c, which yields the non-dimensional value: Vc Rc = (3.38) It is also possible to use the Reynolds number per unit length (in [m1 ]), which equals: V Re = (3.39) In equations (3.38) and (3.39), is the coefcient of the dynamic viscosity, which can be calculated with the equation of Sutherland: 1.458 106 T 2 = (3.40) T + 110.4 From all variables mentioned in this paragraph, only p, T, , and qdyn really must be calculated in order to be able to solve the equations of motion for the Beaver airplane. However, the other airdata (-related) variables may be useful for many analytical purposes and some of them will be needed to solve equations of motion when a different aerodynamic model that takes into account compressibility and/or scale effects would be used instead. Although the current list of atmosphere and airdata equations is quite comprehensive, it is by no means complete: expanding the ight-envelope beyond the troposphere (i.e. to altitudes above 11,000 meters) and beyond the speed of sound will require additional modications to the equations for pressure, density, and temperature. For more information, refer to ref. [5] or other books about aircraft instrumentation.
3
3.6
Additional observation variables
In the previous paragraph we have obtained a list of state variables, time-derivatives of the state variables, forces and moments, atmospheric variables, and airdata variables. It is possible to enhance this list with a large number of additional output variables. Here we will include additional normalized kinematic accelerations, specic forces, body-axes velocity rates and some ight-path (-related) variables, but the list can 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 of the aircrafts acceleration along its body-axes. These body-axes velocity rates u, v,
3.6. Additional observation variables
39
and w are equal to: Fx qw + rv m Fy v = + pw ru m Fz pv + qu w = m u =
(3.41)
In section 2.2 it was explained that the true airspeed V, angle of attack , and sideslip angle were better suitable as state variables than the body-axes velocity components u, v, and w. This is why equations (3.41) have been implemented as additional output equations, rather than state equations.
3.6.2
Kinematic accelerations and specic forces
It is possible to calculate accelerations and outputs from accelerometers, which may be useful for post-ight analysis or required for certain ight control tasks. A typical example of the latter is a turn-coordination system that is based on a feedback-loop of the acceleration along the YB axis. Also, these signals may be useful for applications in the eld of manoeuvre load limiting. The aircraft model from the FDC-toolbox considers accelerations in the vehicles center of gravity only, but equations for positions outside the center of gravity can easily be included if necessary. See ref.[14] for the required transformations. The body-axis acceleration vector a can be expressed as: V +V a=V= t (3.42)
where is the rotational velocity vector of the aircraft. Expanding this equation into its components along the body-axes and substituting for u, v, and w see equation (3.41) yields: a x,k = ay,k az,k 1 Fx (u + qw rv) = g0 W Fy 1 = (v + ru pw) = g0 W 1 Fz = (w + pv qu) = g0 W
(3.43)
The difference between the kinematic accelerations and u, v, and w is the inclusion of additional angular and translational velocity cross-product terms. In addition, contrary to equations (3.41), the kinematic accelerations have been measured in units of 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 accelerations in the body-xed reference frame. The outputs of accelerometers which are oriented along the body-axes, and located in the vehicles center of gravity are equal to the kinematic body accelerations
40
minus the gravity terms: A x = a x,k + sin = ( Fx Xgr ) / W Ay = ay,k cos sin = ( Fy Ygr ) / W Az = az,k + cos cos = ( Fz Zgr ) / W (3.44)
A x , Ay , and Az are measured in units of g. These accelerations represent what would actually be felt by a pilot when he would be located at the aircrafts center of gravity; they are usually called specic forces.
3.6.3
Flight-path related variables
To determine the ight-path of the aircraft, it is useful to introduce some additional observation variables. First of all, the ight-path angle is computed, using the following expression: = arcsin H V (3.45)
This angle is, for instance, useful during approach simulations where it determines how much the aircraft deviates from the standard glide-path. The acceleration in the direction of the velocity vector V, measured in units of [g], is called the ight-path acceleration fpa. It is equal to: u2 + v2 + w2 V fpa = = (3.46) g0 g0 Other ight-path related variables are the azimuth angle and the bank angle , which are obtained with the following equations [30]: = + = arcsin sin sin(90 ) = arcsin sin cos
(3.47) (3.48)
See also the description of the ight-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 dynamics, described in section 2.5, by developing models for the aerodynamic, propulsive, and gravitational forces and moments, correcting the force factors for nonsteady atmosphere, and determining some atmosphere and airdata variables that are required to compute these forces and moments. All elements combined result in the mathematical model from gure 3.2. This model was enhanced with several useful output equations, including additional airdata parameters, acceleration quantities, and ight-path variables. The resulting system of equations completes the block Aircraft dynamics from gure 3.1; the other elements from that gure will be explored in the next chapters. The model comprises twelve states and 77 additional output variables (including some interim results from the computations, such as force and moment coefcients, 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 control surface deections, which affect the aerodynamic forces and moments, and the engine inputs, which affect the propulsive forces and moments. In addition, wind velocity components and rates enter the model as external disturbances; these signals are used to determine the force-corrections for nonsteady atmosphere. An overview of 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 ight-path in relation to the ground. Some basic models of wind and turbulence will be presented in a format that will allow easy adaptation in the S IMULINK environment. The wind velocity will be represented by deterministic functions, while the atmospheric turbulence will be modelled by means of stochastic functions. It is not intended to provide a comprehensive description of the entire atmosphere here, nor will this report provide complete and detailed derivations of the wind and turbulence models. Instead, the focus of this chapter is to present some useful models aimed at practical applications, such as the analysis and ne-tuning of ight control system performance under nonsteady atmospheric conditions. Examples of such tasks are the simulation of automatic approaches under varying wind conditions, the assessment of attitude controllers in turbulent weather, and the development of gust alleviation control laws to improve the ride quality or reduce structural loads in the airframe.
4.1
Deterministic disturbances
The velocity and direction of the mean wind with respect to the ground usually is not constant along the ight-path. This variation of the mean wind along the ight-path is called windshear.1 The inuence of windshear upon the motions of the aircraft is of particular importance during the nal approach and landing, and during take-off and initial climb. An idealized prole of the mean wind as a function of height above the ground has been shown in gure 4.1. Much more extreme wind proles in lower atmosphere have been recorded; some data from actual measurements in lower atmosphere can be found in ref.[1]. A very dangerous type of windshear is encountered in so-called microbursts: large pockets of air moving rapidly downwards to the ground in thunderstorms. An aircraft ying through a microburst can be faced with a sudden increase in headwind, followed by a severe downdraft that is immediately followed by a sudden increase in tailwind, all within a matter of seconds. Such conditions
1 In some textbooks the term windshear is used to denote the local variations of the wind and turbulence with respect to the ground. In this report turbulence will be considered separately.
44
Chapter 4. External atmospheric disturbances
500 450 400 350
H [m ]
300 250 200 150 100 50 0
0.5
1.5
2.5
Vw [ m/s ]
Figure 4.1: Wind prole for = 0.0065 Km1 and Vw 9.15 = 1 ms1
may exceed the aerodynamic and propulsive performance of airplanes, causing the aircraft 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, 1975 crash of Eastern Air Lines Flight 66 during nal approach to John F. Kennedy airport in New York. Figure 4.2 shows the reconstructed wind prole and the recorded ightpath of this airplane. Based on this data, numerical models of two-dimensional owpatterns for thunderstorms have been developed [11]; such models are often used for ight crew training in ightsimulators. Although this subject will not be explored in further detail in this report, it is useful to acknowledge the hazards of such extreme weather conditions, and to realize that the idealized wind model that will be presented next will not always be sufcient; for some purposes, it may be necessary to apply additional models, or even measurements of actual wind velocities during extreme weather conditions. However, that goes beyond the current scope of this report. The atmosphere model used in section 3.5 was based on the ICAO standard atmosphere model, which is characterized by a standard temperature lapse-rate = dT/dH = 0.0065 Km1 ; see for instance ref.[30] for more details. The following equations represent a typical idealized windspeed prole that is valid for this particular value of the temperature lapse-rate [1]: H 0.2545 0.4097 1.3470 Vw = 2.86585 Vw9.15 Vw = Vw 9.15
(0 < h < 300m) (h 300m)
(4.1)
Vw 9.15 is the windspeed at an altitude of 9.15 m (approximately 30 ft, which is a commonly used reference height for meteorological experiments). The wind prole in
4.1. Deterministic disturbances
45
250
25 sec 30
200
35
Height [m]
100
pe
20:05 UTC 00 sec
Outburst
50
05
10
0
-3000 -2000
11.4 sec: first ground contact
Se aw
ide
slo
ind
Gl
55
fro
-1000
50
nt
Runway
150
40
Downburst
Distance from threshold [m]
Figure 4.2: Microburst wind pattern that caused the crash of Eastern ight 66
gure 4.1 is based upon a value Vw 9.15 = 1 ms1 . Ref.[1] presents some alternative wind proles, which are typical for other values of the temperature lapse rate. In sections 2.3 and 3.3.4, we described how the inuence of the wind on the motions of the airplane can be expressed in terms of correction terms for the external force components in the body-xed reference frame. If we know the wind velocity relative to the Earth, we can obtain the components of the wind along the aircrafts body-axes using the following axes transformation:
B E Vw = TE B Vw
(4.2)
where Vw represents the wind vector, the superscript B represents the aircrafts body axes, and the superscript E represents the Earth axes. TE B is the transformation matrix from Earth to body axes, which involves the three consecutive Euler rotations shown in gure 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 appendix A. In practice, wind is usually not given in terms of velocity component along the Earth axes, but rather in terms of windspeed and wind direction. The rst represents the magnitude of the windspeed vector, and the latter represents the direction on the compass rose from where the wind emanates; for instance, northerly wind means that the wind is blowing from the north. This notation does not take into account vertical wind components, because such vertical windspeeds are often short-lived, whereas the horizontal wind pattern is usually much more steady.
46
If Vwhor is the horizontal wind velocity and w is the wind direction, the horizontal wind velocity components in the Earth axes are equal to:
E uw = Vwhor cos(w ) E vw = 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 positive when the wind is blowing upwards. Using that angle, the horizontal wind velocity is found to be: Vwhor = Vw cos w
E ww = Vw sin w
(4.5) (4.6)
In this generalized situation, the vertical wind velocity component can be non-zero: where the minus sign reects the fact that the ZE points downwards. Equations (4.3) to (4.6) can be used to model a steady wind pattern, while equation (4.1) can be used to describe the changing wind velocity in the Earths boundary layer. Notice however, that the horizontal wind direction w will normally also vary with height. The above given representation of the vertical wind component may be practicable for modelling microburst wind patterns like the one shown in gure 4.2, but for most other purposes the vertical windspeed can simply be neglected (i.e. w can be kept identical zero).
4.2
Stochastic disturbances
Atmospheric turbulence is often regarded to be a random process. This is actually a bit misleading, because the evolution of turbulent ows are governed by the general Navier-Stokes equations (a set of deterministic, nonlinear, coupled partial differential equations), even when the creation of an eddy out of an instability somewhere in the ow eld is a matter of chance [27]. However, the theory of stochastic processes does provide a convenient means to describe the atmospheric turbulence velocities for the types of simulation problems considered in this report (e.g. the assessment of handling characteristics of the airplane or the performance of automatic ight control systems).
4.2.1
Stochastic properties of atmospheric turbulence
Auto power density spectra form the basic elements of the stochastic turbulence model. In the literature, several sets of these spectra can be found. They all require the selection of intensity levels and scale lengths before they can be applied in simulations. In order to simplify the statistical equations as far as practicable, the stochastical processes describing atmospheric turbulence are usually assumed to have the following six restrictive characteristics [1, 27]: 1. Normality, which means that the probability density function of each turbulence velocity component is Gaussian. As a consequence of this assumption, the covariance matrix alone provides sufcient information for a complete statistical description of the atmospheric turbulence.
4.2. Stochastic disturbances
47
2. Stationarity, which deals with temporal properties of turbulence. If the statistical properties of a process are not affected by a shift in the time origin, this process is called stationary. 3. Taylors hypothesis of a frozen atmosphere, which implies that gust velocities are functions of the position in the atmosphere only. This hypothesis allows spatial correlation functions and frequencies to be related to correlation functions and frequencies in the time-domain. 4. Homogeneity, which deals with the spatial properties of turbulence. Turbulence may be called homogeneous if its statistical properties are not affected by a spatial translation of the reference frame. 5. Ergodicity, which means that time averages in the process are equal to corresponding ensemble averages. This condition follows from the previous assumptions of the turbulence being stationary and homogeneous. As a consequence, all required statistical properties related to a given set of atmospheric conditions can be determined from a single time history of sufcient length. 6. Isotropy, which means that the statistical properties are not changed by a rotation or a deection of the frame of reference. Complete isotropy implies homogeneity. Because of isotropy, the three mean-square velocity components and their scale lengths are equal: u 2 = v 2 = w 2 2 Lu = Lv = Lw L g (4.7)
Experimental data on atmospheric turbulence shows that these assumptions are not always satised [1, 27]. There is some evidence that atmospheric turbulence is not necessarily normal, and while the observed departures from a normal amplitude distribution are small, pilots seem to be quite sensitive to these effects. Actual atmospheric turbulence possesses what is sometimes called a patchy structure [1]. Taylors hypothesis seems to be valid as long as the aircrafts velocity is large relative to the encountered turbulence velocity. For this reason it is somewhat doubtful that the hypothesis is fully valid when simulating the nal approach and landing of S/VTOL aircraft, i.e. aircraft which can y at very low airspeeds, and which are able to take off and land vertically (Vertical Take-Off and Landing) or using only a very short runway (Short Take-Off and Landing). This includes the DeHavilland DHC-2 Beaver aircraft, which served as the example vehicle for the aircraft model from chapter 3. The assumptions of homogeneity and isotropy appear not to be very valid in the vicinity of the ground (i.e. within the Earths boundary layer). Near the ground, there are fairly rapid changes in turbulence velocity with altitude, induced by vertical windshear, which is closely related to the shape and roughness of the terrain. The assumption of stationarity is satised only over short periods of time during which the meteorological conditions remain reasonably constant, and is also affected by the shape and roughness of the ground surface. However, for many practical applications these six assumptions seem to be quite reasonable, which is why these simplications will all be maintained for the derivations in the next sections. It is always possible to enhance these models in the future, if
48
S() S(0)
A
1
S() S(0)
.1
.1
Dryden
.01
Dryden
.01
Von Krmn
Von Krmn
.1
10
.1
10
Lg
Lg
Figure 4.3: Von Krmn and Dryden spectra (A: longitudinal, B: lateral/vertical)
a more accurate description of the atmospheric turbulence is required, e.g. for detailed analysis of the nal approach and landing. Alternatively, it is also possible to insert actual measurements of atmospheric turbulence velocities into the simulation models.
4.2.2
Power spectra of atmospheric turbulence
Due to the simplications we have made in the previous section, it is possible to distinguish between two fundamental correlation functions: the correlation between velocities parallel to a connecting line between two points in space, and the correlation between velocities normal to this connecting line. The rst function is termed longitudinal correlation, the second lateral correlation. Several authors have obtained analytical power spectral density functions for the turbulence velocities, using measured data. The Von Krmn spectral density functions seem to best t the available theoretical and experimental data on atmospheric turbulence, particularly at higher spatial frequencies [27]. Analogous to the correlation functions, these spectra can also be divided in longitudinal and lateral functions. Applying those functions to the turbulence velocity components in the aircrafts body-axes yields: Sug ug () = 2u 2 Lu Svg vg () = v 2 Lv 1
(1 + (1.339 Lu )2 ) 6 1 + 8 (1.339Lv )2 3
11
(4.8) (4.9)
(4.10) 11 (1 + (1.339 Lw )2 ) 6 where Sug ug represents the longitudinal Von Krmn spectrum, while Svg vg and Swg wg are both instances of the lateral Von Krmn spectrum.1 The cross spectral density
1 Some textbooks may use a scaled version of these spectra, due to the application of a different def1 inition for the Fourier transform (the partition of the constant 2 may differ). However, an agreement on the correlation functions exists, because they originate from measured wind velocities.
Swg wg () = w 2 Lw
(1 + (1.339 Lv )2 ) 6 1 + 8 (1.339Lw )2 3
49
functions are zero in isotropic turbulence at any point in space. Although this approximation is not very valid at low altitudes, the cross covariances and hence, the cross power spectral densities are usually neglected [19]. The von Krmn spectra yield an asymptotic behaviour of S() 5/3 as approaches innity. This condition is imposed by the rate at which the most energetic eddies of turbulence loose their kinetic energy: this energy is not immediately lost to viscosity, but instead it is transferred to smaller eddies, which in turn transfer their energy to yet smaller eddies, and so on. A major drawback of the von Krmn spectral densities is that they are not rational functions of , which greatly complicates analysis and computations for any application. To overcome this problem, the simplied Dryden spectral density functions were introduced: 1 Sug ug () = 2u 2 Lu (4.11) 1 + (Lu )2 1 + 3(Lv )2 Svg vg () = v 2 Lv (4.12) (1 + (Lv )2 )2 1 + 3(Lw )2 Swg wg () = w 2 Lw (4.13) (1 + (Lw )2 )2 In gure 4.3 typical Dryden spectral density values have been compared with the Von Krmn functions. The most obvious difference is the asymptotic behaviour at large values of the spatial frequency, the former having a slope of 5 and the 3 latter a slope of 2. Although the Von Krmn form seems to t the experimental data somewhat better, both representations yield much the same results for aircraft responses.
4.2.3
Filter design for atmospheric turbulence
For simulation purposes it would be practical to model atmospheric turbulence as white noise passing through a linear, rational forming lter, as shown in gure 4.4. The relationship between the auto-spectral density of the output signal y and the auto-spectral density of the input signal u of a linear lter can be written as: Syy ( ) = | Hyu ( )|2 Suu ( ) (4.14) where | Hyu ( )| denotes the amplitude response of the lter. If the input signal u is white noise, its spectral density satises: Suu ( ) = 1 so for white noise, relation (4.14) simplies to: Syy ( ) = | Hyu ( )|2
Unfiltered white noise Turbulence velocity (coloured noise')
(4.15) (4.16)
Linear Filter (Dryden)
Figure 4.4: Modelling atmospheric turbulence as ltered white noise
50
To apply these relations, the spatial spectral density functions of the turbulence velocities must be transformed to functions of the circular frequency . This can be done, because Taylors hypothesis implies that the circular frequency [rad s1 ] encountered at the aircrafts center of gravity is related directly to the spatial frequency [rad m1 ]: = V The resulting transformation is given by: 1 (4.18) S () V The extra term 1/V in the spectral density function is due to the fact that we now integrate over the time instead of over the distance in the Fourier transform. S( ) = The Dryden spectra were developed to approximate the von Krmn turbulence spectra 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. From the denitions of the Dryden spectra in equations (4.11) to (4.13) and relation (4.18) the following expressions are found: (4.17)
| Hug w1 ( )|2 = 2u 2 | Hvg w2 ( )| = v

2
Lu 1 V 1 + Lu V
1 + 3 Lv V 1 + Lv V
2 2 2 2 2 2
(4.19) (4.20)
2 Lv
| Hwg w3 ( )|2 = w 2
Lw 1 + 3 Lw V V 2 1 + Lw V
(4.21)
Solving equations (4.19) to (4.21) yields the following candidate functions for the frequency responses of the forming lters: Hug w1 ( ) = u Hvg w2 ( ) = v 2Lu 1 V 1 Lu j V L Lv 1 3 Vv j 2 V 1 Lv j V Lw 1 3 Lw j V 2 V Lw 1 V j (4.22) (4.23)
Hwg w3 ( ) = w
(4.24)
In these equations w1 , w2 , and w3 are independent white noise signals. Choosing the minus sign in the denominators would lead to unstable lters and hence should be rejected for physical reasons. And choosing the minus sign in the numerators leads to non-minimum phase systems, so we shall use positive signs in both the numerator and 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 subsequently be converted to state-space systems using the technique from section 6.4.2.
51
500
II
450 0.318
III
0.662
400
0.363
0.666
350
0.456
0.681
I
300 0 0.538 0.690
H [m]
250
0.151
0.565
0.688
0.235 200 0.245 0.508
0.560
0.670
150 0.210
0.620 0.382 0.506 0.145 0.229 0.307 0.068 0.123 0 0.0825 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8
100
50
wg Vw
9.15
[-]
Figure 4.5: Standard deviation of vertical turbulence velocity as a function of altitude, given dT for three different temperature lapse rates. Curve I: dH = 0.003 C m1 , curve II: dT dT 1 1 dH = 0.0065 C m , curve III: dH 0.01 C m .
This representation of the Dryden lters is very suitable for implementation in a simulation package like S IMULINK. If the white noise is approximated by a sequence of Gaussian distributed random numbers, it is easy to determine the time-trajectories of the turbulence velocity components. It is important to ensure that these random sequences are completely independent, which may not be obvious if the simulation software uses some initial starting value or seed for its random-generator. Better approximations of the Von Krmn turbulence spectra can be obtained by using a series of additional lead-lag networks, adding differentiating and integrating terms to the basic rst-order Dryden lters. Although the resulting equations will be more complicated than the Dryden equations, the resulting functions will still remain rational. 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 turbulence scale was represented by the scale-lengths Lu , Lv , and Lw , while the turbulence inten-
52
500 160 450 158 400 48 350 44 300 152
II
III
300
301
156
305
310
H [m ]
250
42
149
315
200
38
145
326
150
35
139
329
100
33
108
284
50 9 0 0
26 18 36 50
69
161
100
150
200
250
300
350
Lw [ m ]
Figure 4.6: Scale of (longitudinal) turbulence as a function of altitude, given for three dT different temperature lapse rates. Curve I: dH 0.005 C m1 , curve II: dT C m1 , curve III: dT 0.01 C m1 . 0.005 < dH < 0.01 dH
sity was represented by the standard deviations u , v , and w . If the turbulence eld is assumed to be isotropic, the scale lengths can all be replaced by a single length L g , and the standard deviation factors can be replaced by a single factor g , but this is not necessarily true for lower altitudes. The standard deviation of the vertical gust velocity w was experimentally found to be a function of height, atmospheric stability (as expressed by the temperature lapse rate), wind velocity, and a terrain factor. Since the latter inuence appears to be relatively small and the available data show a large scatter, the wind velocity as a function of the altitude, and the atmospheric stability appear to be the primary factors in determining turbulence intensity. With wind proles for the boundary layer of the atmosphere experimentally determined at different atmospheric stabilities (see e.g. gure 4.1 for the standard temperature lapse rate = 0.0065 K m1 ), the standard deviation of atmospheric turbulence turns out to be dependent on the windspeed at a certain reference height (usually 9.15 m, or 30 ft), and the temperature lapse rate . Figure 4.5 presents the standard deviation w in relation to the windspeed at 9.15 m, as a function of the height above the ground. The standard deviations for
53
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 v = = 2.5 0 m h < 15 m w w u v = = 1.25 0.001h 15 m h < 250 m (4.25) w w u v = =1 h > 250 m w w The scale of the turbulence is represented by the scale length L g , which also depends on the height above the ground and the temperature lapse rate. This has been shown in gure 4.6. It can be concluded that the structure of the turbulence at low altitudes can be described completely by examining the gures 4.5 and 4.6, given the windspeed at the reference height of 9.15 m and the temperature lapse-rate for the lower atmosphere. In practice, this is mainly relevant for the simulation of nal approach and landing. For higher altitudes, typical values are g = 1 m s1 and L g = 300 m.
Chapter 5
Radio-navigation, sensors, actuators

The previous chapters provide a solid basis for the construction of a simulation model of the aircraft and its working environment. This model allows us to extract all incorporated ight data without any restrictions, which is very useful for the analysis of ight dynamics and which allows us to build elaborate control systems. However, it should be noted that this transparency is actually an idealised representation of reality. In real ight, the relevant ight data is obtained through a limited array of sensors of limited accuracy and bandwidth. Some data can only be obtained indirectly; for instance, signals emitted by radio-navigation beacons on the ground are often used to derive the position of the airplane. Similarly, control inputs made by the (auto-) pilot do not represent the actual control surface deections, as there is a system 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 the ight-deck. This chapter will provide a starting point by presenting some additional models, primarily focussing on the mathematical representation of radio-navigation systems that are still commonly used for approach guidance and short-range navigation. At the end of the chapter, a short overview about additional sensor models, actuator models, and other navigation equipment will be given, thus identifying room 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 precision approaches to landing since the 1940s, and is still being used worldwide. Under certain circumstances it can provide guidance data of such integrity that fully coupled approaches and landings may be achieved. The system, which is ground-based, broadcasts very precise directional signals, providing a lateral and vertical path to the runway up to a distance of approximately 40 kilometers from the runway. The system comprises three distinct parts of on-ground equipment: (i) the localizer transmitter, which gives guidance in the horizontal plane, (ii) the glideslope (or glide-path) transmitter, which provides vertical guidance, and (iii) one, two, or three marker beacons situated on the approach line, which serve as checkpoints for the pilot to verify the distance to the runway (these markers are increasingly often being
56
Chapter 5. Radio-navigation, sensors, actuators
x loc xgs ygs

Landing direction Glideslope antenna
Runway
Localizer antenna
Figure 5.1: Positioning of ILS ground equipment

Aircraft track Join glide-path and commence final descent Alt. 1200 ft Alt. 2500 ft
Alt. 300 ft Glide-path transmitter

3000 ft
Outer marker Middle marker

3.9 N M
Runway Localizer transmitter
Figure 5.2: Lay-out of the approach path
replaced by the use of distance measuring equipment for direct distance-to-threshold measurements). In this section we will analyze the localizer and glideslope signals in 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 approach path. The localizer signal is emitted by an antenna, situated beyond the up-wind end of 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 predominates to the left-hand side of the approach path and 150 Hz predominates to the right, as seen from an aircraft ying on nal approach course. Figure 5.3 shows the required minimum 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 from the 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
35 o
10 o
17 N M
Runway Localizer transmitter
25 NM
10
Figure 5.3: Required coverage of localizer signal
35
Idealized glide-path (straight line)
Actual glide-path (hyperbola)
10
NM
Conical surface
Localizer plane
Glide-path antenna
Figure 5.4: Hyperbolic intersection of localizer and glideslope reference planes
58
Glideslope transmitter
8o
Localizer transmitter
10 NM
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 Hz is predominant above the desired glide-path and 150 Hz dominates below the glidepath. Due to the position of the glideslope antenna, the intersection of the localizer reference plane and the glideslope reference cone is actually a hyperbola which is located a small distance above the idealized straight glide-path. This is shown in gure 5.4. The minimum coverage of the glideslope signals, required by ICAO [2] is shown in gure 5.5. An ILS installation is said to belong to a certain performance category, representing the meteorological conditions under which it is to be used. These conditions have been summarized in gure 5.6. An ILS installation of category I is intended to provide guidance down to an altitude of 200 ft, a category II installation provides guidance down to 100 ft, and an installation of category III must provide guidance down to the runway surface. Only cat. III signals can be used for fully automatic landings. If the aircraft is making an approach under cat. I conditions, the pilot should either see the runway lights at an altitude of 200 ft or cancel the nal approach and go-around.1 The localizer and glideslope signals are received on board the aircraft and displayed in an appropriate form to the pilot. In addition, these signals may be fed directly to an automatic pilot for automatic localizer and glideslope tracking. The nominal ILS signals on board the aircraft are expressed in terms of the currents which are supplied to the pilots cockpit instrument. The magnitude of the localizer current iloc is proportional to the localizer deviation angle loc , shown in gures 5.7 and 5.8, while the glideslope current i gs is proportional to the glideslope deviation angle gs , shown in gure 5.8. From these gures,
altitude at which the runway lights should be visible is called the decision altitude or decision height. Some states and some individual airlines require larger values for the decision height than the numbers shown in gure 5.6. Local circumstances, such as special terrain features or radio-interference patterns, may also dictate higher minimums.
1 The

Decision height [ft]
59
Cat. I 200
-?
Cat. II 100
? -?
A Cat. III 0
? ?
B C
??
1000
800
600
400
200
50 0
Runway visual range [m]

Cat. I : Cat. II : Operation down to minima of 200 ft decision height and runway visual range of 800 m with a high probability of approach success Operation down to minima below 200 ft decision height and runway visual range of 800 m, and as low as 100 ft decision height and runway visual range of 400 m with a high probability of approach success Operation down to and along the surface of the runway, with external visual reference during the nal phase of the landing down to runway visual range minima of 200 m Operation to and along the surface of the runway and taxiways with visibility sufcient only for visual taxiing comparable to runway visual range in the order of 50 m Operation to and along the surface of the runway and taxiways without external visual reference
Cat. III A:
Cat. III B:
Cat. III C:
Figure 5.6: ILS performance categories
we can deduce that loc is dened as the the angle between the localizer reference plane and a vertical plane that passes through the localizer antenna, and gs is the angle between the reference glidepath and the line that connects the aircraft to the glideslope antenna. Since these angles are supposed to remain zero during the nal approach, we will call them localizer deviation angle and glideslope deviation angle, respectively. For the simulation of ILS-approaches, we will use the runway-xed reference frame FRW , which has been dened in appendix A. At time t = 0 the position of the aircrafts center of gravity coincides with the origin of the Earth-xed reference frame FE , hence, at that moment xe = 0, ye = 0, and H = H0 . The position of the origin ORW of the runway-xed reference frame is dened by the coordinates xt and yt , measured relatively to the Earth-xed reference frame, and the altitude of the runway above sea level, Ht (the index t denotes the runway threshold). The horizontal relation between FRW and FE has been shown in gure 5.7. The vertical relation has been depicted in gure 5.9, using the intermediate reference frames FE = OE XE YE ZE and FE = OE XE YE ZE to help interpret the spatial orientation. FE
60
has the same orientation as FE , but its origin has been moved to the projection point of ORW on the horizontal plane at sea level. FE has the same orientation as FE , except its origin has been shifted to runway level. Hence: xe = xe = xe xt xe = ye = ye yt (5.1) (5.2)
We can express the position of the aircraft relatively to the runway by introducing the coordinates x f and y f , measured in the runway-xed reference frame FRW (the index f denotes ight), and the height of the airplane above the runway threshold, H f . Observing gures 5.7, 5.8, and 5.9, and substituting equations 5.1 and 5.2, we nd the following transformations from FE to FRW :
( 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 the altitude of the airplane, and Ht is the elevation of the runway threshold. The latter two variables are both referenced to sea level. As can be seen from gure 5.7, loc can be computed from the coordinates x f and y f as follows:
xf = (5.6) dloc = y f loc and dloc are positive if the aircraft ies at the right-hand side of the localizer reference plane, heading toward the runway. The localizer current through the cockpit instrument equals: iloc = Sloc loc [A] (5.7) where Sloc is the sensitivity of the localizer system. According to ref.[2], Sloc has to satisfy the following equation: Sloc = 1.40 xloc [A rad1 ] (5.8) where xloc is the distance from the localizer antenna to the runway threshold, shown in gure 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 deection on the cockpit instrument [2]. The locations which provide a constant glideslope current lie on a cone, as shown in gure 5.4. The nominal glide path has an elevation angle gs which normally has a value between 2 and 4 . Obviously gs is negative since the aircraft will descend along the glide path. The magnitude of the glideslope current is proportional to the glideslope deviation angle gs [rad] (see gure 5.8): i gs = Sgs gs [A] (5.9) Full-scale deection on the cockpit instrument is again obtained at the limiting values of the glideslope current i gs = 150 A, see ref.[2]. Sgs is the sensitivity of the glideslope system, which equals: 625 Sgs = [A rad1 ] (5.10) |gs | Rloc = y f 2 + ( xloc x f )2 loc = arcsin dloc Rloc
61
xf (-) X" E
xloc Runway
RW XRW YRW Y" E
dloc = yf (+)
loc (+)
Localizer antenna
R loc
Position of aircrafts c.g. at t = 0 YE
XE
Figure 5.7: Localizer geometry and denition of XE , YE , XRW , and YRW -axes
Glideslope antenna
ygs(-)
gs(+)
dgs (+)
gs (-)
(+) gs
ZRW YRW
XRW
Runway
Rg
Hf
xgs (
+)
x f (yf (
+)
Figure 5.8: Glideslope geometry and denition of XRW , YRW , and ZRW -axes
62
Nominal glidepath
yf YRW y" e Hf xf
Runway
x" e
RW
Y" E
RW
H
X" E
Ht
Sea level
XRW
Y E X E Z , Z" , Z RW E E
No r
th
Figure 5.9: ILS geometry: expressing the aircraft position in the runway-xed reference frame and the intermediate (Earth-xed) coordinate systems FE and FE . Notice that the airplane in the picture is turning to the right after a missed approach; this position corresponds with positive values of the x f and y f coordinates!
From gure 5.8 it can be seen that the deviation angle gs can be computed from the coordinates x f and y f and the height above the runway, H f , using the following expressions: R gs =
( x gs x f )2 + (y f y gs )2
Hf R gs
(5.11) (5.12)
gs = gs + arctan
The distance from the aircraft to the nominal glideslope is: d gs = ( R gs tan gs + H f ) cos gs (5.13)
In these expressions gs and d gs are positive if the aircraft ies above the glideslope reference line. Notice that gs is always negative!
63
Performance category of the ILS system
Maximum deviation from nominal localizer sensitivity [%]
Maximum deviation of localizer runway reference plane from centerline at runway threshold [m]
I II
17 17
( 10 where practicable)
10.5 7.5
( 4.5 for new installations)
III
10
Table 5.1: Maximum permissible localizer steady-state errors
Performance category of the ILS system
Maximum deviation from nominal glideslope sensitivity [%]
Maximum deviation from nominal glideslope elevation angle [rad]
I II III
25 20 10
0.075 gs 0.075 gs 0.04 gs
Table 5.2: Maximum permissible glideslope steady-state errors
In order to be able to verify whether the aircraft ies in the glideslope coverage area (gure 5.5), we will also calculate the angle gs : gs = arcsin y f y gs R gs (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 ground equipment. For obvious reasons, these limits are most stringent for category III approaches. Tables 5.1 and 5.2 provide these limits for the localizer and glideslope transmitters, respectively. The nominal glide path must pass over the runway threshold at an altitude of 15 3 m. Due to interference effects caused by buildings, high voltage cables, etc., the actual ILS signals can become distorted in the spatial and time domains. To an ap-
64
proaching aircraft, these distortions appear as noise in the time-domain, superimposed on the nominal ILS signals. Based on available experimental data, localizer and glideslope noise may be approximated by stochastic signals which have rather simple power spectral density functions. Refs.[1] and [19] present power spectra for ILS noise, which are expressed in the same general form as the Dryden model for longitudinal atmospheric turbulence, see equation (4.11). The power spectral density function for localizer noise can be approximated by: 1 Sloc () = 2loc 2 Lloc where: loc = standard deviation of the localizer noise, Lloc = scale of the localizer noise, approximately 130 m = spatial frequency [rad m1 ] The power spectral density of the glide path noise appears to be similar to the localizer noise and may be approximated by: Sgs () = 2gs 2 L gs where: gs L gs = standard deviation of the glideslope noise, = scale of the glideslope noise, approximately 85 m = spatial frequency [rad m1 ] 1 1 + (L gs )2 A2 rad1 m (5.16) 1 1 + (Lloc )2 A2 rad1 m (5.15)
For atmospheric turbulence it is often assumed that the turbulence velocities are functions only of the position in the atmosphere (the frozen eld concept or Taylors hypothesis). This assumption can be made because aircraft usually y at large speeds compared to turbulence velocities. Using Taylors hypothesis for the ILS noise will probably introduce errors, especially for aircraft with very low nal approach speeds such as the Beaver. Still, this assumption makes it possible to convert the spatial power spectral density functions to temporal expressions in , which can be used for practical simulations. One should remember that the power spectral density functions are in any case approximations of the actual ILS noise, so if a really accurate representation of ILS noise is required for simulations (e.g. for assessing automatic cat. III landing systems) an actual calibration of the localizer and glideslope signals for the site in question should be used.
the expressions for ILS noise and atmospheric turbulence given in refs.[1] and [19] have an additional term in the denominator. The Dryden spectra from ref.[27] do not contain this term, due to a slightly different denition of the Fourier transform. In this report, the denition of the Dryden lters 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 denitions of the Fourier transform and the inverse Fourier transform used in ref.[27] are: X ( ) = F { x (t)} =
1 Note:
x (t)e jt dt;
x (t) = F 1 { X ( )} =
1 X ( )e jt d 2

loc ,gs
[]
65
15
gs (cat. I)
t. II, III)
gs (ca
10
loc (
cat
. I)
. at II, ) III
7.5
loc
(c
2.5
loc (cat. III)

-600 0 600 1050 Distance to threshold, [m] 7410
Figure 5.10: Maximum allowable ILS localizer and glideslope noise
With Taylors hypothesis it is possible to substitute = V. Then the ILS noise can be modelled as a white-noise signal which is sent through a linear forming lter in the same way as the derivations for atmospheric turbulence shown in gure 4.4. The resulting lters are: Hloc ( ) = loc Hgs ( ) = gs 1 2Lloc Lloc V 1+ V j 2L gs 1 V 1 + Lgs j V (5.17) (5.18)
Alternative shapes of the power spectral density functions for localizer and glideslope noise are given in ref.[22]. These expressions were based upon average power spectral density plots of beam noise, observed at several airports: Sloc = | Hloc ( )|2 = Sgs 25 (1.5 + j )2 (0.35 + j )2 (10 + j )2 15.9 = | Hgs ( )|2 = (0.25 + j )2 A2 rad1 s A2 rad1 s (5.19) (5.20)
The lters for these spectral density functions are: Hloc ( ) = 5 (1.5 + j ) (0.35 + j )(10 + j ) 3.9875 Hgs ( ) = 0.25 + j (5.21) (5.22)
Both ILS noise models have been implemented in the FDC toolbox. The maximum allowable values of the standard deviations of localizer and glideslope noise, according to ICAO standards [2] have been given in gure 5.10.
66
In addition to the ILS noise and steady-state errors, specic deterministic interference patterns may occur due to signal reections from aircraft in the vicinity of the glideslope and/or localizer transmitters. These disturbances may be quite severe and should be taken into account for the evaluation of automatic landing systems. It is possible to construct relatively simple models of these interference effects, but that goes beyond the scope of this report. Ref.[1] provides more details about these types of disturbances.
5.2
The VOR navigation system
Another radio-navigation system that is still commonly used today is the Very-high frequency Omnidirectional Radio-range (VOR) system. The system was developed after World War II, and has become the backbone of the air navigational system since the 1950s. It provided more accurate signals than the Low-Frequency beacons used 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 less prone to interference from thunderstorms. Distance measuring equipment (DME) was added to many VOR transmitters and receivers, allowing the distance between the station and the aircraft to be shown in the cockpit. The VOR system can be used for navigating between airports, following so-called airways, and it can also be used for nal approach guidance if the pilot ies along a reference VOR bearing to the runway, using a timed descent or an altitude-versus-distance table (the latter procedure requires both VOR and DME signals). However, unlike the ILS system, the VOR system is considered a non-precision landing aid, because it is not accurate enough and does not provide enough information to allow a pilot to land. Because of this, VOR/DME approaches require considerably 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 VOR ground station radiates a cardioid pattern that rotates 30 times per second, generating a 30 Hz sine wave at the output of the airborne VOR receiver. The ground station also radiates an omnidirectional signal which is modulated with a 30 Hz reference tone. The phase difference between the two 30 Hz tones is a function of the bearing of the aircraft, relatively to the VOR ground station. A position x can be obtained by using two or more VOR beacons, or by probing the signal from a single beacon at two different points in time and space. In practice, however, a position x is usually obtained by using bearing information from the VOR system and distance information from a DME station that is co-located with the VOR transmitter. More detailed technical information about these systems can be found in refs.[5], [7], and [23]; here we will mainly focus on the VOR navigation geometry. The geometry of the VOR system has been shown in gure 5.11. Simple generalaviation VOR systems make it possible for the pilot to y along a reference VOR
5.2. The VOR navigation system
67
CD QDR
VOR
VOR antenna
Reference VOR radial
xe
xVOR
XE (north)
YE (east) yVOR ye
Figure 5.11: Geometry of VOR navigation
radial, that can be entered using an Omni Bearing Selector. The reference bearing is called Course Datum (CD), while the bearing on which the aircraft is actually ying is denoted by QDR (a term used in radio telephony). The course deviation angle VOR , which is equal to the angle between the reference bearing and the actual bearing, is shown on the cockpit instrument; a typical value for a full-scale deection is VOR = 10 . The bearing information can also be coupled to an automatic control system, allowing the airplane to automatically y from or to the VOR along a reference radial, or to automatically intercept a VOR bearing. Although many autopilots still offer such functionality today, modern airliners and business aircraft normally have more advanced Area Navigation systems which use information of multiple VOR stations and other navigation equipment to follow arbitrary routes between arbitrary waypoints. In this report we will consider tracking of VOR radials only.
VO R
68
In order to compute VOR signals for simulation purposes we need to know the exact positions of the VOR station and the aircraft in relation to the Earth-xed reference frame. If the horizontal position of the VOR ground station is dened by the coordinates ( xVOR , yVOR ) and the horizontal position of the aircraft by ( xe , ye ), we can nd the following equations for the QDR and the course deviation angle VOR (see gure 5.11): QDR = arctan VOR ye yVOR xe xVOR = CD QDR (5.23) (5.24)
We also need to know whether the aircraft ies toward the VOR beacon, or away from it. This information is visualized in the cockpit by means of a TO-FROM indicator, which veries the difference between the airplanes heading and the QDR:
| QDR| > 90 TO | QDR| < 90 FROM
(5.25)
(In gure 5.11 we can observe that the aircraft is ying away from the VOR beacon. This corresponds with the above given relations since QDR 40 , which is indeed 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 ies in an area where the VOR signals can be received with appropriate reliability. This distance is equal to: RVOR =
( xe xVOR )2 + (ye yVOR )2
(5.26)
If the aircraft ies in a certain area in the direct neighbourhood of the VOR transmitter, the signals are not accurate. This area is formed by a cone with a top-angle of approximately 80 to 120 degrees, the so-called Cone of Silence, which has been shown in gure 5.12. The aircraft ies 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 height of the airplane above the VOR station. Table 5.3 gives the maximum coverage of the VOR signals as a function of the height above ground level, measured in two different ight tests [7]. Using the M ATLAB function POLYFIT to t a polynomial to the data from this table, the following approximative function for the VOR coverage as a function of the altitude (expressed in meters, contrary to table 5.3 itself!) was found: Range = 1000 2.3570 106 ( H HVOR )2 +
+ 5.7087 102 ( H HVOR ) + 80.8612
(5.28)
5.2. The VOR navigation system
69
to 6 40
o
40 o
to 6
0o
RD
E M
VOR antenna
RVOR
Figure 5.12: The Cone of Silence
Another, more generally accepted, rule-of-thumb to determine the coverage of a VOR station is [5]: Range = 1.2 h + hVOR (5.29) where Range expresses the VOR coverage in nautical miles, h is the height of the aircraft above the ground, measured in [ft] (this differs from equation (5.28), which expressed the altitude in meters above sea-level!), and hVOR is the height of the VOR station 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 equipment errors. Each of these errors comprises both the equipment and antenna errors and 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 distance from 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 .
H - HVOR
Cone of Silence
70
Height [ft] 1000 5000 20000 30000 3000 5000
VOR range [NM] 50 92 182 220 75 95
Table 5.3: VOR coverage based on two different ight tests [7]
Ref.[7] presents some data about ground equipment errors, obtained from actual measurements. According to this source, the steady-state errors typically lay somewhere in the range from 1.4 to 2.5 . There are also other errors of a more random nature, which are caused by e.g. variations of supply voltage of the ground and/or airborne equipment, temperature changes, inaccurate instrument reading, etc. Flight tests using commercial aircraft yielded the following approximative values for overall 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 may be more accurate than these gures suggest.
5.3
Other ight navigation systems
The equations from the previous section allow us to create a simulation model of an aircraft that is operated in a conventional air-trafc environment, using VOR and DME systems for guidance along airways, standard arrival routes, and standard departure routes. However, in modern air-trafc control environments, it has become increasingly common to dene ad-hoc ight-paths along great circles1 between xed (sometimes arbitrary) waypoints, rather than y along pre-determined airways, dened by VOR radials. The geometric position of modern airliners is computed by the Flight Management System, using integrated information from DME stations (possibly VOR stations), the Inertial Reference System (IRS) from the airplane, and sometimes also navigation information from Global Positioning System (GPS) satellites. In this setup, the IRS usually offers short-term position information, which remains accurate even when manoeuvring, while the radio and/or satellite navigation signals offer longer-term position updates which nullify the long-term IRS drift.
1 A great circle is a circle on the surface of a sphere (thus on the surface of the Earth or the celestial sphere) which is formed as the result of the inter-section of the sphere and a plane passing through the center 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 precision approach system, even though in the late 1970s ICAO declared the far superior Microwave Landing System (MLS) to become the precision approach system for the 21st century. In practice, the MLS has only been applied in a few specialized locations where operational requirements dictated a need for a combination of precision and accuracy that, at that time, only the MLS could provide. Nowadays it seems more likely that the role of the ILS will some day be taken over by satellite-based landing guidance systems. Precision approach guidance using GPS is already feasible today. It would go far beyond the current scope of this report to analyze these other navigation systems in detail. If modern navigation systems and practices are to be evaluated in simulations, additional mathematical models will most likely be required. However, the general approach taken in the previous two sections could serve as a model for the determination of the governing equations: start by dening the navigation geometry, and include systematic and random system errors thereafter. It should be noted that in ight simulations, we can always compute the exact position of the airplane; constructing a realistic model of a navigation system is therefore mainly 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 the aircraft, resulting from applied control inputs and external disturbances. Although the model includes many observation variables that make it suitable for many applications in aircraft dynamics research and ight control system design, we need to take into account the difference between the actual values of these variables and the values which are sensed and displayed on the cockpit instruments, or used for computations by the ight control computers of the airplane. In addition, we must remember that this model is based on the actual deections of control surfaces, which do not necessarily correspond to the intended control inputs generated either directly by the pilot (using the ight controls in the cockpit), or indirectly via an automatic ight control system (using electric signals to dene deections of actuators, which in turn move the control surfaces). Both on the input and on the output side of the aircraft model, we may need to augment the equations by including additional system dynamics, deterministic errors, stochastic errors, and data-processing inuences. Whether or not such renements are really necessary obviously depends on the required accuracy for specic tasks. For instance, while it may very well be possible to build a decent set of ight control laws using the idealized equations from chapter 3, it is quite possible that other effects such as sensor noise, actuator dynamics, and time-delays and quantization effects caused by computer limitations may degrade system performance to such an extent that additional measures have to be taken. A striking example of the potential detrimental effects of signal processing in a digital computer was encountered during the design of the Altitude Hold control law for the Beaver autopilot (see chapters 14 and 15): the altitude signal was represented with a Least Signicant Bit of approximately 4 feet, which would lay well within the
72
required accuracy, but which inadvertently caused the reference input to consist of a series of 4 feet step-inputs. This resulted in unacceptable control characteristics; additional ltering of the altitude signal was required to solve the problem [28]. Since the Flight Dynamics and Control toolbox currently does not include a comprehensive library of sensor and actuator models, despite their potential importance for ight control system design tasks and ight simulation, this report will not further elaborate on this subject. However, the toolbox does take into account some specic ad-hoc representations of time-delays, quantization effects, and actuator dynamics to represent the Beaver autopilot; see the corresponding block-reference for details.
Chapter 6
Analytical tools
When developing the aircraft differential equations in chapter 2, much emphasis was placed on the state-space formulation for the aircraft differential equations. This formulation will prove to be especially suited for the implementation of the aircraft model in the S IMULINK environment, and the development and application of analytical M ATLAB and S IMULINK software tools. Figure 6.1 shows the nonlinear state-space model of the aircraft and the associated analytical tools. The tools provide the capability to trim the aircraft model for steady-state ight, perform digital simulations, and derive linear state-space descriptions of the aircraft dynamics. Linear control system design techniques can be applied to these linearized aircraft models, and the resulting control laws can be validated with nonlinear simulations. Notice how this gure corresponds to the upper part of gure 1.3 from chapter 1, which depicted the ight control system design cycle in the FDC toolbox. These analytical functions are mostly generic in nature, and S IMULINK and M ATLAB include several built-in software tools to full these functions. Although it is not necessary (and often not possible) to know the exact algorithms used by these built-in tools, it is still useful to have at least a basic understanding of the underlying theory. For this purpose, this chapter provides an introduction to the theory of simulation (in particular: numerical integration), system linearisation, and some elements from linear system analysis. It also introduces a specialized trimming algorithm, tailored to the nonlinear aircraft model.
6.1
Numerical integration methods
The aircraft equations of motion from chapter 2, which were further elaborated in chapter 3, express the aircraft dynamics in terms of a set of twelve nonlinear ordinary differential equations (ODEs). To simulate aircraft responses to control inputs or external disturbances, we therefore need to solve an initial-value problem. The FDC toolbox delegates this task to the built-in S IMULINK integrators, which have been documented in the M ATLAB and S IMULINK user-manuals, refs. [3] and [4], and in ref.[32]. These documents can all be downloaded from www.mathworks.com. A summary of the S IMULINK solvers will be given in chapter 11. Here, we will provide general background information about numerical integration of ODEs.
74
Chapter 6. Analytical tools
Steadystate trim
Initialisation data
Nonlinear simulation
Initialisation data
Nonlinear state-space model

. x ( t ) = f ( x( t ) , u ( t ) , t ) y ( t ) = g ( x ( t ), u ( t ) , t )
Linearise
Control system simulation Linear statespace model

. x(t) = A x (t) + B u (t) y( t ) = C x ( t ) + D u ( t )
Coefficient data
Trial design
Linear design techniques

Figure 6.1: State-space ight 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-trajectories of state variables of continuous dynamical systems, which are characterized by 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 time t0 . This equation represents a so-called initial value problem. Since few differential equations can be solved exactly, it is usually necessary to approximate the solutions of these ODEs numerically. If the state vector x has N elements, N constants of integration appear in the solution of equation (6.1). A unique solution to this system can be obtained only if the initial values of all states are specied. The techniques for solving the vector equation (6.1) are essentially the same as the techniques used for solving scalar initial value 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 of brevity; including the latter signals does not change the integration methods. Numer-
6.1. Numerical integration methods

x
75
Initial value
x0
x1
x2
x3
Euler solution
t0
t1
t2
t3
Figure 6.2: Family of solutions of an unstable ODE. The Euler approximation from equation (6.3) has been displayed graphically.
ical integrators generate a sequence of discrete points t0 , t1 , t2 , . . . in time, possibly with variable spacing hn = tn+1 tn (the step-size). At each point tn the solution x (tn ) is approximated by xn , which is computed from earlier values of x. If k earlier values xn , xn1 , . . . , xnk+1 are used for the computation of xn+1 , the method is called a k-step method. For instance, the Euler method is a single-step method: x n +1 = x n + h n f ( x n , t n ) This method is used by the S IMULINK integrator ode1. (6.3)
6.1.2
Stability, errors, and order of a numerical integration method
Figure 6.2 shows a typical family of solutions of a rst-order differential equation for different initial values x0 . If we select a wrong value of the initial condition, the deviation from the desired solution will increase in time, i.e. the differential equation is unstable. The gure demonstrates how the Euler approximation from equation (6.3) will cross from one solution to another between subsequent time steps, due to the numerical inaccuracy. For this unstable differential equation, the resulting error is shown to increase in time. Figure 6.3 shows a family of solutions for a stable differential equation. In this case, the solutions of the ODE converge as time proceeds, and numerical integration errors do not increase with time. Nonlinear differential equations may be unstable in some regions and stable in others. For multiple coupled ODEs, the situation will be even more complex. One should always be aware of possible instabilities of dynamic systems when assessing numerical results. Numerical integration methods introduce two types of errors: discretisation errors and round-off errors. Discretisation errors are a property of the numerical integration method, while round-off errors occur due to the nite number of digits used in the calculations (hence they are a property of the computer and the program that is used). In general, reducing the step-size hn will decrease the discretisation error.
76
Figure 6.3: Family of solutions of a stable ODE

Error
Total error
Discretisation error Min. error Round-off error
hn min
hn
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-off error is starting to become dominant. This has been illustrated in gure 6.4. These errors may cause the numerical solution to become unstable, even when the ODE itself is stable. An example of this numerical instability will be shown later in gure 6.5, which demonstrates a system where the numerical error of the Euler method is amplied in each step. The order of a numerical integration method is dened in terms of the local discretisation error n , obtained when the method is applied to problems with smooth solutions. A method is said to be of order p if a number C exists so that:
|n | Chn p+1
(6.4)
77
C may depend on the derivatives of the function which denes the differential equation and on the length of the interval over which the solution is sought, but it should be 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 methods. Based upon these references, we will provide a brief overview of these methods in this section. All equations can easily be converted to vector notations when evaluating 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 expansion: hn 2 (6.5) x (t) + . . . 2! Provided it is possible to calculate higher-order time-derivatives of x, a numerical method of order p can be obtained by using: x (t + hn ) = x (t) + hn x (t) + x n +1 = x n + h n x n + hn 2 hn p xn + . . . + 2! p! dp x dt p (6.6)
The derivatives xn , xn , etc. can be expressed in terms of the partial derivatives of the function f from the state equation (6.2). The rst neglected term provides an estimate of 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 the Euler method equals p = 1. Higher-order Taylor series methods involve increasingly complex computations of the higher-order derivatives, so the general applicability of these methods is rather limited.
2. Runge-Kutta methods
Runge-Kutta methods approximate Taylor series methods without evaluating timederivatives beyond the rst. The higher-order derivatives are replaced by a number of evaluations of the function f . Modern Runge-Kutta algorithms typically include techniques 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 compute xn+1 , which makes them self-starting. In order to gain a little more insight in the relation between the Taylor series and Runge-Kutta methods, we will now rst take a look at the derivation of a second order Runge-Kutta method. The second-order method uses two function evaluations per step [17]: k1 = hn f ( xn , tn ) k2 = hn f ( xn + k1 , tn + hn ) (6.7)
78
The second step is a fractional step based on k1 . and are two as yet unknown coefcients. The two function evaluations are combined to make a complete step, which involves two additional unknown coefcients 1 and 2 : xn+1 = xn + 1 k1 + 2 k2 (6.8) To determine the coefcients, k1 and k2 are expanded in a Taylor series about (tn , xn ), giving: k1 = hn f n k2 = hn Hence: xn+1 = xn + (1 + 2 )hn f n + 2 h2 n f x f n + 2 h2 n
n
f n + k1
f x
+ hn
n
f t
+ ...
n
(6.9)
f t
+ ...
n
(6.10)
In these equations, f n has been used as a shorthand notation for f ( xn , tn ). The expansion of xn+1 can be compared with the Taylor series for the actual local solution z n ( t ): z n ( t n +1 ) = z n ( t n ) + h n z n ( t n ) + h2 n zn (tn ) + . . . 2 f f fn + x n t
= xn + hn f n +
h2 n 2
+ ...
n
(6.11)
Matching the coefcients of the powers of hn yields three equations involving the unknown coefcients: 1 + 2 = 1 2 = 1 =
1 2 1 2
(6.12)
It is now possible to choose one coefcient as parameter, which results in a oneparameter 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 ) 1 1 x n +1 = x n + 1 k1 + k2 2 2 (6.13)
1 Obvious choices of are 2 , which yields a method closely related to the rectangle rule, and 1, yielding a method related to the trapezoid rule. The method is of second order, because no choice of can eliminate the h3 terms, which were neglected in the above equations.
Higher-order Runge-Kutta methods can be derived in a similar manner. Although these higher-order methods provide an improvement of accuracy, this comes at the cost of additional derivative evaluations. For a given overall accuracy in a time response calculation, there is a trade-off between many small steps with a lower-order method, or fewer steps, but more derivative evaluations with a higher-order method.
79
i
0
1 5 3 10 4 5 8 9 1 5 3 40 44 45 19372 6561 9017 3168 35 384 9 40 56 15
ij
i
35 384
i
5179 57600
0
500 1113 32 9 64448 6561 46732 5247 500 1113 212 729 49 176 125 192 5103 18656 125 192
0
7571 16695 393 640 92097 339200 187 2100 1 40
25360 2187 355 33

0
2187 6784
11 84 11 84
1 1
2187 6784
Table 6.1: Coefcients of the Dormand-Prince (4,5) pair
In order to reduce the number of function evaluations, mathematicians have developed several algorithms that combine Runge-Kutta integration with an estimation of the error in the computed function at each time-step; the error estimate can be used to control the step-size automatically in order to meet a specied accuracy. Over the years, several so-called Runge-Kutta pairs have been developed. These pairs combine two Runge-Kutta methods, usually of adjacent orders p q, which share their and coefcients and differ only in the s. For p = 1, . . . , 4 it is possible to obtain a pth -order method with p function evaluations, while for p = 5 or 6, p function evaluations will produce a ( p 1)st -order method only [17]. However, for Runge-Kutta pairs the extra function evaluation is not wasted, as the difference between the two solutions provides a convenient error estimate. Such pairs are dened by: k i = hn f ( xn + ij k i , tn + i hn )
j =1 i 1
(6.14)
The new value xn+1 is obtained using a weighted combination of the six ks. The two Runge-Kutta methods that form a pair result in two solutions for xn+1 : x n + 1 = x n + i k i
xn+1 = xn + i k i
i =1 i =1 N N
(6.15)
where N is the number of function evaluations. For 4th /5th -order pairs, N 6. In practice, the lower-order solution xn+1 is not actually computed; instead the error estimate:
n xn+1 xn+1 =
i =1
(i i )
(6.16)
is determined and used for step-size control.
80
The coefcients i , ij , and i can again be found by by expanding the ks in Taylor series, substituting the expansions into the formula for xn+1 and comparing the result with the Taylor series for the true local solution zn (tn+1 ). Notice that the s form a lower triangular array, so that each k i is obtained from the previous ks. A popular strand of explicit Runge-Kutta methods are the Dormand-Prince pairs. Table 6.1 lists the coefcients of the fourth- and fth-order methods (represented by the coefcients i and i , respectively), which are usually combined to form the Dormand-Prince (4,5) pair. This pair is used by the S IMULINK solver ode45.
3. Linear multistep methods
The Runge-Kutta and Taylor series methods determine the value of xn+1 by means of a function which depends only on tn , yn , and the step-size hn . Multistep methods differ in that they use information at previous points to obtain more accuracy. Multistep methods can be very effective, as they usually require less function evaluations than one-step methods of equal accuracy: a number of past values can be kept in storage as the computation proceeds. Furthermore, an estimate of the discretisation error can often be trivially obtained [17]. Properly programmed multistep methods can efciently provide outputs at arbitrary points without changing the value of the step-size. The order of the method can be selected automatically and changed dynamically. Some multistep methods can handle stiff equations (see section 6.1.4), and equations can be classied as stiff or nonstiff automatically. Linear multistep methods can be considered as special cases of the formula: x n +1 =
i =1
i x n +1 i + h n i f n +1 i
i =0
(6.17)
where f i = f ( xi , ti ) = xi , k is an integer, and either k or k is not zero. This formula denes the general k-step method. It is linear because every f i appears linearly in the equation; f itself does not necessarily have to be a linear function in its arguments. Because of the requirements for past values, the multistep methods are not self-starting; a different method must be used to calculate the starting values of x. After equation (6.17) has been started, each step involves the calculation of xn+1 from the known values xn , xn1 , . . . , xnk+1 , and f n , f n1 , . . . , f nk+1 . If 0 is nonzero, the algorithm is implicit because in that case the solution xn+1 is needed to evaluate f n+1 = xn+1 on the right-hand side of equation (6.17). The implicit 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 computing each step of the solution: an explicit method, called predictor, followed by one or more applications of an implicit method, which is called a corrector. The S IMULINK solver ode113, which is based on an Adams method, is an example of a predictorcorrector multistep method. Some important Adams solvers found in literature are the explicit Adams-Bashforth integration method and the implicit Adams-Moulton method.
81
i: 1i 2 2i 12 3i 24 4i 720 5i 1440 6i
1 1 3 23 55 1901 4277
1 16 59 2774 7923
5 37 2616 9982
9 1274 7298
251 2877
475
Table 6.2: Coefcients for the Adams-Bashforth integration method
i: 1i 2 2i 12 3i 24 4i 720 5i 1440 6i

1 1 1 5 9 251 475
1 8 19 646 1427
1 5 264 798
1 106 482
19 173
27
Table 6.3: Coefcients for the Adams-Moulton integration method
The k-step Adams-Bashforth formula can be written as: xn+1 = xn + hn ki f n+1i

i =1 k
(6.18)
Table 6.2 lists some values ki for this method. The k-step Adams-Moulton formula equals:
k 1
x n +1 = x n 1 + h n
i =0
ki f n+1i
(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 extrapolate 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 rational function interpolation formulas, providing alternative ODE solvers. We will not discuss such methods will in this report, as none of the S IMULINK integrators have been based on these theories. See ref.[18] for more information about this subject.
82
x x2 f (t)
x0 x1 x3
t0
t1
t2
t3
Figure 6.5: Unstable solution using the Euler method for a stiff system.
x f (t) x0 x1 x2 x3
t0
t1
t2
t3
Figure 6.6: Stable solution using the backward Euler method for a stiff system.
83
k: 0 1 2 3 4 5 6
2
2 3 4 3
3
6 11 18 11 9 11 2 11
4
12 25 48 25
5
60 137 300 137
6
60 147 360 147 450 147 400 147 225 147 72 147 10 147
1 3
36 25
16 25 3 25
300 137
200 137 75 137 12 137
Table 6.4: Coefcients for stify stable integrator (Gear method)
6.1.4
Stiff differential equations
Stiffness of the differential equations can roughly be dened as the presence of one or more fast decay processes in time, with a time constant that is short compared to the time-span of interest. For stiff problems, solutions can change on a time scale that is very short compared to the interval of integration, while the solution of interest changes on a much longer time scale. The time constant is dened as the time in which a solution to a differential equation decays by a factor 1 . In a physical system, different elements often have differe ent time constants, which means that some solutions to differential equations decay much faster than others. In such cases the signals containing fast dynamics will determine the stability of the integration method, even when these components may quickly decay to insignicant levels. Methods not designed for stiff problems must use time steps small enough to resolve the fastest possible changes, which makes them rather ineffective on intervals where the solution changes slowly. Figure 6.5 shows what happens when we apply the Euler method to a stiff problem, using too large a step-size: although the ODE itself is stable, the numerical solution can be seen to diverge rapidly. The only way to prevent this numerical instability is to reduce the step-size, but eventually roundoff 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 increase 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 is an implicit method: x n +1 = x n + h n f ( x n +1 , t n +1 ) (6.20)
This method is stable, although the accuracy of the transient part of the solution is rather poor. The accuracy can be improved by using multistep backward differen-
84
tiation formulas, such as the following method, rst implemented by C.W. Gear [18]: xn =
i =1
i x n i + h n 0 f n
(6.21)
The coefcients i and 0 have been listed in table 6.4. This Gear method differs from the Adams method in the way in which the implicit expression is solved. The algorithm for the S IMULINK 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 a linearized aircraft model from the S IMULINK implementation of the aircraft dynamics. Such models are invaluable for the application of most control system design methods. The tool calls the S IMULINK function LINMOD for the actual linearisation process. Here we will briey 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 assume disturbances to be included in the inputvector u). This expression can be expanded in a Taylor-series about an operating point (x0 , u0 ). Keeping only the rst-order terms, we nd: f f x(t) ( x x0 ) + ( u u0 ) + x0 (6.23) x u where x0 = f( x0 , u0 ) and both partial derivative matrices are determined for the operating point (x0 , u0 ). Moving x0 to the left-hand side of the equation yields: x x0 = Now dene: x = x x0 , a vector of length n u = u u0 , a vector of length m and: A = B = f x f u
(x0 ,u0 )
f f ( x x0 ) + ( u u0 ) x u
(6.24)
(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 the operating point values of the state and control vectors, respectively. In practice, the operating point (x0 , u0 ) is chosen to be a singular point or equilibrium point. The system is at rest when all of the state derivatives are identically zero, 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 departs rapidly from the singular point in response to a small perturbation, the human pilot is unlikely to be able to control the aircraft [33]. In section 6.3 the computation of steady-state equilibrium ight conditions will be explained. The matrices A and B can be evolved analytically by evaluating the wind-axes force equations, the moment equations, the kinematic equations, and the position equations presented in section 2.5. This analysis involves a large series of partial derivatives of the forces and moments with respect to other variables, the so-called stability and control derivatives. Refs.[14] and [33] explain how these derivatives can be determined; the rst reference contains an comprehensive list of derivatives, including derivatives for an large number of observation variables. While this analytical linearisation provides useful insight in the force and moment build-up (aerodynamic forces and moments in particular), we dont need to perform this complete analysis just to nd the numerical values of the system matrices A and B. Since the nonlinear aircraft model has been presented in state-space form also, it is actually more convenient to bypass the stability derivatives and calculate the system matrices directly. This is done by perturbing the state and control variables from the steady-state condition, and numerically evaluating the partial derivatives. In this report we will consider the latter method only; analytical linearisation tools will be kept in mind for possible future FDC versions. The matrix A can be written out as follows: f f 1 . . . x1 n x1 . . . A= . . . fn fn x1 . . . xn
(6.26)
where the partial derivatives are valid for the equilibrium point. This matrix can be approximated by: f f (x +x ,u ) f (x ,u ) f f (x +xn ,u0 ) f 1 (x0 ,u0 ) 1 1 0 1 0 1 0 0 . . . x1 ... 1 0 x1 xn n x1 . = . . (6.27) . . . A . . . f fn f (x +xn ,u0 ) f n (x0 ,u0 ) f n (x0 +x1 ,u0 ) f n (x0 ,u0 ) . . . xn ... n 0 x1 x1 xn n with: i,1 i,2 xi = xi . . .
i,j =
0 if i = j 1 if i = j
(6.28)
i,n 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
x x1 x 0 x1
...
x x n x0 xn
(6.29) (6.30)
In this equation we used the denition: x xi f(x0 + xi , u0 ) which represents the output from the state equation (6.22) in the operating point with the ith element of the state vector being perturbed by the amount xi . If this perturbation is chosen properly, an approximation of the matrix A can now be determined by subsequently computing its columns (i = 1, . . . , n).
86
A similar method can be used to nd the matrix B. This time, we need to perturb the elements of the input vector u, which results in the following approximation: B with:
f(x0 ,u0 +u1 )f(x0 ,u0 ) u1
...
f(x0 ,u0 +um )f(x0 ,u0 ) um
x u1 x 0 u1
...
x u m x0 um
(6.31)
ui = ui and:
i,1 i,2 . . . i,m
i,j = 0 if i = j 1 if i = j (6.32)
xui f(x0 , u0 + ui )
(6.33)
Equation (6.33) represents the output from the state equation (6.22) in the operating point 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 operating point (x0 , u0 ): g g ( x x0 ) + ( u u0 ) + y0 (6.35) x u if we neglect the higher-order terms; y0 = g( x0 , u0 ) and both partial derivative matrices are determined for the operating point (x0 , u0 ). This equation can be developed into the following small-perturbation equation for the output vector y: y(t) y y y0 = Cx + Du with: C = g x
(x0 ,u0 )
(6.36)
g D = u
(x0 ,u0 )
C and D can be approximated in a similar fashion as the matrices A and B from the 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 and control derivatives. With n states and m observation variables, the dimensions of these matrices become: A: B: C: D:
(n n) (n m) (m n) (m m)
For the Beaver model from the FDC toolbox, n equals 12 and m equals 89. The latter number includes the twelve state variables themselves, see chapter 3. This numerical linearisation method forms the basis of the S IMULINK linearisation function LINMOD, which is called by the FDC linearisation program ACLIN.
6.3. Steady-state trimmed ight
87
6.3
Steady-state trimmed ight
The FDC toolbox contains a specialized utility ACTRIM, which determines steadystate trimmed ight conditions that can be used as operating points for system linearisation, or as initial conditions for simulations. Although S IMULINK itself already includes a generic trim function TRIM, it was decided to implement a specialized tailor-made trim routine instead, using an algorithm from ref.[33] that has proved to be very effective in practice. Based on that reference, this section will discuss the underlying theory.
6.3.1
Denition of steady-state ight
In section 2.5, it was shown that the general rigid-body dynamics can be written as a 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, for the Beaver aircraft, the equation turned out to be implicit, as the aerodynamic side-force itself was directly dependent on (similar dependencies are common in aerodynamic 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 approach by 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 reects the most general case, where we have to cater for time-dependencies such as gradual weight reduction due to fuel burn. However, in the relatively short time intervals considered in our simulations, the system can be treated as time invariant: the states, inputs, and disturbances change 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 timeinvariant system with no external control inputs. The coordinates of the singular point(s) of the implicit nonlinear state equations are given by the solution vector x = xeq , which satises: 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 of the time-derivatives are identically zero, and we can examine the behaviour of the system near the equilibrium point by slightly perturbing some of the variables, as we have outlined in the previous section. Steady-state trimmed ight can be dened as a condition in which all of the motion variables are constant or zero, and all acceleration components are zero. This denition is very restrictive, unless some simplifying assumptions are made. We will assume the aircrafts mass to remain constant, and restrict the analysis to the at-Earth equations of motion, so that the denition will allow steady wings-level ight and steady turning ight. If the change in atmospheric density with altitude is neglected during the trim process, a wings-level climb and a climbing turn are also permitted as steady-state ight conditions.
88
One method to nd a steady-state ight condition is to balance the individual forces and moments by closely examining the aerodynamic and propulsion models. The disadvantage of this approach is that it involves working within the aircraft model itself, which would either restrict our exibility to implement forces and moments in whatever format we prefer (for instance, compare the polynomial structure of the Beaver aerodynamics model with the table-lookup methods often used in industry), or require the creation of customized trimming tools for every individual aircraft model. We will therefore use a more generic method that will deal with the aircraft model only through its input and output signals, separating the software from the model as visualized in gure 6.1. The trim algorithm must solve a set of nonlinear simultaneous equations, derived from the state model. The very complex functional dependence of the aerodynamic data makes it virtually impossible to solve these equations analytically, so a numerical algorithm must be used to iteratively adjust the independent variables until some solution criterion is met. The numerical solution will be approximate, but can be made arbitrarily close to the exact solution by tightening up the criterion. It should be realized that solutions do not have to be unique. For example, for a given engine power, there may be two different airspeed and angle of attack combinations that result in steady level ight. Our knowledge of aircraft behaviour makes it possible to specify the steady-state condition so that the trim algorithm will converge on an appropriate solution.
6.3.2
Specication of the ight condition
We must rst decide how to specify the steady-state ight condition, how many of the control variables may be chosen independently, and what constraints exist on the remaining variables. We can then develop a numerical algorithm that adjusts the remaining independent variables and evaluates the constraint equations. If we neglect the change in air density with altitude, the state equations for the aircraft coordinates xe , ye , and the altitude H can be disregarded in our search for a steady-state ight condition, as they no longer couple back into the other equations of motion. Steady-state ight conditions that are important for ight control system design can then be dened in terms of the remaining nine state variables of the atEarth equations: p, q, r, V, , (or u, v, w) 0 and u = constant (6.40)
Additional constraints have to be made to dene the exact ight condition. Here we will consider steady wings-level ight, steady turning ight, steady pull-up or push-over, and steady rolls, which are dened by the following constraints: steady wings-level ight: , , , 0 (i.e. p, q, r 0) steady turning ight: , 0, = turn rate steady pull-up or push-over: , , 0, = pull-up rate 0, = roll rate steady roll: , To satisfy the conditions p, q, r 0, the angular rates must be zero (as in level ight) or constant (as in steady turns). The conditions V, , 0 require the airspeed,
89
angle of attack, and sideslip angle to be constant. As a consequence, the aerodynamic and thrust forces and moments must be zero or constant.1 First of all, we will assume that the aircraft conguration (such as the position of the landing gear and the aircraft loading) and secondary ight controls (aps, slats, speedbrakes) are pre-specied. In addition, we must specify the secondary engine controls (target RPM for a constant-speed propeller, mixture control for a piston engine) and conguration settings that affect engine power (bleed air requirements for jet engines, thrust limit settings for specic phases of ight). For the Beaver model, we will pre-specify the ap position f and the engine RPM n. For steady-state ight, we expect to be able to specify the (initial) altitude and the airspeed. The latter can be controlled by changing either the engine power or the pitch attitude of the airplane (or both), so it is useful to pre-specify at least one of those variables: 1. We can x the ight-path angle, within the boundaries imposed by the engine power, and let the numerical algorithm search for a matching value of the engine power. This situation is sometimes referred to as speed on thrust: for a given ight-path angle, changes in airspeed are achieved by increasing or decreasing engine power. 2. Alternatively, we can x the engine thrust, without putting any constraints on the ight-path angle. This can be called speed on pitch: for a given power setting, the airspeed can be increased by lowering the nose of the airplane, and vice versa. Notice that because of equation (6.40), it is not possible to achieve steady-state ight with an engine thrust that exceeds the weight of the airplane, as even for vertical ight that would result in a linear acceleration. The rst method introduces an additional constraint on the pitch angle, while letting the engine thrust be determined numerically. In the latter case, the pitch angle will be adjusted numerically, but the thrust will be pre-specied. Notice that nonzero values of the ight-path angle will result in instantaneous steady-state ight conditions only, because the air-density will no longer remain constant if the aircraft is climbing or descending.
6.3.3
Remaining control and state variables
The primary ight controls e , a , and r (elevator, ailerons, rudder) enter the model through the aerodynamic data. In general, it is not possible to determine any analytical constraints on these variables, so these three control inputs will be tuned by the numerical algorithm. The thrust can either be pre-specied (speed on pitch), or adjusted by the numerical algorithm (speed on thrust). For the Beaver aircraft, the primary engine control variable is the manifold pressure pz . The engine RPM n, which is the target speed for the regulator mechanism of the constant-speed propeller, is considered a secondary engine control signal that can be pre-specied.
steady-state pull-up or push-over and steady-state roll conditions can only exist instantaneously. However, it can still be useful to trim the aircraft dynamics in such ight conditions and use the resulting operating point values of x and u for aircraft model linearisation, because ight control systems must operate there too.
1 Because of this requirement,
90
In steady-state translational ight conditions, the state variables , p, q, and r are identically zero and can be selected freely. Since V and H are also specied by the user, and xe and ye are irrelevant for the steady-state solution, the only remaining state variables to be determined are , , and . The angle of attack must be adjusted by the trim algorithm to generate the amount of lift needed to support the weight of the aircraft (remember that we chose to pre-specify the airspeed and altitude, and hence, the dynamic pressure). The sideslip angle must be adjusted by the trim algorithm to zero out the sideforce Fy . For a given value of the ight-path angle (speed on thrust), the pitch angle will be constrained, as we will explain in the next section, which presents a general rate-of-climb constraint that allows nonzero roll angles. If the thrust is specied by the user (speed on pitch), the pitch angle can be adjusted by the trim algorithm. In steady-state turning ight conditions, the state variables , p, q, and r will differ from zero. The turn can be specied directly in terms of the yaw rate or indirectly through the turn radius R. These variables are interrelated as follows: V = (6.41) R The initial heading can still be specied freely. If the attitude angles and are known, it is possible to determine the angular rates p, q, and r from the kinematic relations given in equation (2.59) of section 2.4. In principle, it is also possible to dene the turn by specifying the roll angle directly. However, that will in general introduce a signicant sideslip angle , resulting in a skidding turn, in which a side-force is experienced by the ight crew and passengers. To avoid this, an additional constraint for coordinated turns will be derived in section 6.3.5, in order to compute the roll and sideslip angles such that the aircraft is banked at an angle with no component of the aerodynamic and propulsive side-force Ya + Yp . If the roll angle is known, the required pitch angle can be obtained from the rate-of-climb constraint, which will be derived in the next section. Since the turncoordination constraint will be shown to involve both and , it must be solved simultaneously 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 equation (2.61), and equations (2.31), (2.62), and (3.45): H ze sin = = = V V = ue sin + (ve sin + we cos ) cos =
=
with: a cos cos
a sin b cos
(6.42)
b sin sin + cos sin cos
(6.43)
91
Solving for , the resulting rate-of-climb constraint is found to be [33]: , = (6.44) 2 a2 sin2 which allows us to compute , knowing the pre-specied value of and the current value of . Obviously, this constraint is not applicable for speed on pitch. tan = a b + sin a2 sin2 + b2
6.3.5
The coordinated turn constraint
In the Earth-xed reference frame, assuming a at Earth, the velocity vector is tangential to the turning circle, so the centripetal acceleration, expressed in units of [g] equals: V G= (6.45) g0 We can derive a constraint for coordinated turns by taking the lateral v equation of the nonlinear force equations (2.28), imposing the steady-state condition v = 0, and the coordination condition Fy = Fgr , i.e. no aerodynamic and/or propulsive sideforce. Substituting equation (3.10) yields: g0 cos sin + pw ru = 0 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 corresponding relations from equation (2.31), we nd: g0 cos sin V sin sin cos + cos cos cos cos = 0 (6.48) (6.46)
Finally, by substituting equation (6.45) and re-writing terms, the resulting coordinated 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 aircraft for a coordinated turning ight with a specied rate-of-climb. If these equations are solved simultaneously, the only remaining variables to be adjusted by the numerical trim algorithm are the angle of attack and sideslip angle and the control inputs. According to ref.[33] the simultaneous solution equals:
2 2 2 2 cos ( a b ) + b tan c (1 b ) + G sin tan = G cos a2 b2 (1 + c tan2 ) where:
(6.50)
a 1 G tan sin sin b cos c 1 + G2 cos2
(6.51)
92
Specify (initial) flight- and aircraftcondition for trimming
Minimisation algorithm
Store steady-state values of x and u
Flight path constraints u x
Aircraft model (evaluate state equations) . x Scalar cost function . J(x) = J ( x , u )

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 ight-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-climb constraint remains to be solved.
6.3.7
The resulting steady-state trimmed-ight algorithm
We can now develop a general aircraft-trim algorithm that determines steady-state ight conditions by searching for the state and control vectors for which the state derivatives V, , , p, q, and r are identically zero, as specied in equation (6.40). This is achieved by means of a multivariable numerical optimisation routine that minimises a scalar cost function by adjusting the control inputs and appropriate state variables. The cost function J is usually equal to the sum of the weighted squares of the time-derivatives: J = c1 V 2 + c2 2 + c3 2 + c4 p2 + c5 q2 + c6 r 2 (6.53) where ci , i {1, 2, . . . , 6}, are weighting constants. A suitable optimisation technique for this particular problem is the Simplex method [33]. Figure 6.7 shows a block diagram of the resulting trim algorithm. First the ight condition must be specied. The trim program must make an initial guess for the independent 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 x and 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 updated for each iteration step. The state equations are then evaluated for the new values of u and x to nd the time-derivative of the state-vector, x. Substituting the results in equation (6.53) yields the new value of J, which is returned to the minimisation routine. A stop criterion that depends upon the change of J between two iterations is used to decide when to nish the minimisation procedure. Also, the maximum number of iterations is limited 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 gure 6.1, focussing on numerical integration, linearisation and trimming methods. In this section, some other issues which may be encountered during numerical nonlinear simulations will be highlighted. These topics are relevant for the FDC toolbox, because they shed some light on the practical difculties one may encounter, and provide background information for some analytical functions. The information from section 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 system into logical modules, and suggest a certain order of computations. The latter, though convenient for digital simulations, is not in accordance with reality: in the actual system, all variables will change simultaneously, not sequentially. A suitable calculation sequence is needed for digital simulations, but we should realize that this is an articial construct a sequential representation of what is, in effect, a parallel system. If feedback is applied to a system, it may not be possible to nd a suitable computation sequence for digital simulations. This situation generally occurs when blocks having direct feedthrough of their input signals form a feedback-loop: the block outputs cannot be computed without knowing the values of the signals entering the blocks, while the block inputs cannot be computed without knowing the signals leaving the blocks. This is called an algebraic loop. A simple example of this situation can be seen in gure 6.8, which shows a system consisting of a gain K with negative unity feedback. Mathematically, this loop implies that the output of the summation junction is an algebraic state e, constrained to equal the rst input u minus the output y, which equals K e: y = K e = K (u y) The solution of this simple loop is: y= K 1+K u (6.55) (6.54)
but most algebraic loops cannot be solved so easily [4].
94
u
+_
Figure 6.8: Gain with unity feedback: an algebraic loop
4
0 = t ta pets tinu :tupnI
-1
-2
Figure 6.9: Dynamics, introduced by the algebraic loop from gure 6.8
Algebraic Equations
ALB
Figure 6.10: Iterative solution of an algebraic loop
]s[t
5.0 = K 0.1 = K 5.1 = K

2 3 4 5
K y ( t
) /
g(x)
95
It is interesting to see what will happen if we try to integrate this system with a numerical integration method, using a step-size hn , by introducing an articial computation sequence as follows: e n = u n y n 1 yn = Ken = K (un yn1 ) (6.56) where yn y(n hn ) and yn1 y((n 1)hn1 ) for an integer value n. Taking the Z-transform of these equations yields: Y (z) Kz = U (z) z+K (6.57)
which indicates that inadvertent additional dynamics have been introduced as a consequence of trying to calculate the responses of a parallel system using sequential calculations. Figure 6.9 visualizes unit step-responses for the Z-transfer function (6.57) for several values of the gain K. When S IMULINK detects an algebraic loop it will calls a loop solving routine at each time step. The loop solver tries to determine a solution by means of NewtonRhapson iterations [4]. First, a new block ALB is added to the system containing the implicit algebraic equations from the algebraic loop, see gure 6.10. This block has an input g( x ) and an output x. The block attempts to nd a value of x such that g( x ) = x, which means that it tries to solve the following nonlinear equation: G ( x ) g( x ) x = 0 This is done by applying the Newton-Rhapson method [8]: x i +1 = x i where: G ( xi + x ) (6.60) x for small values of x. The subscript i in these equations denotes the iteration number, not the time-step. In some situations, this method will not converge to a solution within a reasonable number of iterations. S IMULINK will display an error message if it is unable to solve the algebraic loop within 200 iterations (it is possible and recommended 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. One should try to avoid this whenever possible. An algebraic loop can be broken by including an additional dynamic element in the feedback loop, e.g. a lter or an articial time-delay. However, the effect of such measures needs to be weighted carefully remember the inadvertent dynamics from gure 6.9. Sometimes, it is possible to write out the system equations in an explicit form. For instance, the algebraic loop from gure 6.8 can be eliminated by replacing this diagram with a single block representing equation (6.55). Another example was provided in section 3.4, where an algebraic loop in the equation for the aircrafts sideslip angle was averted by re-writing the differential equation in an explicit form. G ( xi ) = G ( xi ) G ( xi ) (6.59) (6.58)
96
bn b n-1 b n-2 ++ ++
b1 U(s) + sn V 1/s an-1 an-2 s n-1 V 1/s sn-2 V sV 1/s V(s) b0
++ ++ Y(s)
++ ++
++
a1 a0
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 implemented in S IMULINK 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, S IMULINK will handle this conversion for Transfer Fcn blocks, but we will discuss this topic in a little more detail nevertheless, as this knowledge will prove to be useful for the implementation of transfer functions with non-constant coefcients. There exist a variety of techniques to convert transfer functions into linear state models. Refs.[8, 33] and [36] contain some examples, and ref.[10] includes a more fundamental discussion of this topic. Regardless of the method, the resulting state models will not be unique, as they depend on the choice of state variables. Here we will focus on what is called the controllable canonical form realisation [10], which will generally be adequate for our needs. For a broad class of systems the dynamic behaviour of variations about operating point values can be approximated by an nth -order linear differential equation: dn y d n 1 y d2 y dy + a n 1 n 1 + . . . + a 2 2 + a 1 + a 0 y = dtn dt dt dt mu m 1 u d d d2 u du = bm m + bm1 m1 + . . . + b2 2 + b1 + b0 u (6.61) dt dt dt dt where u(t) and y(t) represent the variations of input and output signals, ai and bi are
97
real constants, and m and n are scalars, representing the highest-order derivatives of the input and output signals, respectively (m n). The corresponding transfer function is: H (s) Y (s) bm sm + bm1 sm1 + . . . + b2 s2 + b1 s + b0 = U (s) s n + a n 1 s n 1 + . . . + a 2 s 2 + a 1 s + a 0 (6.62)
If there are no input derivatives present in the differential equation (i.e. if m = 0), the task of nding a state representation is trivial: state variables can simply be assigned to the output y and its derivatives up to order n 1, and n state equations can be written down immediately. To derive the state equations in the general case where input derivatives are present, we will rst re-write this transfer function, introducing a help function V (s): Y (s) U (s) = n bm + . . . + b1 s + b0 s + . . . + a1 s + a0 This yields the following equations: V (s) sm Y (s) = (bm sm + . . . + b1 s + b0 ) V (s) sn V (s) = U (s) an1 sn1 V (s) . . . a1 sV (s) a0 V (s) (6.63)
(6.64) (6.65)
These equations can be represented in a simulation diagram, as illustrated in gure 6.11. This diagram is constructed from a series of cascaded rst-order integrals (the 1 blocks) and simple gain blocks; V (s) is the output of the last integrator and s the number of integrators is equal to the degree of the denominator polynomial of transfer function (6.62). Equation (6.65) relates the input of the rst integrator to the transfer function input U (s) and the feedback signals from later integrators. This equation corresponds to the lower half of gure 6.11. Equation (6.64) establishes the resulting output signal Y (s); the output connections have been drawn in the upper half of the gure. Notice that the gure assumes the highest order of the input and output derivatives to be equal, i.e. m = n. For m < n, some of the bi coefcients are zero. If we now assign state variables to the integrator outputs, working from right to left and starting with the rightmost integrator, we can dene the state vector for this transfer function block as: 1 s 2 s x ( s ) = V ( s ) s3 (6.66) . . . s n 1 By observing the simulation diagram, we can obtain the familiar linear state and output equations (taking notice of the fact that u and v are scalars, and x is a vector of length n): x = Ax + bu y = cx + du (6.67)
98
The state matrices then become: 0 1 0 ... 0 0 0 1 ... 0 0 0 0 ... 0 A = . . . . . . . . . . . . 0 0 0 ... 1 a 0 a 1 a 2 . . . a n 1 c = b0 b1 b2 . . . bn 1
0 0 0 b =. . . 0 1 d = bn
(6.68)
This form of the system matrix A is known as a companion-matrix: all elements are zero, except for the superdiagonal 1s and the nonzero bottom row. The simplicity of this form makes it useful for theoretical derivations, but its numerical computation properties are not particularly good. However, this is not a problem when dealing with systems of low order [33]. For the FDC toolbox, the structure from gure 6.11 has been applied for the implementation of the Dryden turbulence lters, which are dened by transfer functions with airspeed-dependent coefcients, and for a lter in the Altitude Select mode of the Beaver autopilot, which also uses non-constant coefcients. Obviously, the standard Transfer Fcn block from S IMULINK is more convenient for the implementation of transfer functions with constant coefcients.
Chapter 7
Getting started with the FDC toolbox

Having treated the underlying theory, it is now time to introduce the Flight Dynamics and Control Toolbox software itself. This chapter explains how to install the toolbox on your computer, and allows you to get acquainted with the software by exploring the FDC directories and libraries. It also explains the modular and layered architecture of the S IMULINK models and outlines the relation between models and libraries. A detailed description of all individual FDC models and programs will be provided later in chapters 8 to 11, while the practical use of the software will be demonstrated in chapter 13.
7.1
Objectives of the FDC toolbox
Lets start by summarizing the purpose of this software. The Flight Dynamics and Control toolbox (FDC toolbox) for M ATLAB and S IMULINK was conceived as an Open Source software environment for ight simulation, open-loop analysis of aircraft dynamics, and closed-loop analysis of ight control systems. It has been constructed around a nonlinear dynamics model of the DeHavilland DHC-2 Beaver aircraft, which is characterized by comprehensive, yet still straightforward model equations. The model has been implemented in a layered, modular S IMULINK block diagram structure, which can be adapted for other airplanes with relative ease. The toolbox includes S IMULINK models of the airplane dynamics, wind and turbulence, radio-navigation signals, and the control laws of the Beaver autopilot, as developed at Delft University of Technology [28]. It also provides analytical M ATLAB routines for the computation of steady-state ight conditions and linearized ight models, and several help-utilities that simplify system handling. The individual models, subsystems, and blocks have been systematically collected in a series of S IMULINK libraries. The toolbox was originally created as part of an autopilot design project. The current version 1.4, when applied in the context of the M ATLAB platform and its multitude of systems analysis and control design tools, can be considered an advance proof of concept of an integrated software environment for ight control system design, 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 starting point 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 M ATLAB Release 11 (M ATLAB 5.3 / S IMULINK 3.0), but it has been reported to work correctly with later M ATLAB releases as well. Although it has been built and tested on an MS W INDOWS system, the toolbox 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 for M ATLAB and S IMULINK (for detailed information, refer to the website of The Mathworks: http://www.mathworks.com) should be able to handle the FDC systems comfortably. Only if your computer is barely able to cope with the demands of M ATLAB itself it may run out of memory when performing intensive FDC simulations. The toolbox requires at least 2.7 MBytes of free space on your harddisk, although up to twice that amount of free space may be needed in practice, depending on the lesystem used and the amount of le slack for the relatively large number of small les. It is, however, highly recommended to have additional space available for data storage and possible future model enhancements. These hardware and software requirements may be changed for future versions of the toolbox. For the most up-to-date information, refer to the website of the FDC toolbox, http://www.dutchroll.com or http://www.dutchroll.org, and the README -le that is shipped with the software itself.
7.3
License Agreement
The FDC toolbox version 1.4 is distributed as Open Source software, licensed under the Open Software License (OSL), version 2.1 or later. A copy of this license has been included in appendix F and the software itself includes a at-text copy of the OSL. (Earlier versions of the toolbox have been distributed under slightly different licenses, which are now considered obsolete. Redistribution of those versions under the 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 you to modify the source code, and re-distribute modied les, provided the licensing terms are not altered. This licensing model was chosen to allow as many people as possible to freely use, change, and share this software. Unrestricted access to the source code was deemed essential, as one of the main features of this toolbox is its transparent design, which makes it easier to understand how to put the theory of ight dynamics modelling into practice, and which provides the exibility to change the tools and models if required. For more information about the philosophy behind open source software and licensing, 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 some reason, these licensing terms are not suitable or not acceptable for your particular situation, it is recommended to contact the author to see if a different licensing scheme can 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 le and path-notations in this report have been presented in MS-W INDOWS format. For different operating systems, use the appropriate substitutes. All screenshots and other examples have been created with M ATLAB Release 11 for W INDOWS. It is possible that newer M ATLAB and S IMULINK versions use a different menu structure, keyboard shortcuts, or default directories, and the referrals in this chapter to right-click context-menus may be valid for W INDOWS systems only. The FDC Toolbox is distributed via the FDC website (http://www.dutchroll.com or http://www.dutchroll.org). It has been packed into a ZIP archive an installer is not available. To install the FDC toolbox, the ZIP archive must be unpacked into an appropriate directory, and the FDC subdirectories must be appended to the M AT-
102
path by running a dedicated initialisation utility. The following instructions will guide you through this installation process:
LAB
1. Copy the archive le FDC14. ZIP into a temporary directory. 2. Create a suitable destination directory for the FDC toolbox. The recommended location is a subdirectory FDC14. ZIP within the TOOLBOX directory of M ATLAB but any other dedicated directory would do ne as well. For example, if M ATLAB itself has been installed into C :\ MATLAB , the recommended destination directory for the FDC toolbox would be C :\ MATLAB \ TOOLBOX \ FDC 14, but if you prefer something like K :\ MYTOOLS \ FDC 14 thats ne also. 3. Unpack FDC14. ZIP into this destination directory. Be sure to retain the FDC directory 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 W INZIP or 7 ZIP, will normally retain the directory structure by default.) 4. At this stage, it is recommended to read the documentation in the FDC subdirectory DOC. In particular, check README . TXT for important last-minute information (this le also contains a copy of these installation instructions), and COPYING . TXT and LICENSE . TXT for the terms of use. Other documentation les are CHANGELOG . TXT, which describes the major changes in the last few FDC versions, ROADMAP. TXT, which outlines past FDC developments and future plans, and CONTENTS . TXT, which contains a complete list of FDC les. 5. Start M ATLAB version 5.3 or later and use the command cd or chdir to go to the FDC directory specied above (from now on denoted as FDC root-directory). This has been illustrated in gure 7.1, where it is assumed that the FDC toolbox has been installed into the directory K :\ MYTOOLS \ FDC 14. 6. Type fdc at the command-line to run the FDC initialisation routine. The splash screen from gure 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 gure 7.3. 7. The toolbox will now be initialized by appending the FDC subdirectories to the M ATLAB-path. As shown in gure 7.3, you will be asked to verify the default FDC search-path: Path ok? (y=yes, n=no, s=suppress this message in the future). If you have followed the above instructions, it is normally sufcient to verify the location of the FDC root-directory; the option to change subdirectory names is meant 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 to the menu shown in gure 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 gure 7.3. 9. If the FDC path is correct, you can leave the directory-check window by answering the question from step 7 with y. This directory-check (and the directory
1 The splash screen can be disabled for future sessions by commenting-out the line containing the call fdc splash; in the le 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
104
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 answering with s instead.1 If this latter option is selected, the initialisation routine will ask for conrmation, as shown in gure 7.5. 10. Next, the welcome message from gure 7.6 will be shown to signal that the toolbox has been initialized. The FDC directories have now been appended to the M ATLAB path, so all FDC programs and models can now be opened directly from the command line, regardless of the current working directory. The main FDC library can be accessed by typing fdclib, while the on-line helples for FDC 1.4 can be shown in a webbrowser or the M ATLAB help browser by typing browse fdc. In addition, the FDC directories will be appended to the bottom of the list in the M ATLAB 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 M ATLAB command line by typing help <dirname> , where <dirname> is the name of the FDC rootdirectory or subdirectory.) Notice that the FDC directories will not be appended to the M ATLAB path permanently. After closing M ATLAB it will be necessary to repeat steps 5 to 10 from the above list again: start M ATLAB, change to the FDC root-directory, type fdc at the command-line, and verify the directory structure. This last step can be skipped for future FDC sessions by choosing the suppress option in step 8. Users who intend to use the FDC toolbox frequently, may nd it convenient to permanently append the FDC root-directory to the M ATLAB path. This can be achieved by manual editing of the M ATLAB system les PARDEF. M or STARTUP. M, or by means of the path browser, which can be started by typing editpath at the command-line. See the M ATLAB documentation for more information about the M ATLAB path [3]. In the remainder of this report we will assume that the toolbox has been properly initialized, so that all options are readily available from the command-line, regardless of the current working directory.
7.5
Uninstalling FDC 1.4
Although the toolbox does not include an uninstall utility, the uninstall process itself is straightforward: just delete the entire FDC 1.4 directory, including all subdirectories (however, be careful not to inadvertently delete important datales from the DATA directory, if you wish to use them later!). If the FDC directories have been permanently appended to the M ATLAB path by editing PATHDEF. M or STARTUP. M, it will also be necessary to remove the FDCrelated items from those initialisation les, either by hand, or by using the M ATLAB path browser. The FDC toolbox does not store any information in the Windows registry or in other directories, and involves no other system-dependencies.
it is desired to restore the directory check and editing features for later FDC sessions, the le must be deleted from the FDC root-directory. This will cause the FDC initialisation routine to assume that the toolbox is run for the rst time, and reset the FDC path to its default status.
FDCINIT. INI
1 If
106
7.6
The FDC directory structure
Lets take a closer look at the contents of the FDC toolbox, starting with an overview of its directory structure. The les from this toolbox have been organized in ten separate subdirectories: AIRCRAFT contains the nonlinear aircraft model Beaver, the main library FDCLIB, the aircraft model sublibraries FDCLIB1 till FDCLIB10, and the program MODBUILD, that denes the parameters for the aircraft model, APILOT contains several simulation models of the Beaver autopilot, and some related M ATLAB functions, DATA is used to store FDC datales (in particular *. TRI les, which are used to store trimmed ight conditions, *. LIN les, to store system matrices of linearized aircraft models, and *. DAT les, to store model parameters), DOC contains program documentation les (README-le, list of new features, list of features for future versions of the toolbox, a complete list of all les from the toolbox, and the software license documents), EXAMPLES contains some open-loop simulation models and M ATLAB demos that access the aircraft model for open-loop simulations, an analysis of the aerodynamic and propulsive models, and the computation of an elevator deection curve for trimmed ight conditions, HELP contains the HTML helples for the FDC models and programs, NAVIGATE contains the library NAVLIB and its sublibraries, which include models of the ILS and VOR radio-navigation systems, PROGRAMS contains the trim and linearisation routines, a tool for quick analysis of the properties of linear systems, routines for post-processing simulation results, load routines for model-initialisation and quick access to FDC datales, the HTML browse routine that forms part of the on-line help system, and some supporting routines to determine the screensize, display text-menus, convert numbers to strings in a nice lay-out, determine the data and help directories, and x states in the aircraft model, TOOLS contains the S IMULINK library FDCTOOLS, which includes several useful general-purpose blocks that cannot be found in the standard S IMULINK libraries, WIND contains the library WINDLIB and its sublibraries, which include models of steady wind and atmospheric turbulence.
7.7
The FDC model libraries
As we will see in the next section, the S IMULINK models in the FDC toolbox have a layered, modular structure. The subsystems and masked blocks that comprise these models have been arranged in a series of S IMULINK libraries. A single access-point to all libraries and simulation models is provided by the main library FDCLIB, shown in gure 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 provides links to the following libraries and models: the nonlinear six-degree-of-freedom models of the complete aircraft (the system 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 been included in the open-loop and closed-loop models of the FDC toolbox. Detailed descriptions about these libraries and simulation models will be provided in the next chapters. The sublibraries and models can be opened by double-clicking
108
Figure 7.8: Top-level of the system Beaver
the corresponding boxes in the main library window, or by right-clicking these boxes and selecting open in the context-menu. They can also be accessed directly from the M ATLAB command-line by typing their names in lower-case. For instance, the command navlib will open the navigation library NAVLIB, and apilot1 will open the autopilot model APILOT1.
7.8
Taking a closer look at the aircraft model
The complete nonlinear aircraft model is contained in the S IMULINK system Beaver, which can be accessed via FDCLIB, or directly from the command-line. A detailed description of this model can be found in chapter 8. Here we will use this model to explain the layered and modular structure of the S IMULINK systems, the use of block libraries, and the on-line help facilities for the FDC toolbox. A similar structure has been used for virtually all S IMULINK models from this toolbox. To open the system Beaver, double-click the block Complete system BEAVER in the FDCLIB window, or type beaver at the command-line. The top-level of this model has been shown in gure 7.8. This level handles the input/output functions of the aircraft model, sending simulation results to the M ATLAB workspace by means of To Workspace blocks, and providing Inport and Outport handles that allow M ATLAB programs to access this model. The actual system dynamics have been implemented in the subsystem Beaver dynamics and output equations.
7.9. Linking to S IMULINK libraries
109
Notice the three blocks with shadow borders (in reality, these blocks have been accentuated by a blue colour). The shadow indicates that some action will occur when these blocks are double-clicked. In this case, related help information will be displayed in your webbrowser or the M ATLAB help browser. The upper-left block is called a title block, which shows the blockname, the author, and the latest revision date; it has been linked to help information about the subsystem itself. Similar title blocks 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, the dialog window from gure 7.9 will be shown. The rst line below the window title provides the blockname, and indicates that we are dealing with a masked subsystem, that has been linked from a S IMULINK library. Directly beneath, a brief description about the block is given. Detailed information about the masked subsystem will be shown in a webbrowser or in the M ATLAB help browser if the Help button is clicked. The dialog window can be closed by clicking Cancel, which will cause S IMULINK to return to the system Beaver. Without further interaction from the user, the subsystem Beaver dynamics and output equations will remain active, which is indicated by four tiny black squares in its corners. The active status of the subsystem can be cycled by repeated single-clicking on the subsystem block (the tiny squares will disappear when 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 under the mask. This can be done in several ways: (i) right-click the block, and select Look under 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 unmask the block. Use whatever method you prefer. Unmasking the subsystem Beaver dynamics and output equations results in the opening of the new window shown in gure 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-left corner; double-clicking this block will reveal the same help information as the Help button from gure 7.9. The subsystem includes four masked blocks, which have been linked from a S IMULINK library, and ve subsystems without a mask interface. To indicate that these unmasked subsystems also have library links, they have been highlighted with a light-blue colour (shown as a grey colour in gure 7.10).
7.9
Linking to S IMULINK libraries
S IMULINK libraries enable users to copy blocks from external libraries into the simulation models, and automatically update these blocks when the source libraries change. In fact, the model only contains a placeholder for the block, instead of the block itself, with a link referring to the applicable source library that contains the actual block contents. This promotes the re-use of existing blocks, and prevents inadvertent proliferation of multiple versions of the same block (some being properly updated, some inadvertently remaining unchanged). To demonstrate the use of the libraries in the FDC toolbox, we will take a closer look at the block Gravity, which can be found slightly left of the center of gure 7.10. Double-clicking this block results in the mask-dialog from gure 7.11. As we have seen before in gure 7.9, the mask-dialog includes a short description of the block, a
110
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 S IMULINK 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
112
note that the block has been masked, and a note that the block has been linked from a library. In this case, there is also a parameter eld, although it has been locked because the parameter denition for this particular block can only be changed in the library in which it is dened. It is possible to quickly jump from a block in a model (actually: its placeholder) to the corresponding library by: (i) right-clicking the block and selecting Go To Library Link from the context-menu, (ii) activating the block and selecting Go To Library Link from the Edit menu, or (iii) activating the block and pressing Ctrl + L . If we apply this method to the Gravity block, gure 7.12 will be opened, with the Gravity block being activated as shown in the gure. Of course, if you know the name of the library, it is also possible to open it directly from the command-line. In this example typing fdclib4 or double-clicking the Gravity and wind forces button in the main FDC library will open the library shown in gure 7.12. The internal structure of this block can again be shown by unmasking it rst. This yields gure 7.13, which shows the deepest level of this block, i.e. the level in which the actual equations are evaluated. The expressions within the individual Fcn blocks will probably look rather cryptic at rst sight, but once one knows the meaning of the input and output signals (as explained in the next chapters and the on-line help information) and the part of the theory on which these equations are based, 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 a block: 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 not be edited within the model. Libraries are read-only or locked by default, which means that it is not possible to change any elements in library blocks, unless the library is released rst by selecting the Unlock Library option in the Edit menu. If the user does try to edit a locked library, or manipulate a linked block directly from within a model, the error message from gure 7.14 will be displayed. It is not possible to edit the contents of a linked block within a model, because the actual block contents are included in the library only. However, it is possible to break a library link after copying a block from the library, by selecting the option Break Library Link in the Edit menu. In that case, the placeholder containing the library link will be overwritten with the blocks actual contents effectively creating a clone of the block, and editing the block within the model will become possible. Since this breaks the library link, it will obviously not affect the contents of the library itself. Unfortunately, the placeholder containing the library link will look exactly the same as the original block in the library; the only visual difference is the link indication in the mask-dialog, and that is only present if a mask dialog exists in the rst place. Some subsystems from the FDC toolbox do not have a mask-dialog, even though they have been linked from a library. To make the user aware of the library links in those cases, such linked, yet unmasked subsystems have been highlighted with a light-blue colour. Please be very careful when editing existing blocks in the FDC libraries: since they may be called by several other models, it is not recommended to alter their input/output denitions (e.g. increase the number of outputs), or change the names of blocks within a library. The latter is important, because library links are dened
7.10. Summary of the model and library structure
113
by reference to the blocknames (changing blocknames in models doesnt matter, because in that case only the name of the link placeholders is modied). A save method to implement big changes is to create a clone of the original block rst, by copying the block and breaking its library link.
7.10
Summary of the model and library structure
Lets summarize these last two sections before proceeding. All FDC models have a modular 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 that can provides short block-information, a help-button with a link to extensive blockinformation, an indication that tells us whether we are dealing with the actual block or a linked copy, and possibly also one or several parameter elds. It is possible to zoom in to masked subsystems by using the Look Under Mask option in the Edit or context menus to unmask these blocks. Almost all subsystems from the FDC models have been sorted in libraries. The link status of masked subsystems is indicated in their mask-dialog window; linked subsystems which have not been masked are distinguished by a light-blue background colour. Direct editing of these blocks within the models in which they are applied is not possible, except when the library link is broken rst, which will cause the editing to be limited to the new, local, copy of the block. Editing blocks within a library is possible after unlocking the library rst. The easiest way to open the required library is to follow the library link from the model, but it is also possible to open libraries directly from the command-line. In addition, all FDC libraries can also be accessed via the main library FDCLIB. Relevant help information for masked blocks will be shown in a webbrowser or in the M ATLAB help browser if the Help button is clicked in the mask-dialog. Doubleclicking the title block of a model or subsystem will have the same effect, whether the 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 lightblue background colour for subsystem blocks has been used to indicate that those subsystems are contained in a library. In addition, the following colours have been used: black-on-cyan (with shadow border): used for button-blocks, i.e. blocks that will start a related M ATLAB utility when double-clicked, black-on-yellow (no shadow border): used to indicate places where data is sent from the S IMULINK systems to the M ATLAB workspace black-on-yellow (with shadow border): used to highlight signal switches that require user-interaction,
114
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 webbrowser or the M ATLAB help browser when double clicked; also used for the Mux blocks in the rst level of the aircraft model, to indicate that double-clicking these blocks will 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 will be discussed later in chapter 15.
7.12
Some cautions
Although you are encouraged to use, modify, and extend the FDC models and tools for your own experiments, it is important to be aware of the many interactions between the various models, libraries, tools, and helples, which may not always be obvious. As noted before, be especially careful when changing blocknames and/or editing existing blocks in libraries, to prevent inadvertently breaking library links or mismatching connections. When in doubt, it is safer to create a clone of the original block 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 problems for the open-loop simulation models, the autopilot models, the interface to the aircraft trimming program, and the workspace input/output functions. Although it is not difcult to correcting these problems, it does require a lot of attention, especially 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 keep safety copies of the original les on your system, which will allow you to quickly restore errors when necessary (of course, it is always possible to re-install the complete package if things really go wrong). It is also recommended to use distinct lenames for your own adaptations of the FDC models and tools to prevent possible mix-ups in the future. Dont let that stop you from experimenting, though: this is Open Source software for a reason! Users who now decide to start working with the toolbox right away should not be surprised if they are, at times, confronted with some disturbing error messages. Over the years the programs have been equipped with some basic error-trapping subroutines, but that doesnt make this toolbox entirely error-proof. If you are not keen on reading before experimenting, it is recommended to at least study the relevant helples and read chapter 13, which contains some examples of the practical use 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 S IMULINK implementation of the aircraft model, the wind and turbulence models, and the radio-navigation models will be discussed in 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 blocks for subsystems which dont contain any individual equations), lists of input and output signals1 , an overview of the block or subsystem parameters, and an overview of important connections to other blocks or subsystems. The description of the elements from the aircraft model in chapter 8 also includes the path in the aircraft model, starting with the interface level Beaver level 1, and the location of the block-library containing the element, starting with FDCLIB. For the description of the wind and turbulence elements in chapter 9 and the radionavigation elements in chapter 10 the locations in the main library FDCLIB and the wind or navigation libraries Windlib or Navlib will be included. Chapters 11 and 12 describe the analytical functions and support utilities for the FDC toolbox. Together with the model reference chapters, this completes the reference guide for the basic FDC models and tools. Practical applications of the toolbox will be elaborated later in chapter 13, and in chapters 14 and 15, which describe a case-study of the Beaver autopilot.
1 To avoid signal clutter, the FDC models make extensive use of vector signals. If a vector signal is used as input to a block, this doesnt necessarily mean that all elements from this vector are actually needed; 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 the installation process and the general architecture of the models and libraries. In this chapter we will take a closer look at the dynamics model of the DeHavilland DHC-2 Beaver aircraft, which is the core element of the FDC toolbox. First, the structure of this 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 described in alphabetical order. Hereafter, chapters 9 and 10 will provide similar information for the wind, turbulence, and radio-navigation models.
8.1
The aircraft model and its subsystem equivalents
The S IMULINK implementation of the nonlinear aircraft model has been based on the block-diagram structure from gure 3.2 of chapter 3. The resulting S IMULINK model has been shown in gure 8.1. This model differs from gure 3.2 in that it gathers all output signals on the right-hand side of the block-diagram, which results in a stairway-like structure in which subsequent blocks are shifted to the right and downwards. Also, the axis-transformations have been integrated in the forces and moments blocks, and a separate block for computing additional observation variables has been included directly below the subsystem Aircraft equations of motion. But despite these differences, the overall structure of gure 3.2 should be clearly recognisable in the S IMULINK model. Apart from the aerodynamic and propulsive forces, all elements from gure 3.2 are independent of the airplane under consideration. This is also true for the S I MULINK model from gure 8.1, with the exception of a single aircraft-dependent correction block xdotcorr (Beaver) that is contained in the subsystem Aircraft Equations of Motion (Beaver). Notice how all aircraft-dependent elements (which have currently been elaborated for the Beaver aircraft) have been distinguished by their sufx (Beaver). From left to right and from top to bottom we can distinguish the following blocks and subsystems in the S IMULINK model from gure 8.1: Airdata Group. This subsystem evaluates airdata equations and computes important 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 solve the equations of motion). Aerodynamics Group (Beaver), Engine Group (Beaver), Gravity, and Fwind. These subsystems determine the individual contributions to the external forces and moments upon the airplane. Not surprisingly, the aerodynamic and propulsive forces and moments are currently valid for the Beaver aircraft only. FMsort. This block computes the body-axes components of the resulting forces and moments, and it stores the results in a separate force vector and moment vector. Aircraft Equations of Motion (Beaver). The core element of the nonlinear aircraft model. This subsystem rst determines the time-derivative of the state vector by evaluating the differential equations from section 2.5. Next, this vector is sent through an Integrator block, to nd the state vector itself. The subsystem is aircraft-dependent in that it contains a block which corrects the time-derivative of 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 and the description of the block xdotcorr (Beaver) for more information). Additional Outputs. This subsystem computes some additional observation signals that are not needed to solve the equations of motion, yet may be useful for post-simulation analysis of the airplane responses. Hlpfcn. This block computes some frequently used sines and cosines of angular values from the state vector. It has been located in the internal feedback-loop of the aircraft model, because of the trivial nature of the results. The feedbackloop itself is necessary, because the external forces and moments that determine the movements of the airplane are themselves dependent upon the airplane motions. On the left-hand side of gure 8.1, we see the external inputvectors uaero and uprop , which contain the control inputs to the aerodynamic and engine models (control surface deections, engine RPM, and engine manifold pressure). The third inputvector is uwind , which is used to account for unsteady atmosphere; it contains the wind velocity components along the aircrafts body-axes and the time-derivatives of these velocities. This vector can include both deterministic stochastic terms (i.e. wind and atmospheric turbulence). See table D.3 in appendix D for the exact denitions of the input vectors. The output vectors from the blocks in gure 8.1 are all gathered on the left-hand side of this model. In total there are 18 output vectors, which have been dened in table D.2 of appendix D. In order to handle the input/output functions for this ight simulation model, an additional system level was introduced. This system level makes sure that the relevant input and output signals are logged into the M ATLAB workspace, and it provides connections for external models and access points for M ATLAB functions. In the system hierarchy, this interface level forms an additional layer on top of the actual aircraft model from gure 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
yatm yad1 x yad2 yad3 x uaero yad1 ydl Caero FMaero
Airdata Group 1 uaero
18 yad3
17 yad2
16 yad1
15 yatm
Aerodynamics Group (Beaver) 2 uprop

x uprop yatm yad1 ypow Cprop FMprop
11 FMaero
9 Caero
5 ydl
Engine Group (Beaver) Gravity Gravity forces Fwind W ind forces FMsort Add/sort forces and moments
Ftot Mtot uwind yatm yhlp x
1
12 FMprop
10 Cprop
7 ypow
13 Fgrav 14 Fwind 1 x
3 uwind
xdot
1
ybvel
Aircraft Equations of Motion (Beaver)

x xdot yhlp Ftot Fgrav yfp yuvw yacc
3 ybvel
2 xdot
Additional outputs hlpfcn yhlp xdot x (co)sines of alpha, beta, psi, theta, phi
8 yacc
4 yuvw
6 yfp
Figure 8.1: Block-diagram of the main level of the aircraft model (Beaver Level 2)
time Clock In To Workspace To Workspace Out To Workspace 2 alpha 4 p 6 r 8 theta
Mux
1 V 3 beta 5 q 7 psi 9 phi 11 ye
1 deltae 3 deltar
Mux click 2x for info! 2 deltaa

Mux
Mux Double-click for info!
x uaero
Demux
4 deltaf
uprop
5 n 7 uw 9 ww 11 vwdot
6 pz 8 vw 10 uwdot
DeHavilland DHC-2 Beaver dynamics and output equations
10 xe 12 H
xdot
Demux
Mux
uwind
ydl
Demux
12 wwdot
15 qc/V
13 Hdot 14 pb/2V 16 rb/2V
Figure 8.2: Block-diagram of the interface level of the aircraft model (Beaver Level 1)
120
ered the main level of the airplane model, because it contains the actual system dynamics. The full name of this subsystem is DeHavilland DHC-2 Beaver dynamics and 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 model of the Beaver aircraft (called Beaver), and two subsystem equivalents of this model. The stand-alone model is used for model analysis from the M ATLAB environment (simulations, trimming, linearisation), while the subsystem equivalents are intended to be used as subsystems within larger simulation models, such as the autopilot models from chapter 15. All three variants call the subsystem Beaver Level 2, and they all use the same input denitions. The stand-alone model and the rst subsystem equivalent use the I/O structure from gure 8.2; the second subsystem equivalent uses a slightly different output structure, creating two output vectors instead of 16 scalar output signals. From gure 8.2 we can see that all inputs and outputs are sent to the M ATLAB workspace, together with a clock signal that provides a corresponding time reference for postsimulation processing (e.g. trajectory plotting). Only a small subset of the outputs has been connected to the scalar Outport blocks in Beaver Level 1, visible on the righthand side of gure 8.2.1 The current choice of output signals provides sufcient information 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 individual blocklibraries, 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 also be accessed directly by typing fdclibi in the command-line, where i represents the number of the blocklibrary according to the list above. In addition, FDCLIB contains a direct link to the system Beaver (the stand-alone version of the aircraft model), and a link to a sublibrary containing the subsystem equivalents of Beaver. The stand-alone model and this sublibrary can also be opened directly from the command-line by typing beaver or fdclib10, respectively. In gure 8.3, the main FDC library has been shown, with highighted links to the aircraft blocklibraries and the complete aircraft models. FDCLIB can be opened from the command-line by typing fdclib.
1 The reason for using scalar Inport and Outport blocks in the interface level of the aircraft model was that older versions of S IMULINK did not allow the use of vector inputs or outputs in top-levels of systems. 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 description of all blocks and subsystems from the nonlinear aircraft model, i.e. the system Beaver or one of its subsystem equivalents. The blocks have been sorted in alphabetical order; their locations have been referenced with respect to the system Beaver and the main FDC library FDCLIB.
122

Beaver level 1 / Beaver level 2 / Aircraft Equations of Motion / 12 ODEs Main FDC library / Equations of motion
12 ODEs
Type Aircraft-independent subsystem, essential for solving the equations of motion. The subsystem is not masked. Description The subsystem 12 ODEs contains the twelve non-linear Ordinary Differential Equations that describe the aircraft dynamics. The equations are valid for all rigid bodies, assuming a at, non-rotating Earth; see chapter 2 for a detailed theoretical discussion. The time-derivatives of the twelve state variables are nonlinear functions of the state variables themselves and of the external forces and moments. The latter depend upon the state variables, external control inputs, and external disturbances affecting the airplane. Subsystems and/or blocks The subsystem 12 ODEs contains four blocks:
Vabdot pqrdot Eulerdot xyHdot
computes time-derivatives of true airspeed, angle of attack, and sideslip angle, computes time-derivatives of the angular velocities along the body-axes of the aircraft, computes time-derivatives of the Euler angles, computes time-derivatives of the coordinates and the altitude above sea-level.
Inputs x Ftot Mtot yhlp ybvel
= = = =
[ V p q r xe ye H ] T state vector, x [ Fx Fy Fz ]T total external forces, Ftot [ L M N ]T total external moments, Mtot [ cos sin cos sin tan sin cos sin cos sin cos ]T
frequently used sines and cosines, yhlp
= [ u + uw v + v w w + ww
]T
body-axes velocity components plus wind, ybvel
Outputs x = [ 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 direct contribution of to the aerodynamic side force Ya . This correction is taken into account by the block xdotcorr (Beaver), which has been described later. Parameters The block Vabdot reads the parameter vector GM1 from the M ATLAB workspace; the block pqrdot requires the matrix GM2. The denitions of GM1 and GM2 can be found in appendix C. These variables can be loaded from the le AIRCRAFT. DAT, using the utility DATLOAD (see section 12.4.2). If this datale has somehow inadvertently been deleted, it can be re-created by running the program MODBUILD (see section 12.6.1). Connections in: 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 block xdotcorr (Beaver). Type browse 12odes at the command-line for on-line help.
123
Beaver level 1 / Beaver level 2 / Additional Outputs / Accel Main FDC library / Other (output-) equations
Accel
Type Aircraft-independent masked subsystem block, not essential for solving the equations of motion. Description The block Accel computes some accelerations and specic forces (outputs of accelerometers) in the aircrafts center of gravity. These output variables are useful for several FCS design tasks, e.g. turn-coordination by means of feedback of the specic force along the YB -axis, or manoeuvre load limiting. However, these variables are not required to actually solve the equations of motion themselves! Computing accelerations outside the center of gravity will require additional terms, which are not taken into account in this block; refer to ref.[14] for more details. Equations The equations used by the block Accel have been discussed in some more detail in section 3.6.
Kinematic accelerations a x,k , ay,k , and az,k along the body-axes, measured in the vehicles c.g.: 1 Fx a x,k = (u + qw rv) = g0 W Fy 1 ay,k = (v + ru pw) = g0 W 1 Fz az,k = (w + pv qu) = g0 W These accelerations are measured in units of g which explains why the terms have been divided by g0 . W = m g is the total weight of the aircraft, measured in [N]. Note: the kinematic accelerations differ from the body-axes velocity rates u, v, and w, which are computed in the block uvwdot, because the latter do not contain the angular and translational velocity cross-product terms. Outputs of body-axis accelerometers (specic forces) A x , Ay , and Az , measured at the vehicles c.g.:
A x = a x,k + sin = ( Fx Xgr ) / W Ay = ay,k cos sin = ( Fy Ygr ) / W Az = az,k + cos cos = ( Fz Zgr ) / W These specic forces are also measured in units of g. Inputs Ftot Fgrav Outputs yacc
= [ Fx Fy Fz ]T = [ Xgr Ygr Zgr ]T = [ A x Ay Az a x,k ay,k az,k ]T
total external forces, Ftot gravity forces, Fgrav
specic forces and accelerations, yacc
Parameters Accel needs the parameter vector GM1 to be present in the M ATLAB workspace, in order to 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 in simulations). The denition of GM1 can be found in appendix C. GM1 can be loaded from the le AIRCRAFT. DAT, using the utility DATLOAD (see section 12.4.2). If this datale
124
has somehow inadvertently been deleted, it can be re-created by running the program MODBUILD (see section 12.6.1). Connections in: 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.
125
Beaver level 1 / Beaver level 2 / Additional Outputs Main FDC library / Other (output-) equations
Additional Outputs
Type Aircraft-independent subsystem, essential for solving the equations of motion. The subsystem is not masked. Description The subsystem Additional Outputs contains some useful output equations which are not required to solve the state equations, and which do not logically t in other subsystems from 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 to be 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 aircraft model.1 Subsystems and/or blocks The subsystem Additional Outputs contains three blocks:
Accel Flpath uvwdot
computes specic forces (outputs of accelerometers) and kinematic accelerations, computes some ight-path related variables, computes the time-derivatives of the body-axes velocity components.
Inputs x x yhlp Ftot Fgrav Outputs yfp yuvw yacc
= [ V p q r xe ye H ] T state vector, x T = [ V p q r xe ye H ] time-derivative of state vector, xdot = [ cos sin cos sin tan sin cos sin cos sin cos ]T = [ Fx Fy Fz ]T = [ Xgr Ygr Zgr ]T = [ fpa ]T = [ u v w ]T = [ A x Ay Az a x,k ay,k az,k ]T
frequently used sines and cosines, yhlp total external forces, Ftot gravity forces, Fgrav
ight-path variables, yfp time-derivatives of body-axes velocities, yuvw specic forces and accelerations, yacc
Parameters The block Accel reads the parameter vector GM1 from the M ATLAB workspace; the block Flpath requires the initial value of the state vector, xinco. GM1 can be loaded from the le AIRCRAFT. DAT, using the utility DATLOAD (see section 12.4.2); its denition can be found in appendix C. If this datale has somehow inadvertently been deleted, it can be re-created by running the program MODBUILD (see section 12.6.1). The initial value of the state vector can be computed using the aircraft trim program ACTRIM (see section 11.1), or loaded from le using the utility TRILOAD (see section 12.4.2).
1 Since the outputs from Additional Outputs are not involved in the solution of the state equations themselves, the use of time-derivatives of state variables within this subsystem does not yield algebraic loops (see section section 6.4.1). However, if outputs from this subsystem are fed back to the inputside of the aircraft model, e.g. via an autopilot control loop, an algebraic loop may inadvertently be created. This can cause simulations to slow down considerably, and such an algebraic loop may be too complicated for S IMULINK to solve altogether. For this reason, feeding back additional outputs into the aircraft model should be prevented.
126
Connections in: x comes from the block Integrator; x comes from xx; 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 any other block in the aircraft model. Type browse moreouts at the command-line for on-line help.
127
Beaver level 1 / Level 2 / Aerodynamics Group (Beaver) Main FDC library / Aerodynamics
Aerodynamics Group (Beaver)
Type Aircraft-dependent subsystem, essential for solving the equations of motion. The subsystem is not masked. Description The subsystem Aerodynamics Group (Beaver) contains blocks for computing the aerodynamic forces and moments that act on the aircraft under consideration. In this case the aerodynamic model is valid for the DHC-2 Beaver aircraft. It uses model data from ref.[34] (see also section 3.3.1). Notice that the subsystem Aerodynamics Group does not compute propeller slipstream related contributions to the aerodynamic forces and moments; that task is performed by the subsystem Engine Group instead. Subsystems and/or blocks The subsystem Aerodynamics Group (Beaver) contains three blocks:
Aeromod
Dimless FMdims
computes dimensionless aerodynamic force and moment coefcients for the aircraft under consideration (currently Aeromod contains the aerodynamic model of the Beaver from ref.[34], which has been described in section 3.3.1), computes dimensionless angular velocities, converts the dimensionless force and moment coefcients to dimensional forces and moments.
Since the block Aeromod (Beaver) is aircraft-dependent, it needs to be replaced if the user wants to implement a model of a different aircraft in the FDC framework. However, if the new aircraft model also uses different denitions of the non-dimensional angular velocities, it may be more convenient to replace the complete subsystem Aerodynamic Group instead. Either way, this modular construction allows the user to build a comprehensive S IMULINK library of aerodynamic models. Inputs x = [ V p q r xe ye H ] T state vector, x T uaero = [ e a r f ] aerodynamic control inputs, uaero T yad1 = [ a M qdyn ] basic airdata variables, yad1 Outputs
rb ydl = [ 2V V 2V ]T dimensionless angular velocities, ydl T Caero = [ CXa CYa CZa Cla Cma Cna ] aerodynamic force and moment coefcients, Caero FMaero = [ Xa Ya Za L a Ma Na ] T dimensional aerodynamic forces and moments, FMaero pb qc
Parameters The block Dimless and the block FMdims read the parameter-vector GM1 from the M ATLAB workspace; the block Aeromod (Beaver) needs the parameter-matrix AM. The denitions of these variables can be found in appendix C. The variables can be loaded from the le AIRCRAFT. DAT, using the utility DATLOAD (see section 12.4.2). If this datale has somehow inadvertently been deleted, it can be re-created by running the program MODBUILD (see section 12.6.1). Connections in: x comes from the block Integrator; uaero is an external input vector containing aerodynamic 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.
128

Beaver level 1 / Beaver level 2 / Aerodynamics Group / Aeromod (Beaver) Main FDC library / Aerodynamics
Aeromod (Beaver)
Type Aircraft-dependent masked subsystem block, essential for solving the equations of motion. Description The block Aeromod (Beaver) contains the aerodynamic model of the DHC-2 Beaver aircraft. The model is based on ref.[34], which expresses the aerodynamic forces and moments in terms of nonlinear polynomial functions of state variables and external aerodynamic control inputs. This block needs to be updated if one wishes to implement a model of a different aircraft within the FDC framework. Thanks to the black-box structure of Aeromod, it is relatively easy to change the structure of the equations if necessary, e.g. to incorporate look-up table functions, which often dene the aerodynamic equations for different airplane models. Note: Aeromod (Beaver) does not take into account contributions to the forces and moments due to the propeller slipstream. This is done in the masked subsystem block Engmod within the subsystem Engine Group. Equations The aerodynamic force and moment coefcients of the Beaver are expressed in terms of nonlinear polynomial functions of the state variables and aerodynamic control inputs. The model includes longitudinal-lateral cross-coupling effects, as well as unsteady aerodynamics, but it does not take into account the inuence of compressibility, as airspeed is assumed to be low [34]. The equations have been described in more detail in section 3.3.1.
Coefcients of the aerodynamic forces and moments, measured in the body-xed reference frame: qc CXa = CX0 + CX + CX 2 2 + CX 3 3 + CXq + CXr r + CX f + CX f f f V rb b pb CYa = CY0 + CY + CYp + CYr + CYa a + CYr r + CYr r +CY 2V 2V 2V qc CZa = CZ0 + CZ + CZ 3 3 + CZq + CZe e + CZ 2 e 2 + CZ f + CZ f e f f V rb pb + Clr + Cla a + Clr r + Cla a Cla = Cl0 + Cl + Cl p 2V 2V rb qc Cma = Cm0 + Cm + Cm2 2 + Cmq + Cme e + Cm 2 2 + Cmr + Cm f f V 2V pb rb qc Cna = Cn0 + Cn + Cn p + Cnr + Cna a + Cnr r + Cnq + Cn 3 3 2V 2V V
The coefcients of the polynomials represent the stability and control derivatives of the Beaver; they have been listed in table B.3 of appendix B. A closer look at the internals of the block Aeromod (Beaver) reveils that the polynomial evaluation has been implemented in practice by means of a multiplication of the vector: 1 2 3 2 3 pb qc rb e a r f r a e 2 0 2V V 2V
T
with the constant parameter matrix AM in which the stability and control derivatives of the Beaver are contained. Notice that the direct contribution of the time-derivative of the sideslip angle to the aerodynamic side-force coefcient CYa has not been taken into account in this block: the
129
last element of the multiplication vector equals zero instead of b/2V, i.e. the bracketed term in the CYa equation is neglected by Aeromod (Beaver)! This was necessary in order to prevent the equation from becoming implicit, which would have yielded an algebraic loop in the simulation model (see section 6.4.1). The error which results from neglecting this term is corrected in the separate block xdotcorr. Inputs x uaero ydl Outputs Caero
= [ V p q r xe ye H ] T = [ e a r f ]T pb rb = [ 2V qc 2V ]T V = [ CXa CYa CZa Cla Cma Cna ]T
state vector, x aerodynamic control inputs, uaero dimensionless angular velocities, ydl
aerodynamic force and moment coefcients, Caero
Parameters The block Aeromod reads the parameter matrix AM from the M ATLAB workspace. AM contains the stability and control coefcients of the Beaver; see appendix C for its exact denition. This matrix can be loaded from the le AIRCRAFT. DAT, using the utility DATLOAD (see section 12.4.2). If this datale has somehow inadvertently been deleted, it can be re-created by running the program MODBUILD (see section 12.6.1). Connections in: 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.
130

Level 1 / Level 2 / Aircraft Equations of Motion Main FDC library / Equations of Motion
Aircraft Equations of Motion (Beaver)
Type Aircraft-independent subsystem, except for the block xdotcorr (Beaver), essential for solving the equations of motion. The subsystem is not masked. Description The subsystem Aircraft Equations of Motion (Beaver) contains the generic nonlinear sixdegree-of-freedom rigid-body equations of motion. It determines the time-derivatives of the state variables from the aircraft model, and the time-trajectories of the state variables themselves. Aircraft Equations of Motion (Beaver) contains one aircraft-dependent element: the block xdotcorr (Beaver) is needed to correct the time-derivative of the sideslip angle for the implicit nature of the sideforce equation in the aerodynamic model. Because of this, this subsystem is not entirely aircraft-independent; the current implementation has been tailored to the DeHavilland DHC-2 Beaver. Subsystems and/or blocks The subsystem Aircraft Equations of Motion (Beaver) contains two blocks:
uvw xdotcorr
computes the body-axes velocity components as a function of the true airspeed, angle of attack, and sideslip angle, applies corrections to the time-derivatives of the state variables in order to take into account the implicit nature of the aerodynamic forces and moments model (the current implementation is valid for the Beaver model, where the timederivative 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 state variables in terms of the external forces and moments, and the state variables themselves.
An Integrator-block is used determine the time-trajectories of the state variables as a function of their time-derivatives and initial condition. Inputs Ftot Mtot uwind yatm yhlp Outputs x x ybvel
= [ Fx Fy Fz ]T = [ L M N ]T
= [ uw vw ww uw vw ww ] T
total external forces, Ftot total external moments, Mtot wind velocity components along body-axes and their time-derivatives, uwind basic atmospheric properties, yatm
= [ ps T g ] T
= [ cos sin cos sin tan sin cos sin cos sin cos ]T
= [ V p q r xe ye H ] T = [ V p q r xe ye H ] T = [ u v w ]T
state vector, x time-derivative of state vector, xdot body-axes velocity components, ybvel
Parameters The block xdotcorr (Beaver) reads the parameter matrix AM and the vector GM1 from the M ATLAB workspace. The subsystem 12 ODEs needs the parameter vector GM1 and the matrix GM2. The denitions of these variables can be found in appendix C. The variables
131
can be loaded from the le AIRCRAFT. DAT, using the utility DATLOAD (see section 12.4.2). If this datale has somehow inadvertently been deleted, it can be re-created by running the program MODBUILD (see section 12.6.1). The block Integrator requires the initial value of the state vector, xinco, which can be computed using the aircraft trim program ACTRIM (see section 11.1), or loaded from le using the utility TRILOAD (see section 12.4.2). Connections in: Ftot and Mtot come from FMsort; uwind is an external input containing wind and turbulence velocities and their time-derivatives; yatm comes from Atmosph; yhlp comes from Hlpfcn. out: x, which leaves the block Integrator, is connected to many other blocks in the air craft model; x from xx is connected to Accel, Flpath, and uvwdot; ybvel from uvw is connected to xyHdot. Type browse eqmotion at the command-line for on-line help.
132

Beaver level 1 / Beaver level 2 / Airdata Group / Airdata1 Main FDC library / Airdata, atmosphere
Airdata1
Type Aircraft-independent masked subsystem block, essential for solving the equations of motion. Description The block Airdata1 is used to compute some essential airdata variables. This information is usually required to be able to compute the aerodynamic and propulsive forces and moments, and hence, to solve the equations of motion. For the Beaver model, only the dynamic pressure qdyn is actually needed to solve the state equations, but models of faster ying aircraft usually also require the Mach number M. Other airdata (-related) equations have been implemented in the blocks Atmosph, Airdata2, and Airdata3. Equations The equations used by the block Airdata1 have been discussed in more detail in section 3.5.
Dynamic pressure qdyn , [kg m2 ]:

1 qdyn = 2 V 2
Speed of sound a, [ms1 ]:

a= RT where = 1.4 is the ratio of specic heats of air with constant pressure and constant volume, respectively, and R = R a /M0 = 287.05 JK 1 kg1 is the specic gas constant of the air (R a = 8314.32JK 1 kmol1 is the molar gas constant, and M0 = 28.9644 kg kmol1 is the molecular weight of the air at sea level).
Mach number M, [ ]: V M= a Inputs x = [ V p q r xe ye H ] T yatm = [ ps T g ] T

Outputs yad1
state vector, x basic atmospheric properties, yatm
= [ a M qdyn ]T
basic airdata variables, yad1
Parameters All parameters for Airdata1 are dened within the block itself; Airdata1 does not use any parameters from the M ATLAB workspace. Connections in: 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.
133
Airdata2
Type Aircraft-independent masked subsystem block, in general not required for solving the equations of motion. Description The block Airdata2 is used to compute the impact pressure qc , calibrated airspeed Vc , and equivalent airspeed Ve . While these airdata parameters are important for certain applications (e.g. for analysing windtunnel measurements or ight tests), they are generally not required to solve the equations of motion. Therefore, in principle, Airdata2 can safely be deleted from the S IMULINK model without affecting the solutions of the ODEs (although this would introduce practical problems, due to broken connections). The equations from this block are independent of the aircraft under consideration. Other airdata (-related) equations have been implemented in the blocks Atmosph, Airdata1, and Airdata3. Equations The equations used by the block Airdata2 have been discussed in more detail in section 3.5.
Impact pressure qc , [Nm2 ]:

qc = ps 1 2 1+ M 2
1
where = 1.4 is the ratio of specic heats of air with constant pressure and constant volume respectively.
Calibrated airspeed Vc , [ms1 ]: 2 p0 qc Vc = 1+ 1 0 p0
where p0 = 101325 Nm2 is the air pressure at sea level, and 0 = 1.225 kgm3 is the air density at sea level. Equivalent airspeed Ve , [ms1 ]: Ve = V Inputs yatm yad1 Outputs yad2 = 0 2qdyn 0
basic atmospheric properties, yatm basic airdata variables, yad1
= [ ps T g ] T = [ a M qdyn ]T = [ qc Ve Vc ]T
additional airdata (-related) variables, yad2
Parameters All parameters for Airdata2 are dened within the block itself; Airdata2 does not use any parameters from the M ATLAB workspace. Connections in: yatm comes from the block Atmosph; yad1 comes from Airdata1. out: yad2 is not connected to any other block in the aircraft model. Type browse airdata2 at the command-line for on-line help.
134

Airdata3
Type Aircraft-independent masked subsystem block, in general not required for solving the equations of motion. Description The block Airdata3 is used to compute the Reynolds number Rc , which refers to the mean aerodynamic chord of the aircraft, the Reynolds number per unit length Re , and the total temperature Tt . While these airdata parameters are important for certain applications (e.g. for analysing windtunnel measurements or ight tests), they are generally not required to solve the equations of motion. Therefore, in principle, Airdata3 can safely be deleted from the S IMULINK model without affecting the solutions of the ODEs (although this would introduce practical problems, due to broken connections). The equations from this block are independent of the aircraft under consideration. Other airdata (-related) equations have been implemented in the blocks Atmosph, Airdata1, and Airdata2. Equations The equations used by the block Airdata3 have been discussed in more detail in section 3.5.
Total temperature Tt , [K]:

Tt = T 1 + 1 2 M 2
Reynolds number Rc , [ ]: Vc Rc = Reynolds number per unit length Re , [m1 ]: V Re =

Inputs x yatm yad1 Outputs yad3
= [ V p q r xe ye H ] T = [ ps T g ] T = [ a M qdyn ]T = [ Tt Re Rc ]T
state vector, x basic atmospheric properties, yatm basic airdata variables, yad1
additional airdata (-related) variables, yad3
Parameters The block Airdata3 reads the parameter vector GM1 from the M ATLAB workspace in order to extract the mean aerodynamic chord c. The denition of GM1 can be found in appendix C. The variable can be loaded from the le AIRCRAFT. DAT, using the utility DATLOAD (see section 12.4.2). If this datale has somehow inadvertently been deleted, it can be re-created by running the program MODBUILD (see section 12.6.1). Connections in: x comes from the block Integrator; yatm comes from Atmosph; yad1 comes from Airdata1. out: yad3 is not connected to any other block in the aircraft model. Type browse airdata3 at the command-line for on-line help.
135
Beaver level 1 / Beaver level 2 / Airdata Group Main FDC library / Airdata, atmosphere
Airdata Group
Type Aircraft-independent subsystem, part of which is essential for solving the equations of motion. The subsystem is not masked. Description The subsystem Airdata Group is used to compute airdata (-related) variables. Some of these data are required to solve the equations of motion, while other data is provided as additional nice to know information. Subsystems and/or blocks The subsystem Airdata Group contains four blocks:
Atmosph
computes basic atmospheric properties (air-temperature, pressure, density) using the ICAO Standard Atmosphere model, as well as the dynamic viscosity of the air and the gravitational acceleration, computes the most important airdata variables which in general are required to solve the equations of motion of an aircraft, computes additional airdata (-related) variables which may be useful for such purposes as comparing simulations with real ight experiments, windtunnel measurements, etc., computes some more additional airdata (-related) variables.
Airdata1 Airdata2
Airdata3
The blocks Airdata2 and Airdata3 do not affect the solution of the aircraft equations of motion, and can therefore be safely deleted from the model (except that this would require readjustment of several connecting lines as well). While this might have been useful to speed up simulations and free memory on slow computer systems in the past, there are no convincing reasons to do so today. In any case, the blocks Atmosph and Airdata1 are always required to solve the state equations. Inputs x Outputs yatm yad1 yad2 yad3
= [ V p q r xe ye H ] T = = = = [ ps T g ] T [ a M qdyn ]T [ qc Ve Vc ]T [ Tt Re Rc ]T
state vector, x
basic atmospheric properties, yatm basic airdata variables, yad1 additional airdata (-related) variables, yad2 additional airdata (-related) variables, yad3
Parameters The parameters for the blocks Airdata1, Airdata2, and Atmosph are all dened internally. Airdata3 reads the parameter vector GM1 from the M ATLAB workspace; its denition can be found in appendix C. GM1 can be loaded from the le AIRCRAFT. DAT, using the utility DATLOAD (see section 12.4.2). If this datale has somehow inadvertently been deleted, it can be re-created by running the program MODBUILD (see section 12.6.1). Connections in: 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 connected to Airdata2, Airdata3, and FMdims; yad2 from Airdata2 and yad3 from Airdata3 are not connected to any other block in the aircraft model. Type browse adgrp at the command-line for on-line help.
136

Beaver level 1 / Beaver level 2 / Airdata Group / Atmosph Main FDC library / Airdata, atmosphere
Atmosph
Type Aircraft-independent masked subsystem block, essential for solving the equations of motion. Description The block Atmosph is used to compute some basic atmospheric properties, using the ICAO Standard Atmosphere model (see for instance ref.[30] for a description of that model). It also 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 the calculation of airdata variables that must be known to solve the equations of motion, and by the blocks Airdata2 and Airdata3, for the computation of additional airdata (-related) variables. Equations The equations used by the block Atmosph have been discussed in more detail in section 3.5.
Air temperature T in the troposphere, according to the ICAO Standard Atmosphere model, [K]:
T = T0 + H where T0 = 288.15 K is the air temperature at sea level and = 0.0065 Km1 is the temperature lapse-rate in the troposphere. In this equation the small difference between the geometrical altitude h and the geopotential altitude H has been neglected in view of the relatively low altitudes considered; see section 3.5 for more details. Static air pressure in Standard Atmosphere ps , [Nm2 ]: p s = p0 T0 T
g R
where p0 = 101325 Nm2 is the air pressure at sea level and R = R a /M0 = 287.05 JK 1 kg1 is the specic gas constant of the air (R a = 8314.32JK 1 kmol1 is the molar gas constant, and M0 = 28.9644 kg kmol1 is the molecular weight of the air at sea level). Air density , [kgm3 ], according to the gas law for ideal gasses: ps = RT Coefcient of the dynamic viscosity , [kg m1 s1 ], according to Sutherlands equation [30]: 1.458 106 T 2 = T + 110.4 R Earth R Earth + h
3
Gravitational acceleration g, [ms2 ]:

2
g = g0
where g0 = 9.80665 ms2 is the gravitational acceleration at sea level and R Earth = 6371020 m is the radius of the Earth. Note: although this equation uses the radius of the Earth, the state equations in the block 12 ODEs are still based on a at-Earth model! This equation only takes into account the altitude-dependency of the gravitational acceleration.
137
Inputs x Outputs yatm
= [ V p q r xe ye H ] T = [ ps T g ] T
state vector, x
basic atmospheric properties, yatm
Parameters All parameters for Atmosph are dened within the block itself; Atmosph does not use any parameters from the M ATLAB workspace. Connections in: 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.
138

Beaver level 1 Main FDC library / Complete system Beaver
Beaver level 1
Type First level of the Beaver dynamics model, which provides connections to other S IMULINK systems and an interface between the model and the M ATLAB workspace. Description The rst level of the aircraft model (see gure 8.2) takes care of the input/output functions of the simulation model. It collects all input and output signals in vectors which are sent to the M ATLAB workspace by means of To Workspace blocks. A related timeline, which can be used for post-simulation analysis and processing of simulation data, is also made available. Furthermore, Beaver Level 1 contains a set of relevant Inport and Outport blocks, to allow the aircraft model to be connected to external S IMULINK systems, and to provide access points for analytical M ATLAB functions (most noticably the trimming functions). There are twelve Inport blocks: six control inputs and six inputs representing atmospheric disturbances. On the output-side, only a relevant subset of the system outputs have been connected to Outport blocks, to prevent the interface level from becoming too cluttered. This subset provides enough information for the autopilot simulation models, which will be discussed in chapter 15. The aircraft model comes in three avours: a stand-alone system, called Beaver, and two subsystem equivalents of this model. The stand-alone system is used for modelanalysis from the M ATLAB environment (simulations, trimming, linearisation), while the subsystem equivalents are used as subsystems within larger simulation models. These variants are virtually identical, except that one of the subsystem equivalents combines the 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 earlier incarnations of this toolbox, which were designed for earlier S IMULINK versions, that did 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 aircraft model, i.e. an entirely separate S IMULINK system, which could be called by other models, if desired. The advantage of this approach, compared to using ordinary subsystems, was that a single model could be called by several larger models, without having to duplicate any code. However, the feature to treat graphical models as S-functions was dropped from S IMULINK 2 (nowadays, the term S-function is used only to describe specially formatted program functions, written in M ATLAB, C, or Fortran). The current version of the FDC toolbox uses the newer S IMULINK library functionality to maintain a centralized copy of the aircraft model. Subsystems and/or blocks The rst level of the aircraft model uses Mux and To Workspace blocks to collect the inputs and output signals, and send these to the M ATLAB workspace. A Clock block provides a corresponding timeline for the simulation. Demux, Inport, and Outport blocks provide access points for external S IMULINK systems and M ATLAB functions. The actual aircraft model has been implemented in a single subsystem, called DeHavilland DHC-2 Beaver dynamics and output equations, or shortly: Beaver Level 2. Inputs The motions of the aircraft are affected by six control inputs (elevator, ailerons, rudder, aps, engine RPM, and engine manifold pressure), and six inputs representing atmospheric disturbances (three wind velocity components, and their time-derivatives). These signals have all been represented by scalar Inport blocks, and sorted by means of Mux blocks, to obtain the three external input vectors uaero , uprop , and uwind :
139
uaero uprop uwind
= [ e a r f ]T = [ n pz ] T
aerodynamic control inputs, uaero external propulsion inputs, uprop wind velocity components along body-axes and their time-derivatives, uwind
Outputs The time-trajectories of the above mentioned input signals are collected in the workspace variable In, while the time-trajectories of all output signals from the subsystem Beaver Level 2 are collected in the workspace variable Out. A clock signal is collected in the workspace variable time, to provide a corresponding time-axis. In and Out are matrices whose columns represent time-trajectories of the individual input or output signals, and whose rows represent data-points; the number of data-points corresponds to the length of the vector time. See appendix D for the exact denitions of these variables. A subset of the output signals is sent to the Outport blocks in this top-level, which allow the model to be connected to external systems, or to be accessed by M ATLAB functions. 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 from the following output vectors from Beaver Level 2: x x ydl
= [ V p q r xe ye H ] T = [ V p q r xe ye H ] T pb qc rb T = [ 2V V 2V ]
state vector, x time-derivative of state vector, xdot dimensionless angular velocities, ydl
Note: the stand-alone model Beaver and one of the subsystem equivalents use scalar Outport blocks to send these output signals to the outside world. The second subsystem equivalent combines the state variables and the rate of climb/descent in a single output vector, which is connected to the rst Outport block, and sends the dimensionless angular velocities to the second Outport block. Parameters
Beaver level 1 (or rather: Beaver Level 2) requires the variables AM, EM, GM1, GM2, and xinco to be dened in the M ATLAB workspace. The denitions of these variables can be found in appendix C; they can be loaded from the le AIRCRAFT. DAT, using the utility DATLOAD (see section 12.4.2). If this datale has somehow inadvertently been deleted, it can 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 initial value can be computed using the aircraft trim routine ACTRIM (see section 11.1), or it can be loaded into the M ATLAB workspace from le, using TRILOAD (see section 12.4.2). Of course, it is also possible to manually enter xinco, if required. Furthermore, an optional vector xx may be dened in the M ATLAB workspace, to articially x certain states to their initial values; see the description of the block xx for an explanation. If xx is not present in the workspace when the aircraft model equations are evaluated, it will automatically be set to its default value ones(1,12) by the block xx. If it is desired to articially x certain states, xx should be entered manually (it must be a vector of length 12, with all elements being either one or zero), or by running the utility FIXSTATE (see section 12.6.2).
Connections
Beaver Level 1 is the interface level of the aircraft model, where all input and output vectors are collected and sent to the M ATLAB workspace. The Inport and Outport blocks provide connections to external models and M ATLAB functions. Type browse level1 at the command-line for on-line help about this level of the aircraft model. Type browse inputs or browse outputs for help about the input/output denitions.
140

Beaver level 1 / Beaver level 2 Main FDC library / Complete system Beaver / Beaver level 2
Beaver level 2
Type Second level of the Beaver dynamics model. This masked subsystem contains the nonlinear differential equations, and a large range of output equations. Description The full name of this second level in the aircraft model is DeHavilland DHC-2 Beaver dynamics and output equations, which signies that this is in fact the core module of the toolbox (the rst level of the aircraft model handles the workspace output functions and provides an interface between the aircraft model and M ATLAB). For sake of brevity, we will refer to this subsystem as Beaver level 2 below. This subsystem organises the individual elements from the nonlinear aircraft model in a block-diagram structure that resembles gure 3.2 from chapter 3. See gure 8.1 for a picture of Beaver Level 2 itself. Subsystems and/or blocks The subsystem Beaver level 2 contains ve non-masked subsystems:
Additional outputs computes several useful output variables which are not required to solve the equations of motion themselves (and hence, additional), Aerodynamics Group (Beaver) computes the aerodynamic forces and moments for the Beaver, Aircraft equations of motion (Beaver) contains the general differential equations for the rigid-body dynamics and an aircraft-dependent block that corrects the time-derivatives of 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 splits this in a force-vector and a moment-vector, Fwind computes the contributions to the external forces and moments due to nonsteady atmosphere (wind and turbulence), Gravity computes the gravitational forces along the aircrafts body-axes, Hlpfcn computes several sines and cosines, which are used multiple times by other blocks from the aircraft model.
Inputs uaero uprop uwind Outputs x x ybvel yuvw ydl yfp ypow
= [ e a r f ]T = [ n pz ] T
aerodynamic control inputs, uaero external propulsion inputs, uprop wind velocity components along body-axes and their time-derivatives, uwind
= = = = = = =
[ V p q r xe ye H ] T [ V p q r xe ye H ] T [ u v w ]T [ u v w ]T pb rb [ 2V qc 2V ]T V [ fpa ]T [ dpt P ]T
state vector, x time-derivative of state vector, xdot body-axes velocity components, ybvel time-derivatives of body-axes velocities, yuvw dimensionless angular velocities, ydl ight-path variables, yfp engine power related variables, ypow
141
yacc Caero Cprop FMaero FMprop Fgrav Fwind yatm yad1 yad2 yad3
= = = = = = = = = = =
[ A x Ay Az a x,k ay,k az,k ]T specic forces and accelerations, yacc T aerodynamic force and moment coefcients, Caero [ CXa CYa CZa Cla Cma Cna ] T [ CX p CYp Cz p Cl p Cm p Cn p ] propulsive force and moment coefcients, Cprop [ Xa Ya Za L a Ma Na ]T dimensional aerodynamic forces and moments, FMaero [ X p Yp Z p L p M p Np ]T dimensional propulsive forces and moments, FMprop T [ Xgr Ygr Zgr ] gravity force components along body-axes, Fgrav [ Xw Yw Zw ]T corrections to body-axes forces in nonsteady atmosphere, Fwind [ ps T g ] T basic atmospheric properties, yatm T [ a M qdyn ] basic airdata variables, yad1 T [ qc Ve Vc ] additional airdata (-related) variables, yad2 [ Tt Re Rc ]T additional airdata (-related) variables, yad3
Parameters Several blocks and subsystems from Beaver level 2 require the variables AM, EM, GM1, GM2, and xinco to be dened in the M ATLAB workspace. The following list provides an overview of the parameter requirements: AM EM GM1 GM2 xx xinco
Aerodynamics Group (Beaver), Aircraft Equations of Motion (Beaver) Engine Group (Beaver) Additional Outputs, Aerodynamics Group (Beaver), Aircraft Equations of Motion (Beaver), Airdata Group, Engine Group (Beaver), Fwind, Gravity Aircraft Equations of Motion (Beaver) Aircraft Equations of Motion (Beaver) Aircraft Equations of Motion (Beaver)
The denitions for AM, EM, GM1, and GM2 can be found in appendix C. These variables can be loaded from the le AIRCRAFT. DAT, using the utility DATLOAD (see section 12.4.2). If this datale has somehow inadvertently been deleted, it can 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 initial value can be computed using the aircraft trim routine ACTRIM (see section 11.1), or it can be loaded into the M ATLAB workspace from le, using TRILOAD (see section 12.4.2). Of course, it is also possible to manually enter xinco, if required. The vector xx is optional: if this variable is not present in the workspace when the aircraft model equations are evaluated, it will automatically be set to its default value ones(1,12) by the block xx (which is contained in the subsystem Aircraft Equations of Motion (Beaver). If it is desired to articially x certain states, xx should be entered manually (it must be a vector of length 12, with all elements being either one or zero), or by running the utility FIXSTATE (see section 12.6.2). Connections in: 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 such as 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.
142

Beaver level 1 / Beaver level 2 / Aerodynamics Group / Dimless Main FDC library / Aerodynamics
Dimless
Type Aircraft-independent masked subsystem block, essential for solving the equations of motion. Description The block Dimless is used to obtain dimensionless roll, pitch, and yaw rates, which are required for the aerodynamic model of the Beaver. It should be noted that the equations used to determine these dimensionless rotational velocities are typical for most models developed by the Control and Simulation Division, Faculty of Aerospace Engineering, Delft University of Technology. Other sources may use different expressions, so be careful to verify these expressions before trying to implement a model of a different aircraft within the FDC structure. The equations themselves are independent of the aircraft under consideration. Equations The equations used by the block Dimless are straightforward:
Non-dimensional roll rate: pb p 2V Non-dimensional pitch rate: qc q V Non-dimensional yaw rate: rb r 2V Inputs x = [ V p q r xe ye H ] T
Outputs ydl
state vector, x
= [
pb qc rb T 2V V 2V ]
non-dimensional angular velocities, ydl
Parameters
Dimless needs the parameter vector GM1 to be present the M ATLAB workspace, in order
to extract the wing span b and mean aerodynamic chord c. The denition of GM1 can be found in appendix C. GM1 can be loaded from the le AIRCRAFT. DAT, using the utility DATLOAD (see section 12.4.2). If this datale has somehow inadvertently been deleted, it can be re-created by running the program MODBUILD (see section 12.6.1). Connections in: x comes from the block Integrator. out: ydl is connected to the block Aeromod. Type browse dimless at the command-line for on-line help.
143
Beaver level 1 / Beaver level 2 / Engine Group (Beaver) Main FDC library / Engine forces and moments
Engine Group (Beaver)
Type Aircraft-dependent subsystem, essential for solving the equations of motion. The subsystem is not masked. Description The subsystem Engine Group (Beaver) contains blocks which determine the engine power and compute the resulting forces and moments due to operation of the powerplant, including 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 valid for the DeHavilland DHC-2 Beaver aircraft. The remainder of the aerodynamic model has been implemented in the subsystem Aerodynamics Group (Beaver). Subsystems and/or blocks The subsystem Engine Group (Beaver) contains three blocks:
Power
computes the power of the engine and the dimensionless increase in air pressure across the plane of the propeller, the operation of the powerplant, including propeller slipstream effects,
Engmod computes dimensionless force and moment coefcients which are caused by FMdims
converts the dimensionless force and moment coefcients to dimensional forces and moments.
Inputs x uprop yatm yad1
= = = =
[ V p q r xe ye H ] T [ n pz ] T [ ps T g ] T [ a M qdyn ]T
state vector, x external propulsion inputs, uprop basic atmospheric properties, yatm basic airdata variables, yad1
Outputs ypow = [ dpt P ]T engine power related variables, ypow T Cprop = [ CX p CYp Cz p Cl p Cm p Cn p ] propulsive force and moment coefcients, Cprop FMprop = [ X p Yp Z p L p M p Np ] T dimensional propulsive forces and moments, FMprop Parameters The block Engmod reads the engine model parameter matrix EM from the M ATLAB workspace; the block FMdims requires the parameter vector GM1. The denitions of these variables can be found in appendix C. The variables can be loaded from the le AIR CRAFT. DAT , using the utility DATLOAD (see section 12.4.2). If this datale has somehow inadvertently been deleted, it can be re-created by running the program MODBUILD (see section 12.6.1). Connections in: 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 connected to FMdims; FMprop from FMdims is connected to FMsort. Type browse enggrp at the command-line for on-line help.
144

Beaver level 1 / Beaver level 2 / Engine Group / Engmod (Beaver) Main FDC library / Engine forces and moments
Engmod (Beaver)
Type Aircraft-dependent masked subsystem block, essential for solving the equations of motion. Description The block Engmod (Beaver) determines the propulsive forces and moments for the Beaver aircraft, using a model from ref.[34]. It computes the force and moment coefcients which are caused by the operation of the powerplant (this includes the engine thrust, gyroscopical effects caused by the rotating propeller, and the inuence of the propeller slipstream upon the aerodynamic forces and moments), as a function of the dimensionless increase in air pressure across the working plane of the propeller. The latter signal is determined by the separate block Power (Beaver). Engmod (Beaver) needs to be updated if one wishes to implement a model of a different aircraft within the FDC framework. Thanks to its black-box structure, it is relatively easy to change the structure of the equations if necessary, e.g. to incorporate look-up table functions, to implement functions which are typical for a jet engine, or to increase the number of engines. Equations The propulsive force and moment coefcients of the Beaver are expressed in terms of nonlinear polynomial functions of the state variables and the dimensionless increase in pressure 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 coefcients measured in the body-xed reference frame:
CX p = CXdpt dpt + CX CYp = 0 CZ p = CZdpt dpt Cl p = Cl
2 dpt dpt2
dpt2
2 dpt
Cm p = Cmdpt dpt Cn p = Cn
dpt3
dpt3
The coefcients of the polynomials represent engine stability and control derivatives of the Beaver; they have been listed in table B.4 of appendix B. A closer look at the internals of the block Engmod (Beaver) reveils that the polynomial evaluation has been implemented 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 derivatives of the Beaver are contained. Inputs x ypow Outputs Cprop
= [ V p q r xe ye H ] T = [ dpt P ]T = [ CX p CYp Cz p Cl p Cm p Cn p ]T
state vector, x engine power related variables, ypow
propulsive force and moment coefcients, Cprop
145
Parameters
Engmod needs the parameter matrix EM to be present in the M ATLAB workspace, in order to read out the stability and control coefcients of the engine forces and moments model. The denition of this matrix can be found in appendix C. EM can be loaded from the le AIRCRAFT. DAT , using the utility DATLOAD (see section 12.4.2). If this datale has somehow inadvertently been deleted, it can be re-created by running the program MODBUILD (see section 12.6.1).
Connections in: 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.
146

Beaver level 1 / Beaver level 2 / Aircraft Equations of Motion / 12 ODEs / Eulerdot Main FDC library / Equations of motion
Eulerdot
Type Aircraft-independent masked subsystem block, contains three (out of twelve) state equations. Description The block Eulerdot is used to compute the time-derivatives of the Euler angles, i.e. the yaw angle , pitch angle , and roll angle . These three variables form a subset of the twelve state variables of the nonlinear aircraft model. Equations The equations used by the block Eulerdot have been discussed in some more detail in section 2.4.
Time-derivatives of the Euler angles , , and , [rad s1 ]: q sin + r cos = cos = q cos r sin = p + sin
Inputs ueul where: x Ftot Mtot yhlp Outputs yeul
= [ x T Ftot T Mtot T yhlp T ]T
input vector to Eulerdot, ueul
= = = =
[ V p q r xe ye H ] T state vector, x T [ Fx Fy Fz ] total external forces, Ftot T [LMN] total external moments, Mtot [ cos sin cos sin tan sin cos sin cos sin cos ]T
= [ ]T
time-derivatives of the Euler angles, yeul (part of x)
Parameters None. Connections in: 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 a single vector x (not corrected for the implicit nature of the -equation). This timederivative of the state vector x is then connected to the block xdotcorr. Type browse eulerdot at the command-line for on-line help.
147
Beaver level 1 / Beaver level 2 / Additional Outputs / Flpath Main FDC library / Other (output-) equations
Flpath
Type Aircraft-independent masked subsystem block, not essential for solving the equations of motion. Description The block Flpath is used to compute some ight-path (-related) variables. These output variables are useful for ight path tracking, but are not required to actually solve the equations of motion themselves. Equations The equations used by the block Flpath have been discussed in some more detail in section 3.6.
Flight-path angle , [rad]: H = arcsin V Flight-path acceleration fpa, i.e. the acceleration in the direction of the true airspeed vector V, [g]: V fpa = g0
with g0 = 9.80665 ms1 the gravitational acceleration at sea level. Azimuth angle , [rad]: = +
Bank angle , [rad]:

= arcsin sin cos Inputs x x yhlp Outputs yfp
= [ V p q r xe ye H ] T state vector, x p q r xe ye H ] T = [V time-derivative of state vector, xdot = [ cos sin cos sin tan sin cos sin cos sin cos ]T
= [ fpa ]T
ight-path variables, yfp
Parameters None. Connections in: x comes from the block Integrator; x comes from 12 ODEs via the correction blocks xdotcorr (Beaver) and xx; 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.
148

Beaver level 1 / Beaver level 2 / Aerodynamics Group or Engine Group / FMdims Main FDC library / Aerodynamics or Engine forces and moments
FMdims
Type Aircraft-independent masked subsystem block, essential for solving the equations of motion. Description The block FMdims is used to obtain dimensional forces and moments from the dimensionless force and moment coefcients as determined by the aerodynamic model Aeromod (Beaver) and the propulsion model Engmod (Beaver). It should be noted that the relation between the dimensionless coefcients and the corresponding forces and moments is typical for most aircraft models from the Faculty of Aerospace Engineering of Delft University of Technology; other sources may apply slightly different denitions. Equations The equations used by the block FMdims have been discussed in some more detail in section 3.3.1.
Dimensional forces, [N]: Xa = CXa qdyn S Ya = CYa qdyn S Za = CZa qdyn S Dimensional moments, [Nm]: L a = Cla qdyn S b Ma = Cma qdyn S c Na = Cna qdyn S b
The index a denotes aerodynamic forces and moments, which corresponds to the use of FMdims in the subsystem Aerodynamics Group; replace this by p for the propulsive forces and moments, determined in the subsystem subsystem Engine Group. Inputs yad1 Caero or: Cprop
= [ a M qdyn ]T = [ CXa CYa CZa Cla Cma Cna ]T = [ CX p CYp Cz p Cl p Cm p Cn p ]T
basic airdata variables, yad1 aerodynamic force and moment coefcients, Caero propulsive force and moment coefcients, Cprop
Outputs FMaero = [ Xa Ya Za L a Ma Na ] T or: FMprop = [ X p Yp Z p L p M p Np ] T
dimensional aerodynamic forces and moments, FMaero dimensional propulsive forces and moments, FMprop
Parameters FMdims reads the parameter vector GM1 from the M ATLAB workspace, in order to extract the mean aerodynamic chord c, the wing span b, and the wing surface S. See appendix C for the exact denition of GM1. This vector can be loaded from the le AIRCRAFT. DAT, using the utility DATLOAD (see section 12.4.2). If this datale has somehow inadvertently been deleted, it can be re-created by running the program MODBUILD (see section 12.6.1). Connections in: yad1 comes from the block Airdata1; Caero comes from Aeromod (Beaver); Cprop comes from Engmod (Beaver).
149
out: FMaero or FMprop are connected to FMsort. Type browse fmdims at the command-line for on-line help.
150

Beaver level 1 / Beaver level 2 / FMsort Main FDC library / Other (output-) equations
FMsort
Type Aircraft-independent masked subsystem block, essential for solving the equations of motion. Description The block FMsort is used to determine the sum of all contributions to the external forces and moments, and sort the results in a force-vector and moment-vector. The FDC model of the Beaver aircraft takes into account aerodynamic forces and moments, propulsive forces and moments, gravitational forces, and wind-corrections. These contributions are determined by the blocks Aerodynamics Group (Beaver), Engine Group (Beaver), Gravity, and Fwind, respectively. It is relatively straightforward to include additional terms, such as landing gear forces or forces caused by sudden weight-changes of the airplane, by including the appropriate submodels and editing FMsort accordingly. Equations The equations used by the block FMsort are straightforward:
Resulting forces along the body-axes, [N]:

Fx = Xa + X p + Xgr + Xw Fy = Ya + Yp + Ygr + Yw Fz = Za + Z p + Zgr + Zw
Resulting moments around the body-axes, [Nm]:

L = La + L p M = Ma + M p N = Na + Np Inputs FMaero FMprop Fgrav Fwind Outputs Ftot Mtot
= = = =
[ Xa Ya Za L a Ma Na ]T dimensional aerodynamic forces and moments, FMaero [ X p Yp Z p L p M p Np ]T dimensional propulsive forces and moments, FMprop T [ Xgr Ygr Zgr ] gravity force components along body-axes, Fgrav T [ Xw Yw Zw ] corrections to body-axes forces in nonsteady atmosphere, Fwind
total external forces, Ftot total external moments, Mtot
= [ Fx Fy Fz ]T = [ L M N ]T
Parameters None. Connections in: FMaero comes from the block Aeromod (Beaver); FMprop comes from the block Engmod (Beaver); Fgrav comes from Gravity; Fwind comes from Fwind. out: Ftot and Mtot are both connected to Vabdot, pqrdot, Eulerdot, and xyHdot; Ftot is also connected to Accel. Type browse fmsort at the command-line for on-line help.
151
Beaver level 1 / Beaver level 2 / Fwind Main FDC library / Gravity and wind forces
Fwind
Type Aircraft-independent masked subsystem block, necessary for solving the equations of motion in a nonsteady atmosphere. Description The block Fwind is used to compute correction terms for the external forces, which need to be added to the forces along the aircrafts body-axes when considering ight in nonsteady atmosphere. These correction terms depend upon the components of the wind velocity vector Vw along the aircrafts body-axes, the time-derivatives of these wind components, and the roll, pitch, and yaw rates of the aircraft. Equations The equations used by the block Fwind have been discussed in some more detail in section 3.3.4.
Corrections to the force components along the body-axes, to account for nonsteady atmosphere, [N]:
Xw = m (uw + qww rvw ) Yw = m (vw pww + ruw ) Zw = m (ww + pvw quw ) Inputs x uwind Outputs Fwind
= [ V p q r xe ye H ] T
= [ uw vw ww uw vw ww
state vector, x body-axes components of the wind velocity, and their time-derivatives, uwind
]T
= [ Xw Yw Zw ]T
corrections to body-axes forces in nonsteady atmosphere, Fwind
Parameters Fwind needs the parameter vector GM1 to be present the M ATLAB workspace, in order to 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). The denition of this vector can be found in appendix C. GM1 can be loaded from the le AIRCRAFT. DAT , using the utility DATLOAD (see section 12.4.2). If this datale has somehow inadvertently been deleted, it can be re-created by running the program MODBUILD (see section 12.6.1). Connections in: 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.
152

Beaver level 1 / Beaver level 2 / Gravity Main FDC library / Gravity and wind forces
Gravity
Type Aircraft-independent masked subsystem block, essential for solving the equations of motion. Description The block Gravity computes the resolution of the aircrafts weight in body-axes components, using the pitch and roll angle to determine the attitude of the airplane (the yawangle does not affect the gravitational force components). The gravitational acceleration varies with height; its local value is obtained from the block Atmosph. Equations The equations used by the block Gravity have been discussed in some more detail in section 3.3.3.
Contribution of the aircrafts 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]. Inputs x yatm Outputs Fgrav
= [ V p q r xe ye H ] T = [ ps T g ] T = [ Xgr Ygr Zgr ]T
state vector, x basic atmospheric properties, yatm
gravity force components along body-axes, Fgrav
Parameters Gravity needs the parameter vector GM1 to be present the M ATLAB workspace, in order to 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). The denition of GM1 can be found in appendix C. GM1 can be loaded from the le AIRCRAFT. DAT, using the utility DATLOAD (see section 12.4.2). If this datale has somehow inadvertently been deleted, it can be re-created by running the program MODBUILD (see section 12.6.1). Connections in: 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.
153
Beaver level 1 / Beaver level 2 / Hlpfcn Main FDC library / Other (output-) equations
Hlpfcn
Type Aircraft-independent masked subsystem block, essential for solving the equations of motion. Description The block Hlpfcn is used to compute frequently used sines and cosines of the angle of attack, the sideslip angle, and the Euler angles, in order to reduce the number of duplicate sine and cosine evaluations in the simulation model. Since the outputs from this block are used by several other subsystems, Hlpfcn has been placed in an internal feedback loop of the aircraft model. Equations Hlpfcn simply determines the required sines and cosines, and stores the results in a single vector. Inputs x Outputs yhlp
= [ V p q r xe ye H ] T = [ cos sin cos sin tan sin cos sin cos sin cos ]T
state vector, x
(Please notice that this vector also includes a term tan and that the selected cosine-sine sequence is unfortunately not very intuitive.) Parameters None. Connections in: x comes from the block Integrator. out: yhlp is connected to uvw, xdotcorr, Eulerdot, pqrdot, Vabdot, xyHdot, and uvwdot (Additional Outputs). Type browse hlpfcn at the command-line for on-line help.
154

Beaver level 1 / Beaver level 2 / Aircraft Equations of Motion / Integrator Main FDC library / Equations of motion
Integrator
Type Standard S IMULINK block, essential for solving the equations of motion. Description The block Integrator is used to obtain the time-trajectories of the twelve state variables by integrating the corresponding derivatives, starting with the initial value of the state vector, that needs to be dened in the M ATLAB workspace before starting a simulation. Equations The Integrator block determines the new value of the state vector by integrating its timederivative over the current time-interval, and adding this result to its previous value.
Update of the state vector for the current time-step:

x ( t n +1 ) = x ( t n ) +
t n +1 tn
x(t)dt;
n = 0, 1, . . .
where the integral is approximated using a numerical integration method. See section 6.1 for more information. Inputs x Outputs x = [ V p q r xe ye H ] T
time-derivative of state vector, xdot
state vector, x
Parameters
Integrator reads the vector xinco from the M ATLAB workspace; xinco contains the initial value of the state vector. A steady-state initial value can be computed using the aircraft trim routine ACTRIM (see section 11.1), or it can be loaded into the M ATLAB workspace from le, using TRILOAD (see section 12.4.2). Of course, it is also possible to manually enter the elements of xinco, if required.
Connections in: x comes from the block xdotcorr. out: x is connected to most other blocks in the aircraft model. See the S IMULINK block-reference in the M ATLAB helpdesk documentation for more information about the Integrator block.
155
Beaver level 1 / Beaver level 2 / Engine Group / Power (Beaver) Main FDC library / Engine forces and moments
Power (Beaver)
Type Aircraft-dependent masked subsystem block, essential for solving the equations of motion. Description The block Power (Beaver) is used to compute the engine power P and the dimensionless increase in total air pressure, measured across the working plane of the propeller, dpt. The equations are valid for the Beaver aircraft, but the structure of these relations is probably typical 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 different aircraft within the FDC framework. Thanks to its black-box structure, it is relatively easy to change the structure of the equations if necessary, e.g. to incorporate look-up table functions. Equations The equations used by the block Power (Beaver) have been discussed in more detail in section 3.3.2.
Dimensionless increase in air pressure, measured across the working plane of the propeller, []:
dpt = with
1 V 3 2
pt 1 2 2 V
= C1 + C2
P
1 3 2 V
measured in [kW kg1 s3 ], and: C1 = 0.08696, C2 = 191.18, see ref.[34].
Engine power P, [Nm s1 ]:

P = 0.7355 326.5 + 0.00412( pz + 7.4)(n + 2010) + (408.0 0.0965n) 1.0 0
Inputs x uprop yatm Outputs ypow
= [ V p q r xe ye H ] T = [ n pz ] T = [ ps T g ] T = [ dpt P ]T
state vector, x external propulsion inputs, uprop basic atmospheric properties, yatm
engine power related variables, ypow
Parameters All parameters for Power (Beaver) have been dened within the block itself; the block does not use any parameters from the M ATLAB workspace. Connections in: x comes from the block Integrator; uprop is an external input vector with control inputs 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.
156

Beaver level 1 / Beaver level 2 / Aircraft Equations of Motion / 12 ODEs / pqrdot Main FDC library / Equations of motion
pqrdot
Type Aircraft-independent masked subsystem block, contains three (out of twelve) state equations. Description The block pqrdot computes the time-derivatives of the roll rate p, pitch rate q, and yaw rate r. These three variables form a subset of the twelve state variables of the nonlinear aircraft model. Equations The equations used by the block pqrdot have been discussed in some more detail in section 2.1.4.
Time-derivatives of the angular velocities around the body-axes, [rad s2 ]:

p = Ppp p2 + Ppq pq + Ppr pr + Pqq q2 + Pqr qr + Prr r2 + Pl L + Pm M + Pn N q = Q pp p2 + Q pq pq + Q pr pr + Qqq q2 + Qqr qr + Qrr r2 + Ql L + Qm M + Qn N r = R pp p2 + R pq pq + R pr pr + Rqq q2 + Rqr qr + Rrr r2 + Rl L + Rm M + Rn N The coefcients Ppp , Ppq , Ppr , ... , Rm , and Rn are inertia coefcients, see the denition in table 2.2. Inputs upqr where: x Ftot Mtot yhlp Outputs ypqr = [ p q r ]T
time-derivatives of the angular velocities around the body-axes, ypqr (part of x)
= [ x T Ftot T Mtot T yhlp T ]T
input vector to pqrdot, pqr
= = = =
[ V p q r xe ye H ] T state vector, x T [ Fx Fy Fz ] total external forces, Ftot [ L M N ]T total external moments, Mtot [ cos sin cos sin tan sin cos sin cos sin cos ]T
Parameters The block pqrdot needs the parameter matrix GM2 to be present the M ATLAB workspace, in order to extract the inertia coefcients (the moments and products of inertia have been implemented as parameters, i.e. they are assumed to be constant during the relative short time intervals considered). The denition of this matrix can be found in appendix C. GM2 can be loaded from the le AIRCRAFT. DAT, using the utility DATLOAD (see section 12.4.2). If this datale has somehow inadvertently been deleted, it can be re-created by running the program MODBUILD (see section 12.6.1). Connections in: x comes from the block Integrator; Ftot and Mtot come from the block FMsort; yhlp comes from the block Hlpfcn. out: ypqr 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 timederivative of the state vector x is then connected to the block xdotcorr. Type browse pqrdot at the command-line for on-line help.
157
uvw
Beaver level 1 / Beaver level 2 / Aircraft Equations of Motion / uvw Main FDC library / Equations of motion
Type Aircraft-independent masked subsystem block, essential for solving the equations of motion. Description The block uvw is used to compute the body-axes velocity components, using the angle of attack , sideslip angle , and true airspeed V. These velocity components are required to determine the coordinates xe and ye and the altitude H of the aircraft. Equations The equations used by the block uvw have been discussed in some more detail in section 2.2.2.
Velocity component u, directed along the XB -axis, [ms1 ]:

u = V cos cos
Velocity component v, directed along the YB -axis, [ms1 ]:

v = V sin
Velocity component w, directed along the ZB -axis, [ms1 ]:

w = V sin cos Inputs x yhlp Outputs ybvel
= [ V p q r xe ye H ] T = [ cos sin cos sin tan sin cos sin cos sin cos ]T
state vector, x
= [ u v w ]T
body-axes velocity components, ybvel
Parameters None. Connections in: 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.
158

Beaver level 1 / Beaver level 2 / Additional Outputs / uvwdot Main FDC library / Other (output-) equations
uvwdot
Type Aircraft-independent masked subsystem block, not essential for solving the equations of motion (the block does not contain any state equations). Description The block uvwdot computes the time-derivatives of the body-axes velocity components u, v, and w. It should be noted that these body-axes velocity components are not state variables, and therefore, their time-derivatives do not represent state equations (the state equations have been based on the airspeed, angle of attack, and sideslip angle, instead of the body-axes velocity components, as explained in section 2.2). Equations The equations used by the block uvwdot have been discussed in some more detail in section 3.6.
Time-derivative of the velocity component along the XB -axis, [ms2 ]: u = V cos cos V ( sin cos + cos sin ) Time-derivative of the velocity component along the YB -axis, [ms2 ]: v = V sin + V cos Time-derivative of the velocity component along the ZB -axis, [ms2 ]: w = V sin cos + V ( cos cos sin sin )
Inputs x x yhlp Outputs yuvw
= [ V p q r xe ye H ] T state vector, x = [ V p q r xe ye H ] T time-derivative of state vector, xdot = [ cos sin cos sin tan sin cos sin cos sin cos ]T
= [ u v w ]T
time-derivatives of body-axes velocities, yuvw
Parameters None. Connections in: x comes from the block Integrator; x comes from the block xx; 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.
159
Vabdot
Beaver level 1 / Beaver level 2 / Aircraft Equations of Motion / 12 ODEs / Vabdot Main FDC library / Equations of motion
Type Aircraft-independent masked subsystem block, contains three (out of twelve) state equations. Description The 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 of the nonlinear aircraft model. Equations The equations used by the block Vabdot have been discussed in some more detail in section 2.2.
Time-derivative of the true airspeed V, [ms2 ]: 1 V= ( Fx cos cos + Fy sin + Fz sin cos ) m Time-derivative of the angle of attack , [rad s1 ]: 1 1 = ( Fx sin + Fz cos ) + q ( p cos + r sin ) tan V cos m Time-derivative of the sideslip angle , [rad s1 ]: 1 1 = ( Fx cos sin + Fy cos Fz sin sin ) + p sin r cos V m Inputs uVab = [ x T Ftot T Mtot T yhlp T ]T input vector to Vabdot, uVab
where: x Ftot Mtot yhlp Outputs yVab = [ V ]T
= = = =
[ V p q r xe ye H ] T state vector, x T [ Fx Fy Fz ] total external forces, Ftot [ L M N ]T total external moments, Mtot [ cos sin cos sin tan sin cos sin cos sin cos ]T
frequently used sines and cosines, yhlp time-derivatives of the airspeed, angle of attack, and sideslip angle, yVab (part of x)
Parameters Vabdot needs the parameter vector GM1 to be present the M ATLAB workspace, in order to 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). The denition of GM1 can be found in appendix C. GM1 can be loaded from the le AIRCRAFT. DAT, using the utility DATLOAD (see section 12.4.2). If this datale has somehow inadvertently been deleted, it can be re-created by running the program MODBUILD (see section 12.6.1). Connections in: x comes from the block Integrator; Ftot and Mtot come from the block FMsort; yhlp 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 timederivative of the state vector x is then connected to the block xdotcorr. Type browse Vabdot at the command-line for on-line help.
160

Beaver level 1 / Beaver level 2 / Aircraft Equations of Motion / xdotcorr (Beaver) Main FDC library / Equations of motion
xdotcorr (Beaver)
Type Aircraft-dependent masked subsystem block, essential for solving the equations of motion. Description As discussed in section 3.4, the aerodynamic model of the Beaver aircraft includes an implicit differential equation of the sideslip angle: the time-derivative of the sideslip angle appears 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 resulting in an algebraic loop (see section 6.4.1), which would slow down the simulations or make the system too complicated for S IMULINK to solve, the equation has been re-written as an explicit differential equation. In order to keep the resulting model as generic as possible, the resulting equation was split into an aircraft-independent part, which neglected the 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 aircraftdependent block in the subsystem Aircraft Equations of Motion (Beaver) (hence the sufx Beaver). Please notice that xdotcorr is in fact part of the aerodynamic model; this block should be updated if the aircraft model is adapted for a different aircraft type. This method can be applied for any implicit state equation, as long as the dependencies are linear. For nonlinear implicit relations, it will be necessary to use a different solution to this problem, e.g. articially breaking an implicit loop by introducing a delay in the internal x-feedback loop. Equations The -equation for the Beaver can be written as: =
1 b 1 Fx cos sin + Fy cos Fz sin sin + 2 V 2 S CY 2V cos Vm
+ p sin r 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: Sb C cos = 1 4m Y 1 = Fx cos sin + Fy cos Fz sin sin + p sin r cos Vm Based upon this equation the following calculation sequence has been used in the simulation model of the Beaver: 1. compute the external forces and moments as usual, but neglect the -contribution to the aerodynamic side-force for the time being (Aeromod), 2. substitute the thus obtained forces and moments into the general -equation, to obtain the value (12 ODEs), and 3. compute the actual value of using the expression = 1 (xdotcorr).
Sb 4m CY
cos
161
Inputs x yhlp yatm Outputs x
= [ V p q r xe ye H ] T uncorrected time-derivative of state vector, xdot = [ cos sin cos sin tan sin cos sin cos sin cos ]T
= [ ps T g ] T
basic atmospheric properties, yatm time-derivative of state vector, xdot, corrected for
Parameters The block xdotcorr (Beaver) needs the parameter vector GM1 to be present the M ATLAB workspace, 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 during the relative short time intervals considered). It also needs the parameter matrix AM, to extract the stability derivative CY . The denition of AM and GM1 can be found in appendix C. Both variables can be loaded from the le AIRCRAFT. DAT, using the utility DATLOAD (see section 12.4.2). If this datale has somehow inadvertently been deleted, it can be re-created by running the program MODBUILD (see section 12.6.1). Connections in: 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 xx. Type browse xdotcorr at the command-line for on-line help.
162

Beaver level 1 / Beaver level 2 / Aircraft Equations of Motion / xx Main FDC library / Equations of motion
xx
Type Aircraft-independent masked Gain block, not necessary for solving the equations of motion themselves but quite useful for purposes such as autopilot design and analysis. Description Sometimes it is useful to articially x state variables to their initial values by simply setting their time-derivatives to zero, thus totally disregarding the values of the timederivatives resulting from the model equations. Neglecting parts of the system dynamics can be useful to establish reference system responses, against which actual responses can be measured. Examples are the design of a speed-hold autothrottle controller, whose responses can be compared to the ideal situation in which the airspeed is articially held constant, or the analysis of lateral-longitudinal cross-coupling effects by comparing simulations from the full aircraft model with results in which the longitudinal or lateral aircraft dynamics are articially neglected. The block xx can be used to force state variables from the aircraft model to remain xed to their initial value during the simulation. It is in fact a masked Gain block that multiplies the time-derivatives of all state variables with a value of either one, or zero. In the rst situation, the computed time-derivative is used, in the second situation, the time-derivative is articially set to zero, causing the corresponding state variable to stay constant. Equations The block xx modies the time-derivative of the state vector by performing an elementby-element multiplication (in the equation below denoted with the symbol ) with the vector xx. The elements from this vector are equal to one or zero, and the total number of elements corresponds to the length of the state vector.
Modied time-derivative of the state vector: V xx(1) xx(2) xx(3) p . . . q . r . . where: xx(i) = xnew = xold xx = . . . . . . xe . . ye . xx(12) H
Inputs xold Outputs xnew = [ V p q r xe ye H ] T = [ V p q r xe ye H ] T
0 1
i {1, 2, . . . , 12}
unmodied time-derivative of state vector, xdot
modied time-derivative of state vector, xdot
Parameters The block xx tries to read the multiplication vector xx from in the M ATLAB workspace. If the variable xx is not present in the workspace when the aircraft model is accessed by e.g. a simulation or a linearization process, it will automatically be set to its default value ones(1,12). If it is desired to articially x specic states, xx should either be entered
163
manually (it must be a vector of length 12, with all elements being either one or zero), or be dened by running the utility FIXSTATE (see section 12.6.2). Connections in: the unmodied vector x comes from the block xdotcorr (Beaver). out: the modied vector x, whose elements may have been articially set to zero, is connected to the block Integrator. Type browse xfix at the command-line for on-line help. Information about FIXSTATE can be displayed on screen by typing browse fixstate at the command-line.
164

Beaver level 1 / Beaver level 2 / Aircraft Equations of Motion / 12 ODEs / xyHdot Main FDC library / Equations of motion
xyHdot
Type Aircraft-independent masked subsystem block, contains three (out of twelve) state equations. Description The block xyHdot computes the time-derivatives of the aircrafts X and Y-coordinates xe and ye , measured with respect to the Earth-xed reference frame, and of the the altitude H. These three variables form a subset of the twelve state variables of the nonlinear aircraft model. For most purposes it is possible to omit xe and ye from the simulation model, because the motions of the aircraft are not affected by its position relative to the Earth. The coordinates are useful, however, for navigational purposes. Notice that it is not possible to omit the altitude H from the simulation model, because of the altitudedependency of the air temperature, pressure, and density, which affect the aerodynamic and propulsive forces and moments. Equations The equations used by the block xyHdot have been discussed in some more detail in section 2.4.
Time-derivative of the X-coordinate xe , [ms1 ]:

xe = {ue cos + (ve sin + we cos ) sin } cos (ve cos we sin ) sin
Time-derivative of the Y-coordinate ye , [ms1 ]:

ye = {ue cos + (ve sin + we cos ) sin } sin + (ve cos we sin ) cos
Rate of climb or descent, [ms1 ]: H = ze = ue sin (ve sin + we cos ) cos

Inputs ybvel uxyH where: x Ftot Mtot yhlp Outputs yxyH
= [ u + uw v + vw w + ww ] T = [ x T Ftot T Mtot T yhlp T ]T
body-axes velocity components plus wind, ybvel input vector to xyHdot, uxyH
= = = =
[ V p q r xe ye H ] T state vector, x T [ Fx Fy Fz ] total external forces, Ftot T [LMN] total external moments, Mtot [ cos sin cos sin tan sin cos sin cos sin cos ]T
= [ xe ye H ] T
time-derivatives of the coordinates and altitude, yxyH (part of x)
Parameters None. Connections in: x comes from the block Integrator; Ftot and Mtot come from the block FMsort; yhlp 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 timederivative 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 some basic wind and turbulence models that were suitable for implementation in S IMU LINK . This chapter will provide a detailed description of the resulting S IMULINK blocks. If you want to manipulate these blocks, or gain a better insight in the structure of these blocks, it is recommended to unmask the blocks and compare the internal block equations with the descriptions from this chapter. See section 7.8 for more information 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 S IMULINK blocklibrary WINDLIB, which is shown in gure 9.1. This library can be accessed from the main FDC library (shown in gure 7.7 of chapter 7) by double-clicking the Wind and turbulence library button, or by typing windlib in the M ATLAB command-window. WINDLIB itself consists of two sublibraries: WNDLIB1, which contains the deterministic wind models, and WNDLIB2, which contains the stochastic turbulence models. These sublibraries have been shown in gures 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 descriptions of the individual blocks from the wind and turbulence library. The blocks have been listed in alphabetical order; their locations have been referenced in relation to the main FDC library and the wind and turbulence library.
9.1. The wind and turbulence blocklibrary
167
BLwind
Type Masked subsystem block.
Main FDC library / Wind and turbulence / Wind models / BLwind Wind and turbulence library / Wind models / BLwind
Description The block BLwind calculates components of the wind velocity along the aircrafts bodyaxes in the boundary layer of the Earth (BL stands for Boundary Layer), which ranges from ground level to a height of about 300 m. The wind velocity and direction (both in the horizontal plane and the vertical plane) can be freely dened as a function of the altitude. By default, a wind velocity function according to ref.[1] is used, the wind direction is assumed to be constant, and the vertical wind component is set to zero. Equations For 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], [ms1 ]:
Vw = Vw 9.15 H 0.2545 0.4097 1.3470 Vw = 2.86585 Vw9.15
(0 < h < 300m) (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, [ms1 ]:

Vwhor = Vw cos w Vwvert ww = Vw sin w where w is the vertical wind direction angle, i.e. the angle between the wind vector and the horizontal plane. Horizontal components of the wind velocity, aligned along the Earth-xed reference frame, [ms1 ]: uw = Vwhor cos(w ) vw = Vwhor sin(w ) where w is the horizontal wind direction angle, i.e. the direction from where the horizontal component of the wind (Vwhor ) emanates, measured relatively to the magnetic north (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, [ms1 ]:
B E Vw = ( T T T ) Vw
where T , T , and T represent the transformation matrices corresponding to Euler rotations, and the superscripts denote the applicable reference frame. This transformation has been written out in more detail in appendix A, equation (A.4). The angles w and w may be dened as a function of the height above ground, similar to the 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 BLwind structure by means of a Saturation block, which has been hidden beneath the mask interface of BLwind. The height above ground is extracted from the twelfth element of the input vector, which has the same denition as the state vector x from the aircraft model. However, it should be noted that this element actually represents the altitude of the airplane above sea-level, which means that the equations are only valid when ground-level and sea-level coincide!
168
Inputs x = [ V p q r xe ye H ] T Outputs [ uw vw ww ] T
state vector from the aircraft model, x
wind velocities along aircrafts body-axes, [uw,vw,ww]
Parameters BLwind does not require any workspace parameters to be specied. The user may change the equations for the wind velocity, horizontal wind direction, and vertical wind direction in the mask dialog, which is opened after double-clicking the block BLwind. In these equations, u[1] denotes the height above ground-level (which is assumed to be equal to the altitude above sea-level, as explained above). Connections in: 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 the aircraft model (since the body-axes wind-components are in general not constant across the ight-path of the airplane, it will be necessary to compute the timederivatives of the wind velocity components too, using an additional Derivative block the vector uwind can be constructed by muxing the output vector from BLwind with the time-derivative from this Derivative block). Type browse blwind at the command-line for on-line help.
169
Cwind
Main FDC library / Wind and turbulence / Wind models / Cwind Wind and turbulence library / Wind models / Cwind
Type Masked subsystem block. Description The block Cwind calculates components of the wind velocity along the aircrafts body-axes for a constant wind (C stands for Constant). The user can specify the wind velocity and direction (both in the horizontal plane and the vertical plane). Equations For a detailed discussion of the equations from the block Cwind, refer to section 4.1.
Horizontal and vertical components of the wind velocity, [ms1 ]: Vwhor = Vw cos w Vwvert ww = Vw sin w where w is the vertical wind direction angle, i.e. the angle between the wind vector and the horizontal plane. Horizontal components of the wind velocity, aligned along the Earth-xed reference frame, [ms1 ]: uw = Vwhor cos(w ) vw = Vwhor sin(w ) where w is the horizontal wind direction angle, i.e. the direction from where the horizontal component of the wind (Vwhor ) emanates, measured relatively to the magnetic north (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, [ms1 ]:
B E Vw = ( T T T ) Vw
where T , T , and T represent the transformation matrices corresponding to Euler rotations, and the superscripts denote the applicable reference frame. This transformation has been written out in more detail in appendix A, equation (A.4). Inputs x = [ V p q r xe ye H ] T Outputs [ uw vw ww ] T
state vector from the aircraft model, x wind velocities along aircrafts body-axes, [uw,vw,ww]
Parameters Cwind does not require any workspace parameters to be specied. The user must specify the wind velocity, horizontal wind direction, and vertical wind direction in the mask dialog, which is opened after double-clicking the block Cwind. Connections in: 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 the aircraft model (since the body-axes wind-components are in general not constant across the ight-path of the airplane, it will be necessary to compute the timederivatives of the wind velocity components too, using an additional Derivative block the vector uwind can be constructed by muxing the output vector from Cwind with the time-derivative from this Derivative block). Type browse cwind at the command-line for on-line help.
170

Main library / Wind & turbulence / Atmosph. turb. models / Turbulence Group 1 Wind and turbulence library / Atmospheric turbulence models / Turbulence Group 1
Turbulence Group 1
Type Non-masked subsystem.
Description The subsystem Turbulence Group 1 determines longitudinal, lateral, and vertical turbulence velocity components along the body-axes of the aircraft, plus their time-derivatives, using Dryden lters with constant coefcients. The user must specify the mean airspeed, scale length, and standard deviation in each of the Dryden lters from this subsystem (longitudinal, lateral, and vertical). Variations of the lter coefcients with the airspeed are neglected, as the inuence of such variations is usually rather small. If this limitation is not acceptable, use Turbulence Group 2 instead. Subsystems and/or blocks The subsystem Turbulence Group 1 contains three blocks:
UDRYD1 VDRYD1 WDRYD1
generates the turbulence velocity component along the XB -axis of the aircraft (longitudinal turbulence), and its time-derivative, generates the turbulence velocity component along the YB -axis of the aircraft (lateral turbulence), and its time-derivative, generates the turbulence velocity component along the ZB -axis of the aircraft (vertical turbulence), and its time-derivative.
Inputs None. Outputs uwind = [ 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 the same structure as the input vector uwind for the aircraft model. However, in the case of the aircraft model, this vector is meant to take into account deterministic wind components, as well as stochastic turbulence. Parameters
Turbulence Group 1 does not require any workspace parameters to be specied. The user
must specify the scale lengths Lu g ,v g ,wg , the standard deviations u g ,v g ,wg , and the estimated mean value of the true airspeed for which the motions are evaluated for each of the three blocks UDRYD1, VDRYD1, and WDRYD1; double-click these blocks to open the mask-dialogs that allow you to dene these block parameters. Connections in: no connections. out: uwind can be connected to the input-side of the aircraft model (see the description of Beaver Level 1 in chapter 8). If simulations involve deterministic wind components, the wind components need to be added to the outputs from this subsystem rst, before entering the aircraft model. Type browse turb1 at the command-line for on-line help.
171
Turbulence Group 2
Type Non-masked subsystem.
Main library / Wind & turbulence / Atmosph. turb. models / Turbulence Group 2 Wind and turbulence library / Atmospheric turbulence models / Turbulence Group 2
Description The subsystem Turbulence Group 2 determines longitudinal, lateral, and vertical turbulence velocity components along the body-axes of the aircraft, plus their time-derivatives, using Dryden lters with airspeed-dependent coefcients. The user must specify the scale length and standard deviation in each of the Dryden lters from this subsystem (longitudinal, lateral, and vertical). Variations of the lter coefcients are computed on-the-y, as a function of the airspeed. Since the resulting variations in lter characteristics are usually relatively small, the turbulence library also offers a simplied subsystem Turbulence Group 1, which uses constant lter coefcients. Subsystems and/or blocks The subsystem Turbulence Group 2 contains three blocks:
UDRYD2 VDRYD2 WDRYD2
generates the turbulence velocity component along the XB -axis of the aircraft (longitudinal turbulence), and its time-derivative, generates the turbulence velocity component along the YB -axis of the aircraft (lateral turbulence), and its time-derivative, generates the turbulence velocity component along the ZB -axis of the aircraft (vertical turbulence), and its time-derivative.
true airspeed of the aircraft, V
Inputs V Outputs uwind = [ 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 the same structure as the input vector uwind for the aircraft model. However, in the case of the aircraft model this vector is meant to take into account deterministic wind components, as well as stochastic turbulence. Parameters
Turbulence Group 2 does not require any workspace parameters to be specied. The user
must specify the scale lengths Lu g ,v g ,wg and the standard deviations u g ,v g ,wg for each of the three blocks UDRYD2, VDRYD2, and WDRYD2; double-click these blocks to open the mask-dialogs that allow you to dene these block parameters. Connections in: 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 of Beaver Level 1 in chapter 8). If simulations involve deterministic wind components, the wind components need to be added to the outputs from this subsystem rst, before entering the aircraft model. Type browse turb2 at the command-line for on-line help.
172

Main FDC library / Wind and turbulence / Atmospheric turbulence models / UDRYD1 Wind and turbulence library / Atmospheric turbulence models / UDRYD1
UDRYD1
Type Masked subsystem block. Description The block UDRYD1 computes the longitudinal turbulence velocity component, which is aligned along the XB -axis of the aircraft, together with its time-derivative, using a longitudinal Dryden lter with constant coefcients. The user must specify the longitudinal scale-length of the turbulence Lu g , the standard deviation u g , and the (expected) mean airspeed of the aircraft. UDRYD1 does not take into account variations of the lter coefcients with the airspeed, as the inuence of those variations is usually very small; if this limitation is not acceptable, use UDRYD2 instead. Equations For a detailed discussion of the equations from the block UDRYD1 and the underlying theory, refer to section 4.2.
Longitudinal turbulence velocity, [ms1 ]:

u g (s) = Hu g w1 (s) w1 (s) where w1 is a white noise signal, that is generated internally by a white-noise generator within the block UDRYD1, and Hu g w1 is the transfer function of the longitudinal turbulence velocity lter.
Transfer function of the longitudinal turbulence lter:

Hu g w1 (s) = u g 2Lu g V 1+ 1
Lu g V
Note: the value of the airspeed V, used by UDRYD1, is kept constant during simulations. This value must be specied by the user; obviously, the most realistic result is obtained by specifying the (estimated) mean velocity of the airplane. If very large variations in airspeed are anticipated, use the block UDRYD2 instead. Inputs None. Outputs ug ug Parameters
UDRYD1 does not require any workspace parameters to be specied. The user must speclongitudinal turbulence velocity, ug time-derivative of longitudinal turbulence velocity, ug dot
ify the scale length Lu g , the standard deviation u g , and the estimated mean value of the true airspeed for which the motions are evaluated in the mask dialog, which is opened after double-clicking the block UDRYD1. Connections in: no connections. out: u g and u g are usually combined with other turbulence velocities and their timederivatives in a single vector that can be connected on the input side of the aircraft model (through the uwind port). Type browse udryd1 at the command-line for on-line help.
173
UDRYD2
Main FDC library / Wind and turbulence / Atmospheric turbulence models / UDRYD2 Wind and turbulence library / Atmospheric turbulence models / UDRYD2
Type Masked subsystem block. Description The block UDRYD2 computes the longitudinal turbulence velocity component, which is aligned along the XB -axis of the aircraft, together with its time-derivative, using a longitudinal Dryden lter with coefcients that will vary with airspeed. The user must specify the longitudinal scale-length of the turbulence Lu g and the standard deviation u g , but the lter coefcients of UDRYD2 are computed on-the-y, as a function of the airspeed. Since the resulting variations in lter characteristics are usually relatively small, the turbulence library also offers the simplied block UDRYD1, which uses constant lter coefcients. Equations For a detailed discussion of the equations from the block UDRYD2 and the underlying theory, refer to section 4.2.
Longitudinal turbulence velocity, [ms1 ]:

u g (s) = Hu g w1 (s) w1 (s) where w1 is a white noise signal, that is generated internally by a white-noise generator within the block UDRYD2, and Hu g w1 is the transfer function of the longitudinal turbulence velocity lter.
Transfer function of the longitudinal turbulence lter:

Hu g w1 (s) = u g 2Lu g V 1+ 1
Lu g V
Note: the lter coefcients are computed on-the-y, as a function of the actual value of the airspeed V. In practice, the transfer-function has been implemented in the form of its block-diagram equivalent, which was determined using the theory from section 6.4.2; the gains in this block-diagram are scheduled as a function of V. Inputs V Outputs ug ug Parameters
UDRYD2 does not require any workspace parameters to be specied. The user must
true airspeed of the aircraft, V longitudinal turbulence velocity, ug time-derivative of longitudinal turbulence velocity, ug dot
specify the scale length Lu g , and the standard deviation u g in the mask dialog, which is opened after double-clicking the block UDRYD2. Connections in: the airspeed V is usually extracted from the state vector x of the nonlinear aircraft model. out: u g and u g are usually combined with other turbulence velocities and their timederivatives in a single vector that can be connected on the input side of the aircraft model (through the uwind port). Type browse udryd2 at the command-line for on-line help.
174

Main FDC library / Wind and turbulence / Atmospheric turbulence models / VDRYD1 Wind and turbulence library / Atmospheric turbulence models / VDRYD1
VDRYD1
Type Masked subsystem block. Description The block VDRYD1 computes the lateral component of the turbulence velocity, which is aligned along the YB -axis of the aircraft, together with its time-derivative, using a lateral Dryden lter with constant coefcients. The user must specify the lateral scale-length of the turbulence Lv g , the standard deviation v g , and the (expected) mean airspeed of the aircraft. VDRYD1 does not take into account variations of the lter coefcients with the airspeed, as the inuence of those variations is usually very small; if this limitation is not acceptable, use VDRYD2 instead. Equations For a detailed discussion of the equations from the block VDRYD1 and the underlying theory, refer to section 4.2.
Lateral turbulence velocity, [ms1 ]:

v g (s) = Hv g w2 (s) w2 (s) where w2 is a white noise signal, that is generated internally by a white-noise generator within the block VDRYD1, and Hv g w2 is the transfer function of the lateral turbulence velocity lter.
Transfer function of the lateral turbulence lter: Lv 2Lv g 1 + 3 Vg s Hv g w2 (s) = v g 2 Lv V 1 + Vg s

Note: the value of the airspeed V, used by VDRYD1, is kept constant during simulations. This value must be specied by the user; obviously, the most realistic result is obtained by specifying the (estimated) mean velocity of the airplane. If very large variations in airspeed are anticipated, use the block VDRYD2 instead. Inputs None. Outputs vg vg Parameters
VDRYD1 does not require any workspace parameters to be specied. The user must speclateral turbulence velocity, vg time-derivative of lateral turbulence velocity, vg dot
ify the scale length Lv g , the standard deviation v g , and the estimated mean value of the true airspeed for which the motions are evaluated in the mask dialog, which is opened after double-clicking the block VDRYD1. Connections in: no connections. out: v g and v g are usually combined with other turbulence velocities and their timederivatives in a single vector that can be connected on the input side of the aircraft model (through the uwind port). Type browse vdryd1 at the command-line for on-line help.
175
VDRYD2
Main FDC library / Wind and turbulence / Atmospheric turbulence models / VDRYD2 Wind and turbulence library / Atmospheric turbulence models / VDRYD2
Type Masked subsystem block. Description The block VDRYD2 computes the lateral component of the turbulence velocity, which is aligned along the YB -axis of the aircraft, together with its time-derivative, using a lateral Dryden lter with coefcients that will vary with airspeed. The user must specify the lateral scale-length of the turbulence Lv g and the standard deviation v g , but the lter coefcients of VDRYD2 are computed on-the-y, as a function of the airspeed. Since the resulting variations in lter characteristics are usually relatively small, the turbulence library also offers the simplied block VDRYD1, which uses constant lter coefcients. Equations For a detailed discussion of the equations from the block VDRYD2 and the underlying theory, refer to section 4.2.
Lateral turbulence velocity, [ms1 ]:

v g (s) = Hv g w2 (s) w2 (s) where w2 is a white noise signal, that is generated internally by a white-noise generator within the block VDRYD2, and Hv g w2 is the transfer function of the lateral turbulence velocity lter.
Transfer function of the lateral turbulence lter: Lv 2Lv g 1 + 3 Vg s Hv g w2 (s) = v g 2 Lv V 1 + Vg s

Note: the lter coefcients are computed on-the-y, as a function of the actual value of the airspeed V. In practice, the transfer-function has been implemented in the form of its block-diagram equivalent, which was determined using the theory from section 6.4.2; the gains in this block-diagram are scheduled as a function of V. Inputs V Outputs vg vg Parameters
VDRYD2 does not require any workspace parameters to be specied. The user must spectrue airspeed of the aircraft, V lateral turbulence velocity, vg time-derivative of lateral turbulence velocity, vg dot
ify the scale length Lv g and the standard deviation v g in the mask dialog, which is opened after double-clicking the block VDRYD2. Connections in: the airspeed V is usually extracted from the state vector x of the nonlinear aircraft model. out: v g and v g are usually combined with other turbulence velocities and their timederivatives in a single vector that can be connected on the input side of the aircraft model (through the uwind port). Type browse vdryd2 at the command-line for on-line help.
176

Main FDC library / Wind and turbulence / Atmospheric turbulence models / WDRYD1 Wind and turbulence library / Atmospheric turbulence models / WDRYD1
WDRYD1
Type Masked subsystem block. Description The block WDRYD1 computes the vertical component of the turbulence velocity, which is aligned along the ZB -axis of the aircraft, together with its time-derivative, using a vertical Dryden lter with constant coefcients. The user must specify the vertical scale-length of the turbulence Lwg , the standard deviation wg , and the (expected) mean airspeed of the aircraft. WDRYD1 does not take into account variations of the lter coefcients with the airspeed, as the inuence of those variations is usually very small; if this limitation is not acceptable, use WDRYD2 instead. Equations For a detailed discussion of the equations from the block WDRYD1 and the underlying theory, refer to section 4.2.
Vertical turbulence velocity, [ms1 ]:

w g (s) = Hwg w3 (s) w3 (s) where w3 is a white noise signal, that is generated internally by a white-noise generator within the block WDRYD1, and Hwg w3 is the transfer function of the vertical turbulence velocity lter.
Transfer function of the vertical turbulence lter: Lw 2Lwg 1 + 3 Vg s Hwg w3 (s) = wg 2 Lw V 1 + Vg s

Note: the value of the airspeed V, used by WDRYD1, is kept constant during simulations. This value must be specied by the user; obviously, the most realistic result is obtained by specifying the (estimated) mean velocity of the airplane. If very large variations in airspeed are anticipated, use the block WDRYD2 instead. Inputs None. Outputs wg wg Parameters
WDRYD1 does not require any workspace parameters to be specied. The user must
vertical turbulence velocity, wg time-derivative of vertical turbulence velocity, wg dot
specify the scale length Lwg , the standard deviation wg , and the estimated mean value of the true airspeed for which the motions are evaluated in the mask dialog, which is opened after double-clicking the block WDRYD1. Connections in: no connections. out: w g and w g are usually combined with other turbulence velocities and their timederivatives in a single vector that can be connected on the input side of the aircraft model (through the uwind port). Type browse wdryd1 at the command-line for on-line help.
177
WDRYD2
Main FDC library / Wind and turbulence / Atmospheric turbulence models / WDRYD2 Wind and turbulence library / Atmospheric turbulence models / WDRYD2
Type Masked subsystem block. Description The block WDRYD2 computes the vertical component of the turbulence velocity, which is aligned along the ZB -axis of the aircraft, together with its time-derivative, using a vertical Dryden lter with coefcients that will vary with airspeed. The user must specify the lateral scale-length of the turbulence Lwg and the standard deviation wg , but the lter coefcients of WDRYD2 are computed on-the-y, as a function of the airspeed. Since the resulting variations in lter characteristics are usually relatively small, the turbulence library also offers the simplied block WDRYD1, which uses constant lter coefcients. Equations For a detailed discussion of the equations from the block WDRYD2 and the underlying theory, refer to section 4.2.
Vertical turbulence velocity, [ms1 ]:

w g (s) = Hwg w3 (s) w3 (s) where w3 is a white noise signal, that is generated internally by a white-noise generator within the block WDRYD2, and Hwg w3 is the transfer function of the vertical turbulence velocity lter.
Transfer function of the vertical turbulence lter: Lw 2Lwg 1 + 3 Vg s Hwg w3 (s) = wg 2 Lw V 1 + Vg s

Note: the lter coefcients are computed on-the-y, as a function of the actual value of the airspeed V. In practice, the transfer-function has been implemented in the form of its block-diagram equivalent, which was determined using the theory from section 6.4.2; the gains in this block-diagram are scheduled as a function of V. Inputs V Outputs wg wg Parameters
WDRYD2 does not require any workspace parameters to be specied. The user must
true airspeed of the aircraft, V vertical turbulence velocity, wg time-derivative of vertical turbulence velocity, wg dot
specify the scale length Lwg and the standard deviation wg , which is opened after doubleclicking the block WDRYD2. Connections in: the airspeed V is usually extracted from the state vector x of the nonlinear aircraft model. out: w g and w g are usually combined with other turbulence velocities and their timederivatives in a single vector that can be connected on the input side of the aircraft model (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 S IMULINK implementation of the VOR and ILS models from chapter 5. If you want to manipulate these blocks, or gain a better insight in the block structure, it is recommended to compare the internal block equations with the descriptions from this chapter. The internal block equations have been hidden behind a mask interface; refer to section 7.8 for more information about the mask interface of the FDC systems.
10.1
The radio-navigation blocklibrary
All radio-navigation blocks have been collected in the S IMULINK library NAVLIB, which is shown in gure 10.1. It can be accessed from the main FDC library (shown in gure 7.7 of chapter 7) by double-clicking the ILS/VOR radio-nav library button, or by typing navlib in the M ATLAB command-window. NAVLIB itself consists of two sublibraries: NAVLIB1, which contains the ILS models, and NAVLIB2, which contains the VOR models. These sublibraries have been shown in gures 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 descriptions of the individual blocks from the radio-navigation library. The blocks have been listed in alphabetical order; their locations have been referenced in relation to the main FDC library and the radio-navigation library.
10.1. The radio-navigation blocklibrary
181
Main FDC library / ILS/VOR radio-nav / ILS signals / GSerr Radio-navigation library / ILS signals / GSerr
GSerr
Description The block GSerr computes steady-state errors in the glideslope signal. The errors are expressed in terms of electrical currents, used to drive the glideslope deviation indicator in the cockpit. Equations For 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 + i gs The multiplication factor KSgs takes into account the offset in glideslope sensitivity Sgs , while the error i gs 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 instrument currents. Inputs igs,nominal Outputs igs,actual
nomimal glideslope current, igs (nominal) actual glideslope current, including steady-state errors, igs (actual)
Parameters The user must specify the ILS performance category (1, 2, or 3; see gure 5.6 from chapter 5), the offset in glideslope sensitivity, and the glideslope misalignment. The offsetvalues are both expressed as a percentage of the maximum allowable error shown in table 5.2. The parameters can be entered in the mask dialog, which can be opened by double-clicking GSerr. Connections in: 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. This signal 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.
182

Main FDC library / ILS/VOR radio-nav / ILS signals / GSnoise1 (2) Radio-navigation library / ILS signals / GSnoise1 (2)
GSnoise1 (2)
Type Masked subsystem blocks. Description The blocks GSnoise1 and GSnoise2 determine glideslope noise signals. GSnoise1 is based on a noise model from AGARD report R-632 [1], while GSnoise2 uses an alternative model from NASA report CR-2022 [22]. These reports have also been referenced in the block icons. The noise signals are expressed in terms of the electrical currents, used to drive the glideslope deviation indicator in the cockpit. Equations For a detailed discussion of the equations from the blocks GSnoise1 and GSnoise2, refer to section 5.1.2.
Glideslope noise, [A]: i (s) = Hgs (s) w4 (s) gs where i is the glideslope noise, w4 is a white noise signal, generated internally gs within the block GSnoise1 or GSnoise2, and Hgs is the transfer function of the glideslope noise lter. Transfer function of the glideslope noise lter according to AGARD R-632, used for GSnoise1: 2L gs 1 Hgs (s) = gs V 1 + L gs s
V
Note: the value of the airspeed V used by GSnoise1 is assumed to remain constant during the simulations. This is not entirely accurate, but if this value is set equal to the (nal) approach speed of the aircraft, the results are quite usable, keeping in mind that this equation only provides an approximation of actual glideslope noise anyhow. L gs is the scale-length of the glideslope noise; gs is the standard-deviation.
Transfer function of the glideslope noise lter according to NASA CR-2022, used for GSnoise2: 3.9875 Hgs (s) = 0.25 + s Inputs None.
Outputs i gs
glideslope noise, D_igs*
Parameters For the AGARD R-632 version (GSnoise1), the user must specify the scale length L gs , the standard deviation gs , and the approach speed of the aircraft. The parameters can be set in the mask dialog, which is opened after double-clicking GSnoise1. The NASA CR-2022 version (GSnoise2) doesnt require any parameters to be entered. Connections in: no connections. out: i is meant to be added to the original glideslope current i gs . If steady-state errors gs are also taken into account, this summation must take place after sending the glideslope current through the block GSerr rst. The resulting signal can e.g. be used as an input signal for an automatic approach controller. Type browse gsnoise at the command-line for on-line help.
183
Main FDC library / ILS/VOR radio-nav / ILS signals / ILS Radio-navigation library / ILS signals / ILS
ILS
Description The block ILS determines the nominal ILS signals for a given position of the aircraft. The block also computes some closely associated properties, which provide more information about the current position of the aircraft with respect to the runway and the glideslope and localizer reference planes. The validity of the glideslope and localizer signals is veried by an internal masked subsystem block, called ILStest. Equations For 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 through the ILS indicators in the cockpit, [A]:
i gs = Sgs gs iloc = Sloc loc
Glideslope and localizer deviation angles, [rad]: Hf gs = gs + arctan R gs dloc loc = arcsin Rloc Coordinates of the aircraft in the horizontal plane of the runway-xed reference frame, [m]:
xf =
( xe x RW ) cos RW + (ye y RW ) sin RW
y f = ( xe x RW ) sin RW + (ye y RW ) 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 nominal glidepath, [m]:
d gs = ( R gs tan gs + H f ) cos gs
Ground-distances from the aircraft to the glideslope and localizer transmitters, [m]:
R gs = Rloc =
( x gs x f )2 + (y f y gs )2
y f 2 + ( xloc x f )2
Two ags, which show whether the position of the airplane allows accurate reception of the glideslope and localizer signals, are determined with logical Boolean expressions, derived from the glideslope and localizer coverage diagrams from gures 5.5 and 5.3 in chapter 5. These ags are called GS_ag and LOC_ag, respectively; they are set equal to 1 if the signals are reliable, and 0 if they are not. These ags are computed in the internal masked subsystem block ILStest; type browse ilstest at the command-line for more information about this block.
Inputs uils
= [ xe ye H ] T
aircraft coordinates and altitude, uils
184
Outputs yils1 yils2 yils3 yils4
= = = =
[ i gs iloc ]T [ gs loc ]T [ x f y f H f d gs R gs Rloc ]T [ GS_ag LOC_ag ]T
nominal currents through ILS indicators, yils1 angles between nominal and current ILS planes, yils2 distances dening the aircrafts approach position, yils3 ags dening the validity of the ILS signals, yils4
Parameters The following parameters can be dened in the mask dialog of ILS, which can be opened by double-clicking this block: the runway heading RW , the coordinates x RW , y RW , and HRW of the origin of the runway-xed reference frame, measured with respect to the Earth-axes, the distance xloc from the runway threshold to the localizer antenna, measured along the runway centerline (see gure 5.1), the distance x gs from the threshold to the position on the runway centerline that is perpendicular to the glideslope antenna (see gure 5.1), the distance y gs from the glideslope antenna to the position on the runway centerline that is perpendicular to the glideslope antenna (see gure 5.1), the nominal glideslope angle gs . Connections in: 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 steadystate error blocks GSerr and LOCerr, which both express ILS offset errors in terms of electrical currents for the cockpit indications. The other output vectors are normally primarily used for evaluations of simulation results. ILS example sends all outputvectors to the M ATLAB workspace by means of To Workspace blocks. Type browse ils at the command-line for on-line help.
185
ILS example
Main FDC library / ILS/VOR radio-nav / ILS signals / ILS example Radio-navigation library / ILS signals / ILS example
Type Masked subsystem block (contents accessible without unmasking). Description The subsystem ILS example demonstrates how the nominal ILS block ILS and the error blocks GSerr, GSnoise1, LOCerr, and LOCnoise1 can be combined to build a complete ILS simulation model. The subsystem has been masked to generate an appropriate blockicon, but its contents are accessible without unmasking (hence, its light-blue background colour). Slightly modied versions of this block have been included in the autopilot blocklibrary APlib; see chapter 15 for more information. Subsystems and/or blocks The subsystem ILS example contains ve masked subsystem blocks:
ILS GSerr GSnoise1 LOCerr
computes the nominal ILS signals, incorporates a steady-state error in the glideslope signal, computes glideslope noise, 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 to apply the alternative noise blocks GSnoise2 and LOCnoise2 it is necessary to update this subsystem. Since noise will cause simulations to slow down considerably, the ILS blocklibrary 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 currents, needed to drive the cockpit instruments. In ILS example, these signals are converted back to the error angles gs and loc by multiplication with the factors 1/Kgs and 1/Kloc , respectively. Inputs x = [ V p q r xe ye H ] T Outputs gs loc
glideslope deviation angle, including system offset and noise, epsilon_gs localizer deviation angle, including system offset and noise, Gamma_loc
During simulations, the time-trajectories of the nominal ILS signals (excluding ILS offseterrors and noise!) and some interim results from the block ILS are collected in the M ATLAB workspace variable yils. Each row from this matrix corresponds to the vector yils at a certain data-point: yils = [ yils1 T yils2 T yils3 T yils4 T ] T with: yils1 yils2 yils3 yils4
= = = =
[ i gs iloc ]T [ gs loc ]T [ x f y f H f d gs R gs Rloc ]T [ GS_ag LOC_ag ]T
nominal currents through ILS indicators, yils1 angles between nominal and current ILS planes, yils2 distances dening the aircrafts approach position, yils3 ags dening the validity of the ILS signals, yils4
The ags in yils4 provide information about the validity of the ILS signals, based on the
186
ILS coverage depicted in gures 5.5 and 5.3 of chapter 5. See section 5.1.1 for more information about the nominal ILS signals and approach geometry. Note: to plot the resulting time-trajectories of the ILS signals, it is necessary to create a compatible time-basis in the M ATLAB workspace as well. This can be achieved by including a Clock block, which is connected to a To Workspace block, but in the special case where the subsystem ILS 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 the aircraft model itself. Parameters The user must manually specify the parameters of ILS, GSerr, GSnoise1, LOCerr, and LOCnoise1 and the multiplication blocks 1/Sgs and 1/Sloc by double-clicking these blocks individually. For the ILS block, this includes setting the runway heading, Earth-coordinates of the origin of the runway-xed reference frame, the position of the glideslope and localizer antennas relatively to the runway threshold, and the nominal glideslope angle. For the GSerr and LOCerr blocks, it is necessary to dene the ILS performance category, the offset percentages, and the nominal glideslope angle or the distance between the runway threshold and localizer antenna. The GSnoise1 and LOCnoise1 blocks require the denition of a scale length, the standard deviation of the noise, and the nal approach speed of the airplane. And nally, the multiplication factors 1/Kgs and 1/Kloc require the denition of the nominal glideslope angle and the distance from the threshold to the localizer antenna. Note: some parameters have to be dened multiple times in different blocks within ILS example; it is up to the user to make sure that all parameters are set consistently! Connections in: 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: 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 discussed in chapter 15 (these systems use slightly modied versions of ILS example, which have been included in the library APlib). The other signals are primarily used to evaluate simulation results; yils is sent to the M ATLAB workspace for postsimulation processing. Type browse ilsxmpl at the command-line for on-line help.
187
Main FDC library / ILS/VOR radio-nav / ILS signals / LOCerr Radio-navigation library / ILS signals / LOCerr
LOCerr
Description The block GSerr computes steady-state errors in the localizer signal. The errors are expressed in terms of electrical currents, used to drive the localizer deviation indicator in the cockpit. Equations For 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 deviation from the extended runway centerline. The signals are expressed in terms of cockpit instrument currents. Inputs iloc,nominal Outputs iloc,actual
nomimal localizer current, iloc (nominal) actual localizer current, including steady-state errors, iloc (actual)
Parameters The user must specify the ILS performance category (1, 2, or 3; see gure 5.6 from chapter 5), the offset in localizer sensitivity, the localizer misalignment, and the distance from the runway threshold to the localizer antenna. The offset-values are both expressed as a percentage of the maximum allowable error according to table 5.1. The parameters can be entered in the mask dialog, which can be opened by double-clicking LOCerr. Connections in: 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. This signal 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.
188

Main FDC library / ILS/VOR radio-nav / ILS signals / LOCnoise1 (2) Radio-navigation library / ILS signals / LOCnoise1 (2)
LOCnoise1 (2)
Type Masked subsystem blocks. Description The blocks LOCnoise1 and LOCnoise2 determine localizer noise signals. LOCnoise1 is based on a noise model from AGARD report R-632 [1], while LOCnoise2 uses an alternative model from NASA report CR-2022 [22]. These reports have also been referenced in the block icons. The noise signals are expressed in terms of the electrical currents, used to drive the localizer deviation indicator in the cockpit. Equations For a detailed discussion of the equations from the blocks LOCnoise1 and LOCnoise2, refer to section 5.1.2.
Localizer noise, [A]: iloc (s) = Hloc (s) w5 (s) where iloc is the localizer noise, w5 is a white noise signal, generated internally within the block LOCnoise1 or LOCnoise2, and Hloc is the transfer function of the localizer noise lter. Transfer function of the localizer noise lter according to AGARD R-632, used for LOCnoise1: 1 2Lloc Hloc (s) = loc V 1 + Lloc s
V
Note: the value of the airspeed V used by LOCnoise1 is assumed to remain constant during the simulations. This is not entirely accurate, but if this value is set equal to the (nal) approach speed of the aircraft, the results are quite usable, keeping in mind that this equation only provides an approximation of actual localizer noise anyhow. Lloc is the scale-length of the localizer noise; loc is the standard-deviation.
Transfer function of the localizer noise lter according to NASA CR-2022, used for LOCnoise2: 5 (1.5 + s) Hloc (s) = (0.35 + s)(10 + s) Inputs None.
Outputs iloc
localizer noise, D_iloc*
Parameters For 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 can be set in the mask dialog, which is opened after double-clicking LOCnoise1. The NASA CR-2022 version (GSnoise2) doesnt require any parameters to be entered. Connections in: no connections.
out: iloc 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 localizer current through the block LOCerr rst. The resulting signal can e.g. be used as an input signal for an automatic approach controller. Type browse locnoise at the command-line for on-line help.
189
Main FDC library / ILS/VOR radio-nav / VOR signals / VOR Radio-navigation library / VOR signals / VOR
VOR
Description The block VOR computes the nominal VOR signals that will be received on board the aircraft if it ies at a certain position relatively to the VOR ground station. In addition, it computes the ground-distance to the VOR antenna, warning ags which alert the user if the aircraft ies outside the VOR range, and a ag that tells us whether the airplane is heading to or from the VOR station. Equations For 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 yVOR xe 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 ag (C.O.S.-ag) is set equal to 1 if the airplane ies inside the Cone of Silence region, i.e. if:
arctan H HVOR RVOR
> 90 (40 to 60 )
In practice, the smallest cone-size has been used; this corresponds to an opening angle of 2 40 . See gure 5.12 in chapter 5 for more details. A Range ag is set to 1 if the aircraft ies outside the area where the VOR signals can reliably be received, i.e. if: RVOR > Range where: Range = 1000 2.3570 106 ( H HVOR )2 + 5.7087 102 ( H HVOR ) + 80.8612
A To/From ag is set to 1 if the aircraft is heading towards the VOR station, i.e. if: | QDR| > 90
Inputs uvor
= [ xe ye H ] T
aircraft coordinates and altitude, uvor heading of the aircraft, psi
Outputs yvor1 = VOR yvor2 = RVOR yvor3 = [ C.O.S.-ag Range-ag ]T yvor4 = ToFrom
nominal VOR bearing, excluding system offset, yvor1 ground distance from aircraft to VOR station, yvor2 ags specifying validity of VOR signals, yvor3 To/From ag, yvor4
Parameters The user must specify the coordinates of the VOR station measured in the horizontal plane, relative to the initial position of the aircraft. Also, the elevation of the VOR station
190
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. Connections in: 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 the steady-state error block VORerr. The other outputs are normally primarily used for evaluations of simulation results. VOR example sends the combined outputvector yvor to the M ATLAB workspace by means of a To Workspace block. Type browse vor at the command-line for on-line help.
191
Main FDC library / ILS/VOR radio-nav / VOR signals / VORerr Radio-navigation library / VOR signals / VORerr
VORerr
Description The 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 VOR deviation angle, not an electrical current. Also, the FDC toolbox does not include VOR noise models. Equations The steady-state error is implemented by multiplying the nominal VOR signal with a gain value that is slighty offset from the nominal value 1. Some experimental measurements of 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 bearing. It is equal to 1 + 100 with the overall percentile VOR system error, specied by the user. Inputs VOR,nominal Outputs VOR,actual
nomimal VOR bearing, Gamma_VOR (nominal) indicated VOR bearing, includes system offset, Gamma_VOR (actual)
Parameters The user must specify the overall VOR system error, expressed in a percentage of the nominal value. This gure can be entered after double-clicking the block VORerr. Connections in: 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 controller. Type browse vorerr at the command-line for on-line help.
192

Main FDC library / ILS/VOR radio-nav / VOR signals / VOR example Radio-navigation library / VOR signals / VOR example
VOR example
Type Masked subsystem block (contents accessible without unmasking). Description The subsystem VOR example demonstrates how the blocks VOR and VORerr can be combined to build a complete VOR simulation model. The subsystem has been masked to generate an appropriate block-icon, but its contents are accessible without unmasking (hence, its light-blue background colour). A slightly modied version of this block has been included in the autopilot blocklibrary APlib; see chapter 15 for more information. Subsystems and/or blocks The subsystem VOR example contains two masked subsystem blocks:
VOR VORerr
computes the nominal VOR signal, incorporates a steady-state error in the VOR signal.
Inputs x = [ V p q r xe ye H ] T Outputs VOR
VOR bearing, including system offset, Gamma_VOR
During simulations, the time-trajectories of the VOR signals and some interim results from the block VOR are collected in the M ATLAB workspace variable yvor. Each row from this matrix corresponds to the vector yvor at a certain data-point, which is dened as: yvor = [ yvor1 yvor2 yvor3 T yvor4 ] T with: yvor1 yvor2 yvor3 yvor4 VOR RVOR [ C.O.S.-ag Range-ag ]T ToFrom
= = = =
nominal VOR bearing, excluding system offset, yvor1 ground distance from aircraft to VOR station, yvor2 ags specifying validity of VOR signals, yvor3 To/From ag, yvor4
C.O.S. is an abbreviation for Cone of Silence, which has been discussed in section 5.2.2. Information about the range of the VOR signals (i.e. the VOR coverage) can also be found there. For information about the To/From ag, see section 5.2.1. Note: to plot the resulting time-trajectories of the VOR signals, it is necessary to create a compatible time-basis in the M ATLAB workspace as well. This can be achieved by including a Clock block, which is connected to a To Workspace block, but in the special case where 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 the aircraft model itself. Parameters The user must manually specify the parameters of VOR and VORerr by double-clicking these blocks individually. For the VOR block, this includes setting the Earth-axes X and Ycoordinates 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 is the reference radial set on the VOR deviation indicator in the cockpit. See section 5.2.1 for more details about these parameters. In the VORerr block, the percentile VOR system error must be set some guidelines have been provided in section 5.2.3.
193
Connections in: 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: 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 discussed in chapter 15 (these systems use a slightly modied version of VOR example from the library APlib). The other signals are primarily used to evaluate simulation results; yvor is sent to the M ATLAB 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 interacting with the simulation models and analytical tools, taking care of tasks such as toolbox initialisation, directory selection, data handling, on-line help display, and screen formatting. In addition, some model-specic functions help with the denition of model parameters and the presentation of simulation results. Some of the more generic support utilities may be useful for other applications too. This chapter provides a detailed overview of all FDC support functions. With a few exceptions, all programs discussed here are located in the PROGRAMS subdirectory of the FDC toolbox. See the previous chapter for a description of the analytical functions of the FDC toolbox; see chapter 15 for information about the support utilities 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 can roughly distinguish ve main categories: 1. Toolbox initialisation functions Initialisation of the toolbox is handled by the utility FDC, which calls the functions FDCINIT and FDC_SPLASH and displays a welcome message. FDCINIT appends the FDC directories to the M ATLAB path, and provides a simple user interface to change these directories when required, e.g. in order to enhance the toolbox with new models or tools; FDC_SPLASH displays a splash-screen for the FDC toolbox. 2. Directory functions The function FDCDIR assists in obtaining full pathnames of arbitrary FDC subdirectories. DATADIR and HELPDIR provide quick pointers to the DATA and HELP subdirectories, using FDCDIR to build the respective directory paths. 3. Data load functions The function FDCLOAD is used to retrieve FDC datales in general. DATLOAD, LINLOAD, MATLOAD, and TRILOAD apply this utility to retrieve datales with extensions . DAT, . LIN, . MAT, and . TRI, respectively.
208
Chapter 12. Support functions reference
4. Generic helper functions BROWSE displays HTML helples in the default web browser or the M ATLAB help browser, NEWMSGBOX displays simple message boxes, NUM2STR2 converts numericals to strings, SCREENSIZE returns screen dimensions in several units, and TXTMENU displays menus of choices in the M ATLAB commandwindow. 5. Model-specic helper functions MODBUILD is used to generate the datale AIRCRAFT. DAT, which contains the aircraft model parameters. FIXSTATE can be used to initialize the xx block in the S IMULINK model of the aircraft (see chapter 8), RESULTS re-orders aircraft simulation results in the M ATLAB workspace, and RESPLOT is a quick and dirty plotting function to visualise those results. In the next sections these support functions will be described in more detail. Type help fname , helpwin fname , or browse fname to obtain on-screen help for the function fname in the M ATLAB command-window, the M ATLAB help window, or your web browser (or alternatively: the M ATLAB help browser), respectively.
12.2
Toolbox initialisation functions
The toolbox initialisation is handled by the startup utility FDC. It calls two other support functions: FDC_SPLASH, which displays a splash-screen, and FDCINIT, which maintains a list of FDC directories to be appended to M ATLAB search path and allows the user to modify this list if required.
12.2.1
FDC
The startup utility FDC organises the initialisation of the FDC toolbox. A detailed explanation of all steps involved in the installation and initialisation of the toolbox has already been given in section 7.4, but in short the initialisation procedure comes down 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 of directories shown in the command window. FDC will rst call FDC_SPLASH, which displays the splash-screen from gure 7.2, and next FDCINIT, which manages the list of FDC directories and appends them to the M ATLAB search path (gures 7.3 to 7.5). Finally, the welcome message from gure 7.6 will be shown to indicate that the software is ready. The source le FDC . M is located in the FDC root-directory, to provide easy access; FDC _ SPLASH . M and FD CINIT. M are located in the PROGRAMS subdirectory. The modications made to the M ATLAB search path by FDCINIT remain effective until M ATLAB itself is closed; they are not stored permanently. For this reason, the initialisation routine FDC needs to be run every time the toolbox is to be used after starting a new M ATLAB session. If the toolbox is used frequently, it may be convenient to permanently include the FDC root-directory to the M ATLAB path, so that FDC can be started right away by typing fdc, without having to navigate to the FDC root-directory rst.
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 for the FDC directories to be appended to the M ATLAB path, in order to obtain direct command-line access to all functions, models, and helples. The function FDCINIT handles this task, and it provides a simple user-interface to accommodate changes in the FDC directory structure, which may be useful should the toolbox ever be reorganised or enhanced in the future. Figure 12.1 shows the default directory structure of the FDC toolbox. See section 7.6 for an explanation of the purpose of these directories. $ FDCROOT $ represents the default location of the root-directory of the FDC toolbox, which is equal to: $ FDCROOT $ = $ MATLABROOT $ \ TOOLBOX \ FDC 14 with $ MATLABROOT $ being the root-directory of M ATLAB itself. By default, FDCINIT uses this directory list for the toolbox initialisation; these are the default directories to be appended to the M ATLAB path. If the directory list does not correspond to the actual directory structure, it can be modied by the user, using the relevant menu options from FDCINIT. For instance, in section 7.4 it was explained how the FDCINIT menu options can be used to specify a different 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 M ATLAB path after the user conrms the directory denitions. The conrmed list will be stored in the le FDC . INI in the directory PROGRAMS (the location that also holds the le FDCINIT. M). Each next time FDCINIT is started, it will use the list from FDC . INI instead of the default list from gure 12.1. The default list will be used if the le FDC . INI cannot be found; deleting this le makes FDCINIT behave as if it was run for the rst time.
210
Notice that FDCINIT will not verify if specied directories actually exist. Therefore, if the user uses the options to add, remove, or rename (sub-) directories, a mismatch between the actual structure of the toolbox and the directory list used by FDCINIT will occur. It is the responsibility of the user to ensure that the directory list used by FDCINIT corresponds to the actual situation. Although the options to change the directories provide exibility, the mandatory directory verication during initialisation may become rather inconvenient if you dont intend to change the directory structure often. For this reason, FDCINIT offers an option to suppress the directory-check for future sessions. To restore the directory modication options afterward, it is necessary to delete the le FDC . INI. Figure 7.5 shows the directory verication 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 gure 7.2, until the user presses Enter or clicks inside the splash-screen with the mouse pointer. It is relatively easy to modify this function to display other kinds of graphics, so re-using the splash-screen code for other purposes is quite possible. The source-le FDC _ SPLASH . M can be found in the directory PROGRAMS.
12.3
Directory functions
Some FDC functions require access to specic subdirectories. To assure exibility and maintainability of the code, especially with regard to future changes and enhancements, a dedicated function FDCDIR is used to determine the full pathnames of FDC directories. The functions DATADIR and HELPDIR handle the special cases of locating the FDC data and help directories, respectively.
12.3.1
FDCDIR
The utility FDCDIR generates full pathnames for FDC directories. In practice, this feature is primarily used to locate the DATA and HELP directories of the FDC toolbox, but it can handle other subdirectories too. This offers the exibility that is required to 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 specied in the string variable NAME. D = fdcdir(NAME1,NAME2) returns the complete path of the FDC sub-subdirectory specied in the string variable NAME2, which itself is contained in the FDC subdirectory specied in the string variable NAME1. More input arguments are allowed to specify deeper subdirectory levels, which may be useful for future toolbox enhancements currently, this option is not yet very practical. Notice that all input arguments must be string variables.
12.4. Data load functions
211
Examples: Lets assume that the FDC root-directory as specied in ated by the function FDCINIT) is: c:\matlab\toolbox\fdc14 (using MS Windows path separators for convenience; replace these by the relevant symbology 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 specied path actually exists; a warning message will be displayed if the path cannot be found. Since ..\fdc14\models\aircraft is not a standard FDC directory, the above examples will in fact cause this path warning message to be displayed, unless this directory was created by the user.
FDC . INI
(which was gener-
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 obtained 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 directory hard-coding, two simple wrapper functions DATADIR and HELPDIR were created to take care of these FDCDIR calls. All other FDC functions that need to know the location of these directories will simply call these wrapper functions, instead of hard-coding the actual pathname or calling FDCDIR directly. If you ever create additional FDC functions that require access to these directories, it is highly recommended to use the same strategy. DATADIR can be run by simply typing datadir at the command-line, which will yield 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 the string $ FDCROOT $ \ HELP. Should the location of these directories ever be changed in the future (for whatever reason), the only les that need to be changed to reect this 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 various kinds of information, such as model parameters, trimmed ight conditions, and
212
system matrices of linearized models. Although different le-extensions will be used to distinguish different kinds of data, all datales will use the M ATLAB data format which is normally used for MAT-les. Model parameter les can be recognized by the extension . DAT, linearized model datales use the extension . LIN, and trimmed ight conditions use the extension . TRI. A support function FDCLOAD allows quick retrieval of arbitrary datales from the data-directory, while some dedicated functions are available to retrieve les of a specic type (e.g. DATLOAD for DAT-les).
12.4.1
FDCLOAD
The utility FDCLOAD retrieves datales from the FDC data-directory, using a graphical user-interface that is built on the UIGETFILE command of M ATLAB. The datadirectory is used as starting point to browse through the datales; the exact location of this directory is retrieved using the function DATADIR (see section 12.3.2). Usage: fdcload(ext) opens a le browser, listing all les with extension ext that are present in the data directory, and loads the selected le into the base workspace. fdcload(ext,datatype) additionally allows the specication of a short description of the data type, which will be shown in the title bar of the le browser window (see for instance gure 12.2, where the specied datatype description is model-definition data). In both cases, the user can select a le from the list, or navigate to a different directory to select a le from elsewhere. It is allowed to use wildcards ? and *, and the leextension may have more than three characters. Double extensions are possible too, e.g. ext1.ext2. In addition, a default lename can be specied by replacing ext by [filesep filename.ext], where filename.ext is the required default le. Notice that there is no initial protection against specifying a non-existing lename; a warning message will be displayed only when the user actually tries to open a non-existing le from the load dialog window. If the selected le does exist, it will be downloaded into the base workspace when the user clicks the Open button. Nothing will happen if the Cancel button is clicked instead or if the load dialog window is closed. Regardless of the specied extension, the datale must use the M ATLAB le-format (i.e. the format normally used for MAT-les); FDCLOAD uses the LOAD command with the -mat option. FDCLOAD does not yet support ASCII datales. To change this load behaviour, it will be necessary to edit the FDCLOAD . M le accordingly.
12.4.2
DATLOAD, LINLOAD, MATLOAD, and TRILOAD
The following default le-extensions are used to store specic types of FDC data:
DAT -les, LIN -les, TRI -les,
used to store model denition data (e.g. aircraft model parameters),
used to store system matrices of linearized aircraft models, used to store trimmed ight conditions.
12.4. Data load functions
213
Figure 12.2: File browser window that is displayed when using DATLOAD
In addition, MAT-les may be used to store general M ATLAB data. The functions DATLOAD, LINLOAD, TRILOAD, and MATLOAD have been designed to simplify the handling of these datales. They each call FDCLOAD for their respective le-extension, which means that an appropriately congured le-browser will be displayed, allowing the user to select a le for loading into the base M ATLAB workspace. Usage: datload will open a le browser, listing all available DAT-les in the FDC datadirectory. The user must select a le from the list; no default le is specied. It is still possible to select a different letype and/or navigate to a different directory, using the selection options from the le browser. datload(fname) does the same, but pre-selects the le fname.dat. The le, extension, and directory can be overruled via the le browser. linload, matload, and triload do the same for LIN-, MAT-, and tively, again allowing optional pre-selection of a specic le. Example: Figure 12.2 shows the le browser that will be displayed after typing datload at the command-line.1 In this example, the le AIRCRAFT. DAT has been selected by the user (and thus highlighted in the le list); this le will be loaded into the base workspace if the user subsequently clicks on the Open button. An almost similar situation will be seen when typing datload(aircraft), except that in that case the lename AIRCRAFT. DAT will be highlighted in the File name eld, instead of the le-list.
1 The gure shows what the le browser will look like on a Windows system. The lay-out will differ for other operating systems, but the functionality of the le browser will be roughly the same.
TRI -les,
respec-
214
12.5
Generic helper functions
A collection of helper functions assist with other support tasks, such as displaying on-line help information, screen formatting, string formatting, and showing message boxes. These helper functions are generic in nature, which means that they may be re-used for other purposes than the FDC toolbox too.
12.5.1
BROWSE
The function BROWSE displays HTML les using the default web browser or the M ATLAB help browser. It provides a convenient way to implement an on-line help system for M ATLAB toolboxes and S IMULINK blocksets, based on HTML formatting and linking. Although it was specically designed to deal with FDC helples, it can also be used to display HTML les from other sources. In comparison to the standard M ATLAB WEB command, BROWSE provides a more user-friendly way to handle the names of the requested helple and its source directory. By default, the standard web browser is used instead of the M ATLAB help browser. One reason for this choice is that early versions of the M ATLAB help browser may have problems with modern web technologies such as Cascading Style Sheets, but the browser choice in general is mainly a matter of personal preference. To use the M ATLAB help browser instead, an optional argument -mlhelp must be included in the function call; see the examples below. BROWSE builds on the WEB command of M ATLAB. Depending on your M ATLAB version, WEB may not support browsers other than Netscape 4 or Internet Explorer version 4 and later. If your browser is not supported, it is recommended to always use the optional argument -mlhelp when using BROWSE. It is also possible to change the default browser choice for the function BROWSE by editing the le BROWSE . M accordingly. Usage: browse name or browse(name) opens the specied HTML le in the standard web browser browse name -mlhelp or browse(name,-mlhelp) opens the HTML le in the M ATLAB help browser (this switch is functional only for M ATLAB release 12 and later, as earlier M ATLAB releases did not yet contain a help browser). Example: Consider the helple C : \ TOOLBOX \ HELPFILES \ FILENAME . HTML. In order to display this le in the web browser, the following entries for name are valid: the full path, including the lename and the le-extension: C : \ TOOLBOX \ HELPFILES \ FILENAME . HTML a part of the pathname, including the lename and the le-extension: HELPFILES \ FILENAME . HTML the lename and le-extension only:
FILENAME . HTML
12.5. Generic helper functions
215
the full path, including the lename, but excluding the le-extension: C : \ TOOLBOX \ HELPFILES \ FILENAME a part of the pathname, including the lename, but excluding the extension: HELPFILES \ FILENAME the lename only, excluding the le-extension:
FILENAME
The directory in which the helple is located must be present in the M ATLAB search path. An error message will be shown if the specied le cannot be found. Suitable le-extensions are .htm, .html, .HTM, and .HTML; all other extensions will be disregarded and will result in a le not found error, even if the le does exist! For instance, if a le README . TXT can be read from the M ATLAB path, browse(readme.txt) will still yield a le 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 M ATLABs MSGBOX function. Like MSGBOX it displays short messages in a dialog window, but NEWMSGBOX uses a different default font (improving readability) and it lacks the options to display an icon, specify the window style, or specify the text-interpreter. Usage: newMsgBox(Message) creates a message box that automatically wraps the Messagestring to t 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 the font settings for the message box. Font is a structure that contains the font definitions; valid elds are (default values for NEWMSGBOX are wrapped in curly braces): Font.FontAngle Font.FontUnits Font.FontWeight Font.FontName Font.FontSize [{ normal } | italic | oblique] [ inches | centimeters | normalized | { points } | pixels | data ] [ light | normal | demi | { bold } ] requested fontname | { default GUI fontname } requested fontsize | { default GUI fontsize }
(The default GUI fontname and fontsize can be observed from the FactoryUIControlFontName and FactoryUIControlFontSize screen-properties, respectively; see the M ATLAB documentation for more information.)
12.5.3
NUM2STR2
NUM2STR2 is a variant of M ATLABs NUM2STR function, which converts numbers to strings. It differs from NUM2STR in that it allows the user to specify the number of characters used for the string representation.
216
Usage: T = num2str2(X,C) returns a string T with C characters. X is the number to be converted 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 possible signs or decimal points). If a number does not t, it is rounded to a value which does t in C characters. If necessary, an exponent will be created, still within the reserved space of C characters. In that case the number of decimal places will be 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 converted to C = 6! This prevents problems that may occur when trying to show very large numbers in too few characters. However, you may still encounter strange results 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 and express them in several units of measurements. It is particularly useful for the positioning of gures 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 measurement represented 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 dened as follows: s = [left, bottom, width, height] where left and bottom are the coordinates of the bottom left point of the screen, and width and height represent the screen width and -height, expressed in the requested units of measurement. For pixel units, the coordinate pair [left,bottom] will always be equal 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 in the M ATLAB command window. The function mimics the behavior of the MENU command from older M ATLAB versions, which did not yet provide graphical userinterface functions. TXTMENU differs from the MENU command in M ATLAB version 4 or later in that it will always use the command-window regardless of the graphical capabilities of the workstation.
12.6. Model-specic 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. The number 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 a valid syntax. Example: K = txtmenu(Choose a colour,Red,Blue,Green) will display the following menu in the command window: Choose a colour: 1) Red 2) Blue 3) 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-specic helper functions
The support functions discussed in the previous sections were quite generic in nature; 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 with the denition of aircraft model parameters and the post-processing of aircraft simulation results. Helper functions for the autopilot models and open-loop example functions will be treated later in their respective chapters.
12.6.1
MODBUILD
The M ATLAB macro MODBUILD is used to build a datale containing aerodynamic, propulsive, geometrical, and mass-distribution parameters for the S IMULINK model of the Beaver dynamics. To maintain exibility, these parameters have not been hardwired within the S IMULINK model itself, but are read from the M ATLAB workspace each time the model is initialised. Obviously this makes it necessary to load the parameters into the M ATLAB 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 parameters, i.e., the stability and control derivatives of the Beaver, 2. the matrix EM (Engine Model), which contains the propulsive stability and control derivatives,
218
3. the vector GM1 (Geometry & Mass distribution), which contains the basic geometrical 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 coefcients. The exact denitions of these variables can be found in appendix C. The purpose of MODBUILD is to build these variables and save them to a datale. By default, the model parameters will be stored in AIRCRAFT. DAT in the subdirectory 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 already includes AIRCRAFT. DAT, it will normally not be necessary to run MODBUILD, unless the datale is inadvertently deleted. Please do not be mislead by the name MODBUILD, the utility does not actually build complete models, it merely denes their parameters! If it is desired to change the values of one or more model parameters (including mass and/or mass-distribution), the source le MODBUILD . M must be edited, as MODBUILD does not feature a user-interface to change parameter values interactively. However, this is less of an inconvenience than it may seem, because the user is assisted in identifying the individual parameters by the comment lines in MOD BUILD . M , and changing parameters usually wont be required very often.2 The le MODBUILD . M has been included in the AIRCRAFT directory, to reect its close relation to the aircraft model itself. It should be realized that the parameter structure used for the S IMULINK model of the Beaver is only one possible implementation of many. Obviously, there is a direct relation between the structure of the aircraft-dependent parts in this simulation model (see chapter 8) and the shape of the parameter matrices. Models of other aircraft may require different data structures. For instance, many models use a much more elaborate set of aerodynamic tables than the Beaver model. Theoretically, it might be possible to create stringent guidelines for the shapes of data structures, to streamline future model enhancements. However, this has not (yet) been considered for the FDC toolbox, as exibility is deemed more important. The current S IMULINK implementation of the aircraft model uses a generic overall framework with a series of aircraft-dependent and aircraft-independent blocks that function as black boxes. The exceptions to this rule (no formal denition of data structures) are the geometry and mass-distribution variables GM1 and GM2, because they are used for the generic aircraft-independent parts of the aircraft model. The shape of these variables is in fact stipulated by the structure of the subsystem Aircraft Equations of Motion, which basically forms the core of the aircraft simulation model.
1 The airplanes mass and the moments and products of inertia are treated as model parameters, as these properties are assumed to remain constant during the motions of interest. 2 If MODBUILD . M is edited to implement new parameter values, it is recommended to save this macro to a new le, e.g. MODBUILD 1. M. If some parameters are changed more frequently, it may be more convenient to include some degree of user-interaction in the MODBUILD program.
219
Since the mass and mass-distribution are assumed to be constant during simulations, MODBUILD also computes the inertia coefcients from equation (2.29) by substituting the pre-specied values of the moments and products of inertia into the aircraftindependent equations from table 2.2. Future versions of the toolbox may feature continuous computation of the geometrical and/or mass properties during simulations, which will make it possible to simulate vehicles with non-constant geometry or signicant sudden changes in mass and/or mass-distribution, e.g. airplanes with a variable wing-sweep or airplanes that drop signicant loads in-ight. In order to implement a different aircraft model within this framework, we must adapt or replace the aircraft-dependent parts, (e.g. the aerodynamic and propulsive models), perhaps changing some signal lines too. There are no formal requirements for the data structure of the parameters for these aircraft-dependent blocks: any data format that is supported by M ATLAB and S IMULINK 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 implementations of Aeromod and Engmod (and the corresponding parameter denitions) as a guideline or starting point, this is not required. However, it is recommended to re-use at least the MODBUILD . M code that denes GM1 and GM2, changing only the gures for the lengths, wing-surface, mass, and moments and products of inertia. Re-using this code not only saves time, but it also ensures that the data structure of GM1 and GM2 will remain compatible with the aircraft-independent parts in the S IMULINK model.
12.6.2
FIXSTATE
The utility FIXSTATE assists with the denition of a vector xx in the M ATLAB workspace, which is used as a multiplication factor by the block xx in the aircraft model (see chapter 8). This block is used to constrain state variables to their initial values for analytical purposes. Normally the state variables in the aircraft model are simply determined by the equations of motion, but in some cases it may be useful to articially force certain states to remain equal to their initial values. For instance, we may want to neglect longitudinal-lateral cross-coupling effects when studying the fundamental aircraft modes, or emulate an ideal Speed Hold ight control law by articially xing the value of the airspeed. To this means, the block xx performs an element-by-element multiplication of the time-derivative of the state vector, x, and a gain vector of the same length, xx. The elements of xx are identical to either one or zero, meaning: the actual derivative is either taken into account or completely disregarded. See chapter 8 for a detailed description of the block xx.
FIXSTATE offers four user choices, as shown in gure 12.3:
1. Fix asymmetrical state variables. This causes the variations in asymmetrical state variables , p, r, , and to be neglected, which effectively constrains the airplane to symmetrical motions only. In addition, FIXSTATE will ask whether the lateral Earth-coordinate ye needs to be xed as well.
220
Figure 12.3: Main menu of FIXSTATE
2. Fix symmetrical states. This causes the variations in the symmetrical state variables V, , q, and to be neglected, which effectively constrains the airplane to asymmetrical motions only. In addition, FIXSTATE will ask whether it should x the longitudinal Earth coordinate xe and the altitude H too. 3. Fix arbitrary states. After selecting this option, FIXSTATE will ask the user to specify a vector with the element numbers of the state variables to be xed. With the state vector being x = [ V p q r xe ye H ] T , we can for instance x and xe by specifying the vector [8 10], as and xe are the eighth and tenth elements of x, respectively. 4. Dont x any states. This option resets the default value of xx, being a unity vector of length 12, taking into account all state derivatives in order to allow all aircraft states to vary freely. The same effect can be achieved by deleting xx from the workspace altogether. After specifying the states to be xed, FIXSTATE will try to re-initialize the aircraft model. This is only possible if the initial value of the state vector xinco is present in the workspace. Such initial conditions can be loaded from datale with TRILOAD utility, computed in advance using the trim routine ACTRIM, or entered manually. If xinco cannot be found, a warning message will be displayed. FIXSTATE needs to be run (or xx needs to be dened manually) prior to simulations or other analysis requiring one or more aircraft states to be constrained to their initial values. For the common situation in which all states are allowed to vary freely, it will not be necessary to explicitly dene xx, as the block xx within the aircraft model will automatically use the default value of ones(1,12) if xx hasnt been dened.
221
12.6.3
RESULTS
During simulations of the Beaver model, the time-trajectories of the input and output signals are collected in the matrices In and Out. The denitions of these variables can be found in appendix D. The M ATLAB macro RESULTS extracts individual input- and output-trajectories from these matrices, using easy-to-understand variable names that closely resemble the symbols from appendix A (e.g. alpha for the angle of attack , or deltar for the rudder deection r ). This simplies post-simulation analysis, as a command such as plot(time,deltae) is much easier to remember than the equivalent plot(time,In(:,1)). RESULTS will only work correctly if the matrices In and Out correspond to the default denitions from appendix D. If the input/output denitions in the aircraft simulation model are changed, e.g. in order to add more observation variables, implement additional input signals, or rearrange the output matrix, it will be necessary to adapt the RESULTS program too. RESULTS is not able to detect changes in the denitions of the matrices In and Out itself and it does not offer any internal errorchecking mechanisms to protect against incorrect sizing or denition of the output matrices. The source le RESULTS . M is located in the PROGRAMS subdirectory.
12.6.4
RESPLOT
RESPLOT is a very simple M ATLAB script that plots time-trajectories of the most im-
portant input and output signals of the Beaver model. These signals are: the airspeed V, the angle of attack , the sideslip angle , the altitude H, the angular velocities p, q, and r, the Euler angles , , and , the control surface deections e , a , and r , and the wind velocity components uw , vw , and ww . The purpose of RESPLOT is to offer a quick overview of the simulation results only; advanced plotting functions or other visualisation tools are not provided. To change the appearance of the plots, or display other results, the RESPLOT. M sourcele must be edited. RESPLOT. M can be found in the PROGRAMS directory. Before running RESPLOT, all relevant time-trajectories need to be present in the M ATLAB workspace. This can be ensured by rst running RESULTS (after running a simulation involving the Beaver model). RESPLOT does not include error-checking routines to verify the availability of the required variables, it just quits with a hard error if those variables cannot be found in the workspace.
Appendix A
Symbols and denitions

This appendix denes the symbols used in this report, and all relevant reference frames and sign conventions. The units of measurements usually conform to S.I. conventions. Only in some incidental cases, usually involving equations obtained from other literature, non-standard units have been applied. If this is the case, the applied units will be mentioned specically in the main text. Due to the very large number of variables, it could not always be avoided to use the same symbols for multiple purposes, but most of the times this is not a serious problem, because the meaning of a particular symbol usually follows directly from the context in which it is used. In the few cases where there is a real chance of symbols getting mixed-up, these particular symbols may be overlined, to provide the necessary distinction. A list of variable names and acronyms used in the FDC toolbox has been included in appendix E. Several important aircraft model parameters have been listed in appendix B, while appendix C explains the format which was used to implement the aircraft model parameters in S IMULINK.
A.1
a a x,k ay,k az,k Ax Ay Az b c CD C1 C2 Cl Cm Cn CX CY
List of symbols
[ ms1 ] [g] [g] [g] [g] [g] [g] [m] [m] [ rad ] [] [] [] [] [] [] [] speed of sound kinematic acceleration along XB -axis kinematic acceleration along YB -axis kinematic acceleration along ZB -axis output of accelerometer (specic force) in c.g. along XB -axis output of accelerometer (specic force) in c.g. along YB -axis output of accelerometer (specic force) in c.g. along ZB -axis wing-span mean aerodynamic chord course datum (selected VOR bearing) engine model parameter engine model parameter non-dimensional moment about XB -axis (rolling moment) non-dimensional moment about YB -axis (pitching moment) non-dimensional moment about ZB -axis (yawing moment) non-dimensional force along XB -axis non-dimensional force along YB -axis
286
Appendix A. Symbols and denitions
CZ D d gs dloc dpt FB FE FM FR FS FV FW Fx Fy Fz fpa g h h H Hf HRW i i gs Ii iloc Ix Iy Iz Jxy Jxz Jyz k K... L L Lg Lu Lv Lw m M M Ma M0 n N p P
[] [N] [m] [m] []
non-dimensional force along ZB -axis total aerodynamic drag distance from aircraft to nominal glideslope line distance from aircraft to extended runway centerline pt = non-dimensional pressure increase across propeller 1 2 body-xed reference frame, see section A.7.1 Earth-xed reference frame, see section A.7.1 measurement reference frame, see section A.7.1 special body-xed reference frame for the Beaver, see section A.7.1 stability reference frame, see section A.7.3 vehicle-carried vertical reference frame, see section A.7.1 ight-path reference frame, see section A.7.1 total external force along XB -axis, see gure 2.1 total external force along YB -axis, see gure 2.1 total external force along ZB -axis, see gure 2.1 ight-path acceleration acceleration of gravity pressure altitude step-size for numerical integration geopotential altitude height above aerodrome level runway elevation above sea level counter or iteration number glideslope current (ILS) inertia coefcient (i = 1, 2, . . . , 6, see table 2.2) localizer current (ILS) moment of inertia along XB -axis moment of inertia along YB -axis moment of inertia along ZB -axis product of inertia in XB YB -plane product of inertia in XB ZB -plane product of inertia in YB ZB -plane time-step for discrete systems, t kts gain factors for autopilot model, see table 14.3 total rolling moment, see gure 2.1 total aerodynamic lift general scale length for atmospheric turbulence scale length for turbulence velocity along XB -axis scale length for turbulence velocity along YB -axis scale length for turbulence velocity along ZB -axis mass of the aircraft Mach number total pitching moment, see gure 2.1 molecular weight of the air molecular weight of the air at sea level engine speed total yawing moment, see gure 2.1 angular rate of roll, see gure 2.1 engine power
2 V
[N] [N] [N] [g] [ ms2 ] [m] [s] [m] [m] [m] [] [ A ] [ kg m2 ] [ A ] [ kg m2 ] [ kg m2 ] [ kg m2 ] [ kg m2 ] [ kg m2 ] [ kg m2 ] [] [ Nm ] [N] [m] [m] [m] [m] [ kg ] [] [ Nm ] [ kg kmol1 ] [ kg kmol1 ] [ RPM ] [ Nm ] [ rad s1 ] [ Nm s1 ]
A.1. List of symbols

Pl , Pm , Pn , Ppp , Ppq , Ppr , Pqq , Pqr , Prr ps pz q qc qdyn Ql , Qm , Qn , Q pp , Q pq , Q pr , Qqq , Qqr , Qrr r R Ra Rc Re R gs Rloc Rl , Rm , Rn , R pp , R pq , R pr , Rqq , Rqr , Rrr S Sgs Sloc t ts T Tt u ug uw uwe v vg vw vwe V Vc Ve Vw Vw9.15 Va Ve Vr w w1 , w2 , w3
287
inertia coefcients for p-equation, see table 2.2 [ Nm2 ] [ Hg ] [ rad s1 ] [ Nm2 ] [ Nm2 ]
ambient or free-stream pressure manifold pressure angular rate of pitch, see gure 2.1 impact pressure dynamic pressure
inertia coefcients for q-equation, see table 2.2 [ rad s1 ] [ JK 1 kg1 ] [ JK 1 kmol1 ] [ ] [ m 1 ] [m] [m]
angular rate or yaw, see gure 2.1 R a /M0 , specic gas constant of air universal gas constant Reynolds number with respect to c Reynolds number per unit length ground distance from aircraft to glideslope transmitter (ILS) ground distance from aircraft to localizer transmitter (ILS)
inertia coefcients for r-equation, see table 2.2 [ m2 ] [ A rad1 ] [ A rad1 ] [s] [s] [K] [K] [ ms1 ] [ ms1 ] [ ms1 ] [ ms1 ] [ ms1 ] [ ms1 ] [ ms1 ] [ ms1 ] [ ms1 ] [ ms1 ] [ ms1 ] [ ms1 ] [ ms1 ] [V] [V] [V] [ ms1 ] [ ]
wing area sensitivity of the glideslope system (ILS) sensitivity of the localizer system (ILS) time sampling time (step-width for discrete systems) ambient or free-stream temperature total temperature velocity component along XB -axis component of the turbulence velocity along XB -axis wind velocity component along XB -axis wind velocity component along XE -axis velocity component along YB -axis component of the turbulence velocity along YB -axis wind velocity component along YB -axis wind velocity component along XE -axis true airspeed, see gure 2.1 calibrated airspeed equivalent airspeed wind velocity wind velocity at 9.15 m altitude (reference velocity) command signal to actuators (change in deection of the ailerons) command signal to actuators (change in elevator deection) command signal to actuators (change in rudder deection) velocity component along ZB -axis independent white noise signals
288
wg ww wwe W Xa xe xf Xgr Xp Ya ye yf Ygr Yp Za ze zf Zgr Zp gs gs loc VOR a e f r pt a e r gs gs loc u v w
[ ms1 ] [ ms1 ] [ ms1 ] [N] [N] [m] [m] [N] [N] [N] [m] [m] [N] [N] [N] [m] [m] [N] [N] [ rad ] [ rad ] [ rad ] [] [ rad ] [ rad ] [ rad ] [ rad ] [ rad ] [ rad ] [ rad ] [ rad ] [ Nm2 ] [ rad ] [ rad ] [ rad ] [ rad ] [ rad ] [ Km1 ] [ rad ] [ kg m1 s1 ] [ kg m3 ] [ A ] [ A ] [ ms1 ] [ ms1 ] [ ms1 ] [ rad ] [ rad ]
component of the turbulence velocity along ZB -axis wind velocity component along ZB -axis wind velocity component along XE -axis aircraft weight aerodynamic force along XB -axis X-coordinate in Earth-xed reference frame FE X-coordinate in runway-xed reference frame FF gravity force along XB -axis propulsive force along XB -axis aerodynamic force along YB -axis Y-coordinate in Earth-xed reference frame FE Y-coordinate in runway-xed reference frame FF gravity force along YB -axis propulsive force along YB -axis aerodynamic force along ZB -axis Z-coordinate in Earth-xed reference frame FE Z-coordinate in runway-xed reference frame FF gravity force along ZB -axis propulsive force along ZB -axis angle of attack, see gure 2.1 sideslip angle, see gure 2.1 ight-path angle ratio of specic heats of air nominal glide-path angle on nal approach (ILS glide-path) angle between localizer reference plane and the line through the ground position of the aircraft and the glideslope antenna angle between localizer reference plane and the line through the ground position of the aircraft and the localizer antenna angle between selected and actual VOR radial deection of ailerons (a = aright aleft ), see gure A.5 deection of elevator deection of aps deection of rudder increment increase of total pressure over the propeller change in deection of the ailerons change in elevator deection change in rudder deection glideslope error angle above/below the nominal ILS glide-path pitch angle temperature gradient (T/h) aerodynamic angle of roll dynamic viscosity air density standard deviation standard deviation of glideslope noise standard deviation of localizer noise standard deviation of turbulence velocity in XB -direction standard deviation of turbulence velocity in YB -direction standard deviation of turbulence velocity in ZB -direction roll angle bank angle
A.2. Vectors
289
w RW 0 n
[ rad ] [ rad ] [ rad ] [ rad ] [ rad s1 ] [ rad s1 ] [ rad s1 ] [ rad m1 ]
azimuth angle yaw angle wind direction (wind from the North: w = ) runway heading angular frequency natural frequency of undamped system natural frequency of damped system spatial frequency
A.2
a Caero Cprop F h M r u... V Vw x y...
Vectors
body-axes acceleration vector vector with non-dimensional aerodynamic force and moment coefcients vector with non-dimensional engine force and moment coefcients (propulsive) resulting force vector acting on rigid body; F = [ Fx Fy Fz ] T resulting angular momentum of rigid body about c.g.; h = [h x hy hz ] T resulting moment vector about c.g. of rigid body; M = [ L M N ] T position vector input vectors true airspeed vector wind velocity vector state vector output vectors rotational velocity vector
A.3
A B C D TPQ
Matrices
system matrix of linear state-space system input matrix of linear state-space system output matrix of linear state-space system due to x output matrix of linear state-space system due to u transformation matrix from a reference frame FP to a reference frame FQ transformation matrix for rst 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
f(t) g(t) H ( ) S( ) S()
Functions
general vector-equation for the time-derivatives of the state variables general vector-equation for the output variables frequency response of forming lter power spectral density function power spectral density function
A.5
0 0 a
Indices and subscripts

nominal value value at sea level ailerons
290
a aero c.g. dpt e e f f grav gs k loc p q r r RW prop VOR w wind we 2 3 f dpt2 2 dpt 2 3 a a e e 2 f r r
relative to the surrounding atmosphere (used for velocity components) aerodynamic forces and moments or force and moment coefcients center of gravity stability derivative with respect to non-dimensional pressure increase across propeller elevator relative to Earth axes (used for velocity components) aps referenced to runway-xed reference frame FRW , f stands for eld gravity force components related to glideslope deviation kinematic (used for accelerations) related to localizer deviation stability derivative with respect to non-dimensional rolling speed stability derivative with respect to non-dimensional pitching speed stability derivative with respect to non-dimensional yawing speed rudder runway, used for dening runway parameters engine forces and moments or force and moment coefcients (propulsive) related to VOR signals wind velocity and wind velocity components along body axes force components due to non-steady atmosphere wind velocity components along Earth axes stability derivative with respect to angle of attack stability derivative with respect to 2 stability derivative with respect to 3 stability derivative with respect to f stability derivative with respect to dpt2 stability derivative with respect to 2 dpt stability derivative with respect to sideslip angle stability derivative with respect to 2 stability derivative with respect to 3 stability derivative with respect to non-dimensional sideslip rate stability derivative with respect to deection of ailerons stability derivative with respect to a stability derivative with respect to deection of elevator stability derivative with respect to e 2 stability derivative with respect to deection of aps stability derivative with respect to deection of rudder stability derivative with respect to r
A.6
Abbreviations
Automatic Flight Control System Altitude Hold mode of the autopilot Altitude Select mode of the autopilot Computer Aided Control System Design Calibrated Airspeed Course Datum center of gravity De Havilland of Canada Ltd. Distance Measuring Equipment (radio-navigation)
AFCS ALH ALS CACSD CAS CD c.g. DHC DME
A.7. Reference frames and sign conventions
291
DUT FCC FCS FDC GA GPS GS HH IAS ILS IRS LOC MLS NAV NDB PAH ODE RAH STOL TAS VOR VTOL
Delft University of Technology Flight Control Computer Flight Control System Flight Dynamics and Control Go Around mode of autopilot Global Positioning System (satellite navigation) Glideslope mode of autopilot Heading Hold / Heading Select mode of the autopilot Indicated Airspeed Instrument Landing System (radio-navigation) Inertial Reference System Localizer mode of the autopilot Microwave Landing System (radio-navigation) VOR Navigation mode of the autopilot Non-Directional Beacon (radio-navigation) Pitch Attitude Hold mode of the autopilot Ordinary Differential Equation Roll Attitude Hold mode of the autopilot Short Take-off and Landing True Airspeed Very high frequency Omnidirectional Range Vertical Take-off and Landing
A.7
A.7.1
Reference frames and sign conventions

Denitions
Many different reference frames have been used throughout this report. The most important onces have been listed below: Body-xed reference frame FB : This is a right-handed orthogonal reference system which has its origin OB in the center of gravity of the aircraft. The XB OB ZB plane coincides with the aircrafts plane of symmetry if it is symmetrical, or it is located in 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 the right wing (starboard), and the ZB -axis points toward the bottom of the aircraft. Stability reference frame FS : This is a special body-xed reference frame, used in the study of small deviations from a nominal ight condition. The reference frames FB and FS differ in the orientation of their respective X-axes. The XS -axis is chosen parallel to the projection of the true airspeed vector V on the OB XB ZB plane (if the aircraft is symmetrical this is the plane of symmetry), or parallel to V itself in case of a symmetrical nominal ight condition. The YS -axis coincides with the YB -axis. Flight-path or wind reference frame FW : This reference frame, also called the wind reference frame, has its origin in the center of gravity of the aircraft. The XW -axis is aligned with the velocity vector of the aircraft and the ZW -axis coincides with the ZS -axis. Earth-xed reference frame FE : This reference frame, also called the topodetic reference frame [14] is a right-handed orthogonal system which is considered to be
292
xed in space. Its origin can be placed at an arbitrary position, but will be chosen to coincide with the aircrafts center of gravity at the start of a ight test manoeuvre. The ZE -axis points downwards, parallel to the local direction of gravity. The XE -axis is directed to the North, the YE -axis to the East. Vehicle-carried vertical reference system FV : This reference system has its origin at the 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 of gravity). These reference axes are always parallel to the Earth-xed reference axes, although the origin OV moves relatively to the Earth-xed reference frame. Measurement reference frame FM : This is a left-handed orthogonal reference frame that is used for correcting stability and control derivatives of the aircraft if position of the center of gravity differs from the one used during the ight tests. For the Beaver aircraft, the origin O M lies in a point, resulting from the perpendicular projection of the foremost point of the wing chord, parallel to the OB XB ZB plane [34]. The X M O M ZM -plane coincides with the OB XB ZB -plane. The positive X M -axis points to the tail of the aircraft, the positive YM -axis points to the left wing (port), and the positive ZM -axis points upwards. Special body-xed reference frame for the Beaver, FR : This is a special reference frame for the Beaver aircraft. It is identical to FB with one exception: its origin OR is placed in a body-xed reference point, which has been selected to coincide with a c.g. position that was actually used during one ight. It has the following coordinates in FM : x = 0.5996 m, y = 0 m, z = 0.8815 m, see ref.[34]. FR is used only to dene the moments and products of inertia for the aircraft condition on which the aerodynamic model was based; see table B.5 in appendix B. Runway-xed reference frame, FRW : This reference frame is used to dene the geometry of the nal 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 coincides with 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 from an aircraft on nal approach. See also gures 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 chapter 2, have been referenced to the body axes FB . The wind reference frame FW is often used to express aerodynamic forces and moments (the stability reference frame FS is closely related). The position of the airplane has been dened with respect to the Earth-xed reference frame FE , while the denition of the aircraft attitude in terms of the Euler angles , , and required the introduction of the vehicle-carried vertical reference frame FV . The runway-xed reference frame is used for the denition of the nal approach geometry, i.e. the position of the airplane in relation to the landing runway. Finally, two special body-xed reference frames FM and FR are used to dene the reference ight condition for the Beaver model in table B.5 of appendix B; these reference frames are not relevant for other purposes.
293
XV (north) YV (east) c.g. XE (north) r
YE (east)
ZV (down)
g ZE (down)
Figure A.1: Relationship between the vehicle-carried vertical reference frame FV and the Earth-xed reference frame FE
A.7.3
Relationships between the reference frames
In gure A.1 the relationship between the Earth-xed and vehicle-carried vertical reference systems is shown. As can be seen from this gure, FE and FV differ only in the position of their respective origins. The relationship between the vehicle-carried vertical and the body-axes has been shown in gure A.2. The Euler angles , , and dene the orientation of FB with respect to FV , hence they dene the attitude of the aircraft relatively to the surface of the Earth. Each of these Euler rotations can be expressed by a separate transformation matrix: cos sin 0 T = sin cos 0 (A.1) 0 0 1 cos 0 sin 0 T = 0 1 (A.2) sin 0 cos 1 0 0 T = 0 cos sin (A.3) 0 sin cos 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)
294
XV
t
YV
Horizontal plane
A rotation by about the ZV -axis to the intermediate position X Y ZV Z cV

I t
XB XV X
E
YV
Z cV Z XB
A rotation by about the Y -axis to the intermediate position XB Y Z
I t e e e e e e Y e e e e YV e YB e ZB e
XV X
A rotation by about the XB -axis to the nal position XB YB ZB
Z cV
Figure A.2: Relationship between the vehicle-carried vertical reference frame FV and the body-xed reference frame FB
295
XV
t
X Horizontal plane
YV
A rotation by about the ZV -axis to the intermediate position X Y ZV Z cV

XW
XV
t
YV
ZV c
A rotation by about the Y -axis to the intermediate position XW Y Z Z

XW
XV
t f f f f f f Y f f G Y f
YW
f f
ZV c
f Z
f x ZW f
A rotation by about the XW -axis to the nal position XW YW ZW
Figure A.3: Relationship between the vehicle-carried vertical reference frame FV and the ight-path reference frame FW
296
YB = YS XB o YW
XW o XS
V c.g.
ZB ZS = ZW
Figure A.4: Relationship between the body-xed reference frame FB , ight-path reference frame FW and stability reference frame FS
r (+)
e (+)
right
(+)
left
( )
a = a a right left
Figure A.5: Sign conventions for control surface deections
297
Thus, we nd the following relation between a vector y B in the body reference frame and yV in the vehicle-carried vertical reference frame: y B = TV B yV (A.5) The orientation of the ight-path axes with respect to the vehicle-carried vertical axes can also be expressed in terms of Euler angles, denoted by , , and . This is shown in gure A.3. The Euler angles , , and dene the orientation body axes FB in relation to the vehicle-carried vertical reference frame FV ; the angles , , and dene the orientation of the ight-path axes FW in relation to FV . Figure A.4 shows the relationships between the body, ight-path, and stability reference frames. These three reference systems all have their origin in the aircrafts center of gravity. The XW -axis is aligned with the velocity vector of the aircraft. The orientation of the ight-path axes with respect to the body-xed reference frame is dened by the angle of attack and the sideslip angle . The stability reference system is displaced from the ight-path axes by a rotation and from the body axes by a rotation . For the orientation of the runway-xed reference frame relatively to the Earthxed reference frame, refer to section 5.1.1. This section also shows how the aircraft coordinates can be expressed in terms of the runway-axes.
A.7.4
Sign conventions for deections of control surfaces
Figure A.5 shows the positive directions of control surface deections. To summarize: The positive elevator deection is measured downwards; a positive value of e results in a pitch-down moment for the aircraft. The deections of the rudder and ailerons are positive if they force the aircraft to turn to the left. If one aileron deection is positive, the deection of the opposite aileron consequently will be negative. The total aileron deection is dened as: a = a right a left . The ap angle is positive if the aps deect downwards (which they always do), similar to the elevator deection. A positive value of f results in an increase in lift and drag of the aircraft. Please be aware that other literature may use different denitions, especially for the aileron deection (some resources use the mean deection of the left and right ailerons, rather than the total deection).
Appendix B
Beaver model parameters

This appendix provides the values of several Beaver model parameters, as well as some general data for this aircraft. A description of the mathematical model itself can be found in chapter 3. Appendix C will explain the format that was used to implement these parameters in the M ATLAB/S IMULINK environment.
B.1
General aircraft data
From the late 1950s until the end of 1993, the Faculty of Aerospace Engineering of Delft University of Technology has operated a De Havilland DHC-2 Beaver aircraft, specially equipped as ying laboratory for ight research experiments. The Beaver is a high-winged, seven-seat, all metal aircraft. It is powered by a single Pratt & Whitney radial piston engine of 450 horsepower, which drives a two-bladed constant-speed propeller. A picture of the aircraft has been shown in gure B.1; some basic technical data has been presented in table B.1. The aircraft has a xed undercarriage. Under normal circumstances, the apsettings up (0 ), climb (15 ), and take-off (35 ) are used in ight. Other possible apsettings are landing (50 ) and full (58 ), but those are rarely applied in practice, due to the short take-off and landing (STOL) ight characteristics of the Beaver. The ight model data from ref.[34] were based on measurements in actual ights, which were made during the 1977-1978 period. Table B.2 lists some typical ight conditions for the Beaver.
B.2
Flight envelope
Figure B.2 shows the ight envelope of the Beaver, including the manoeuvre points that were used for the ight-test measurements from ref.[34]. The ight envelope was obtained from ref.[6]. Notice that the reported maximum altitude of 10000 feet is 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 of a built-in oxygen supply system that would be necessary for prolonged operation above 10000 feet. In addition, the reported never-exceed speed Vne according to gure B.2 is higher than the maximum speed from table B.1; the latter value probably representing 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 for the Beaver, see equations (3.3) and (3.7). These models are valid over a wide range of ight conditions, roughly covered by the ight envelope boundaries of gure B.2. The corresponding model parameters have been listed in tables B.3 and B.4, respectively. See ref.[34] for more details on how these parameters were obtained.
Manufacturer Serial no. Type of aircraft Wing span b Wing area S Mean aerodynamic chord c Wing sweep Wing dihedral Wing prole Fuselage length Height Max. take-off weight Empty weight Engine Max. power Propeller Diameter of the propeller Total contents of fuel tanks Contents fuselage front tank Contents fuselage center tank Contents fuselage rear tank Contents wing tanks Most forward admissible c.g. position Most backward admissible c.g. position Maximum speed Cruising speed Initial climb gradient Ceiling De Havilland Aircraft of Canada Ltd. 1244 Single engine, high-wing, seven seat, all-metal aircraft 14.63 m 23.23 m2 1.5875 m 0 1 NACA 64 A 416 9.22 m 2.74 m 22800 N 14970 N Pratt and Whitney Wasp Jr. R-985 450 Hp at n = 2300 RPM, pz = 26"Hg Hamilton Standard, two-bladed metal regulator propeller 2.59 m 521 l 131 l 131 l 95 l 2 x 82 l 17.36% c at 16989 N; 29.92% c at 22800 N 40.24% c 71.4 m/sec 58 m/sec 1020 f t/N M = 17% 5486 m
Table B.1: General aircraft data of the DHC-2 Beaver, PH-VTH. These data were obtained from refs.[34] and [29]; the latter gures 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
12000
tniop ervueonam epolevne thgilf
10000
5510
8000
] [
0 10
20
30
40
50
]
60
70
Figure B.2: The ight envelope of the De Havilland DHC-2 Beaver aircraft
Flight condition Take-off Climb Cruise Descend Approach
f [deg] 35 15/0 0 0 15
n [RPM] 2350 2000 1800 1800 2000
pz ["Hg] 36.5 30.0 28.0 15.0 15.0
V [kts] 70 70 100 120 80
Table B.2: Typical ight conditions for the Beaver (the given values are an average of normally applied ap deections, engine settings, and airspeeds); see ref. [34].
52.08 = enV
s/m V
57.62 = sV
H tf
6000
3506 4506 5506
4000
3004
2000
3502 4502 5502 6002
80
90
H [ft/min] 800/900 700/800 0 (level ight) -1000 -400/-500
302
Appendix B. Beaver model parameters
CX
parameter 0 2 3
qc V
CY
value parameter 0
pb 2V rb 2V
CZ
value parameter 0 3
qc V
value
r f f
0.03554 0.002920 5.459 5.162 0.6748 0.03412 0.09447

1.106
a r r
b 2V
0.002226 0.7678 0.1240 0.3666 0.02956 0.1158 0.5238 0.1600
e e 2 f f
0.05504 5.578 3.442 2.988 0.3980 15.93 1.377 1.261
Cl
parameter 0
pb 2V rb 2V
Cm
value 0.0005910 parameter 0 2
qc V
Cn
value 0.09448 parameter 0
pb 2V rb 2V
value
a r a
0.06180 0.5045 0.1695 0.09917 0.006934 0.08269
e 2
rb 2V
0.6028 2.140 15.56 1.921 0.6921 0.3118 0.4072
a r
qc V 3
0.003117 0.006719 0.1585 0.1112 0.003872 0.08265 0.1595 0.1373
Table B.3: Coefcients in the aerodynamic model of the Beaver, valid within the 35-55 ms1 TAS range
CX
parameter dpt dpt
2
CY
value 0.1161 0.1453 parameter value
CZ
parameter dpt value
0.1563
Cl
parameter 2 dpt value
Cm
parameter dpt value
Cn
parameter dpt3 value
0.01406
dpt pt 1 2 2 V
0.07895
P with: 3 2 V
0.003026
= C1 + C2 1
C1 = 0.08696 C2 = 191.18
Table B.4: Coefcients in the engine forces & moments model of the Beaver, valid within the 35-55 ms1 TAS range
B.3. Aerodynamic and engine model parameters
303
xc.g. yc.g. zc.g. Ixx Iyy Izz Jxy Jxz Jyz m h
= = = = = = = = = = = =
0.5996 0.0 -0.8851 5368.39 6928.93 11158.75 0.0 117.64 0.0 2288.231 1828.8 1.024
[m] [m] [m] [kg m2 ] [kg m2 ] [kg m2 ] [kg m2 ] [kg m2 ] [kg m2 ] [kg] [m] [kg m3 ]
in FM in FM in FM in FR in FR in FR in FR in FR in FR (= 6000 [ft])
Table B.5: Aircraft data on which the aerodynamic model of the Beaver is based (FM is the measurement reference frame, which has been dened in section A.7.1)
Appendix C
Data structure of the FDC model parameters

This appendix explains the data-format that was used to implement the parameters of the Beaver dynamics model in M ATLAB/S IMULINK. The numerical values of these parameters has been presented in appendix B; a detailed description of the S IMU LINK model itself can be found in chapter 8.
C.1
Dening the model parameters in the M ATLAB workspace
The aircraft model from the FDC toolbox reads its model data from the M ATLAB workspace. The exact structure of this data is highly dependent of the aircraft under consideration; for the Beaver, most parameters have been stored in three parameter matrices and one parameter vector. The parameters must be present in the M ATLAB workspace before running a simulation of the airplane model, or applying an analytical S IMULINK or FDC function to this model. This data-structure may not be suited for the implementation of different aircraft models within the FDC structure. Although any suitable data-structure can be used, it is recommended not to change the denitions of the vector GM1 and matrix GM2, which contain mass-distribution data and information about the airplanes geometry, 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 subsystems as well, contrary to the aerodynamic and propulsion parameter matrices AM and EM, which are used by aircraft-dependent blocks only. The parameters can be loaded from the le AIRCRAFT. DAT, which can normally be found in the DATA subdirectory, using the utility DATLOAD (see section 12.4.2). If this datale has somehow inadvertently been deleted, it can be re-created by running the program MODBUILD (see section 12.6.1). The denitions of the parameter vector and matrices for the Beaver model will be given below; the numerical values of the parameters have been listed in appendix B, along with some general information about the Beaver aircraft. To change the values of the parameters, e.g. in order to implement a model of a different aircraft, the easier method is to create a customized copy of MODBUILD . M. Since this M ATLAB macro has been heavily documented, it shouldnt be too dif-
306
Appendix C. Data structure of the FDC model parameters
cult to identify the aircraft-dependent parameters that need to be changed, and the generic aircraft-independent code that determines the inertia coefcients from table 2.2 of chapter 2. It is recommended to save the altered parameters to a new datale, such as AIRCRAFT 1 . DAT, BOEING 747 . DAT, or something similar. See section 12.6.1 for more details about MODBUILD.
C.2
Denition of the parameter matrices for the Beaver model
Aerodynamic model
The stability and control derivatives used by the aerodynamic model of the Beaver aircraft have been combined in the parameter matrix AM. The denition of AM has been given in table C.2, while the numerical values of these coefcients can be found in table B.3 from appendix B. The numerical values have been implemented in MODBUILD, which generates the datale AIRCRAFT. DAT. See section 3.3.1 for more details about the aerodynamic model itself.
Engine forces & moments model

The coefcients used by the propulsion model of the Beaver aircraft have been combined in the parameter matrix EM. The denition of EM has been given in table C.2, while the numerical values of these coefcients can be found in table B.4 from appendix B. The numerical values have been implemented in MODBUILD. See section 3.3.2 for 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 its mass-distribution are assumed to remain constant during the relatively short timeintervals considered in most simulations. These values have therefore been implemented 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 denition of GM1 has been given in table C.3, while the numerical values of these parameters can be found in tables B.1 and B.5 from appendix B. These numerical values have been implemented in MODBUILD. The parameter matrix GM2 contains the inertia coefcients from table 2.2 in chapter 2, with numerical values that correspond to the moments and products of inertia from the vector GM1. The denition of GM2 has also been given in table C.3. The equations from table 2.2 have been implemented in MODBUILD, to obtain the numerical values of these parameters.
C.2. Denition of the parameter matrices for the Beaver model
307
C X0 CX CX2 CX3 0 0 0 0 CXq 0 0 CX 0 CXr CX 0 0 0 0

1
f f
CY0 0 0 0 CY 0 0 CYp 0 CYr 0 0 CYa CYr 0 CYr 0 0 CY

2
CZ0 CZ 0 CZ3 0 0 0 0 CZq 0 CZe CZ 0 0 CZ 0 0 CZ 2

e f f
Cl0 0 0 0 Cl 0 0 Cl p 0 Clr 0 0 Cla Clr 0 0 Cla 0 0

4
Cm0 Cm Cm2 0 0 Cm2 0 0 Cmq Cmr Cme Cm f 0 0 0 0 0 0 0

5
Cn0 0 0 0 Cn 0 Cn3 Cn p Cnq Cnr 0 0 Cna Cnr 0 0 0 0 0

6
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
AM
0
3
Table C.1: Coefcients of the aerodynamic model of the Beaver
EM
CXdpt
0 0 0 0
2
CZdpt 0 0 0
3
0 0 0 Cl2 dpt
4
Cmdpt 0 0 0
5
0 Cndpt 0 0
6
T
1
0 C Xdpt2 0
1
2 3 4
Table C.2: Coefcients of the engine forces & moments model of the Beaver
308
Appendix C. Data structure of the FDC model parameters
GM1
c
1
b
2
S
3
Ixx
4
Iyy
5
Izz
6
Jxy
7
Jxz
8
Jyz
9
m
10
GM2
Pl
Pm Qm Rm
2
Pn Qn Rn
3
Ppp Q pp R pp
4
Ppq Q pq R pq
5
Ppr Q pr R pr
6
Pqq Qqq Rqq

7
Pqr Qqr Rqr

8
Prr Qrr Rrr

9
1 2 3
Ql Rl
1
Table C.3: Beaver geometry and mass-distribution
Appendix D
Data structure of the FDC model output signals

During simulations, several signals from the simulation models are logged in the M ATLAB workspace; these results can later be used for post-simulation analysis, such as trajectory plotting, or they can be saved to le. In this appendix, the dataformat for this output logging will be described, and an overview of the input and output signals used in the top-level of the aircraft model will be provided. See chapter 8 (in particular, the description of the Beaver Level 1 system) for more information about the aircraft model input/output structure; see chapter 10 for more information about the radio-navigation models.
D.1
Aircraft model signal logging
During simulations that involve the nonlinear aircraft model Beaver (or one of its subsystem equivalents; see chapter 8 for more information), all input and output signals are logged in the workspace variables In and Out, respectively. In addition, a matching time-axis is logged in the variable time. The reason for including the input signals is that these do not necessarily have to be pre-determined by the user; they may 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 to the length of the vector time, which corresponds with the total number of logged data points. Each column represents a time-trajectory of an individual input or output signal. 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 output 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 utility RESULTS can convert these matrices into human-legible variables for all individual input and output trajectories, while the macro RESPLOT can be used to provide a quick graphical overview of the time-trajectories stored in In and Out. See sections 12.6.3 and 12.6.4 for more information. The logged signals from the aircraft model correspond to the inputs and outputs of 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), but the outputs from the top-level only comprise a small subset of the 89 output signals logged in Out. This has been explained in more detail in the descriptions of Beaver Level 1 and Beaver Level 2 in the reference chapter 8. Table D.1 shows the denition of the resulting output vector from the aircraft model. This vector provides the necessary connection between the aircraft model and external systems; the current choice of signals provides enough information for the Beaver autopilot simulations from chapter 15. The information from tables D.3, D.2, and D.1 can also be displayed in your webbrowser or the M ATLAB help browser (depending on your M ATLAB-setup) by typing browse inputs or browse outputs on the command-line. More information about the utilities RESULTS and RESPLOT is available in the command-window by typing help results/help resplot, or in the webbrowser or M ATLAB help browser by typing browse results/browse resplot.
D.2
Radio navigation signal logging
During simulations involving the ILS example system ILS example, all important results are stored in the workspace variable yils. Simulations involving the VOR example system VOR example will store output information in yvor. These variables are again matrices, which have a similar structure as the matrices In and Out from the aircraft model. The ILS and VOR example systems do not create a separate time-axis, as this task is normally already done by the aircraft model (if ILS example and/or VOR example are used in combination with a model that does not 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 denitions of the matrices yils and yvor; the corresponding column-numbers are displayed underneath the symbols. See the description of the systems ILS example and VOR example in chapter 10 for more information.
Inputs:
e
1
a
2
r
3
f p
n
5
pz
6
uw
7
vw
8
ww
9
uw 10 xe
10
vw 11 ye
11
ww
12
Outputs:
V
1
2 pb 2V 14
3 qc V 15
q
5
r
6
H
12
4 rb 2V 16
H
13
Table D.1: Denition of the input and output signals of the aircraft model (see the description of Beaver Level 1 in chapter 8 for more information)
D.2. Radio navigation signal logging
311
Subvector
Output signals from the aircraft model, logged in the matrix Out
x x ybvel yuvw ydl yfp ypow yacc Caero Cprop FMaero FMprop Fgrav Fwind yatm yad1 yad2 yad3
V
1
p
4
q
5
r
6
xe 10 xe
22
ye 11 ye
23
H
12
V
13

14

15
p
16
q
17
r
18

19

20

21
H
24
u
25
v
26
w
27
u
28 pb 2V 31
v
29 qc V 32
w
30 rb 2V 33
34
fpa
35
36
37
dpt
38
P
39
Ax
40
Ay
41
Az
42
a x,k 43 Cla 49 Cl p 55 La 61 Lp 67
ay,k 44 Cma 50 Cm p 56 Ma
62
az,k 45 Cna 51 Cn p 57 Na
63
CX a 46 CX p 52 Xa
58
CYa 47 CYp 53 Ya
59
CZa 48 CZ p 54 Za 60 Zp
66
Xp
64
Yp
65
Mp
68
Np
69
Xgr
70
Ygr
71
Zgr 72 Zw 75 T
78
Xw
73
Yw
74
76
ps 77 M
82
79
g
80
a
81
qdyn 83 Vc 86 Rc 89
qc 84 Tt 87
Ve 85 Re 88
Table D.2: Logged output signals from the aircraft model. The time-trajectories of these 89 output signals are stored in the 89 corresponding columns of the matrix Out.
312
Appendix D. Data structure of the FDC model output signals
Subvector
Input signals from the aircraft model, logged in the matrix In
uaero uprop uwind
e
1
a
2
r
3
f
4
n
5
pz
6
uw
7
vw
8
ww
9
uw 10
vw 11
ww
12
Table D.3: Logged input signals for the aircraft model. The time-trajectories of these twelve input signals are stored in the twelve corresponding columns of the matrix In.
Subvector
Output signals from the system ILS example, logged in the matrix yils
yils1 yils2 yils3 yils4
igs 1 gs
3
iloc 2 loc
4
xf
5
yf
6
Hf
7
dgs
8
Rgs
9
Rloc 10
LOC_ag
11
GS_ag
12
Table D.4: Logged output signals from the ILS example model. The time-trajectories of these output signals are stored in the corresponding columns of the matrix yils.
Subvector
Output signals from the system VOR example, logged in the matrix yvor
yVOR1 yVOR2 yVOR3 yVOR4
VOR
1
RVOR
2
Cone of silence ag
3
Range ag
4
To/From ag
5
Table D.5: Logged output signals from the VOR example model. The time-trajectories of these 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 authorship (the Original Work) whose owner (the Licensor) has placed the following notice 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, royaltyfree, 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 Original Work; to distribute copies of the Original Work and Derivative Works to the public, with the proviso that copies of Original Work or Derivative Works that You 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, royaltyfree, non-exclusive, perpetual, sublicenseable license, under patent claims owned or controlled by the Licensor that are embodied in the Original Work as furnished by the Licensor, to make, use, sell and offer for sale the Original Work and Derivative Works. 3. Grant of Source Code License. The term Source Code means the preferred form of the Original Work for making modications to it and all available documentation describing how to modify the Original Work. Licensor hereby agrees to provide a machine-readable copy of the Source Code of the Original Work along with each copy of the Original Work that Licensor distributes. Licensor reserves the right to satisfy this obligation by placing a machine- readable copy of the Source Code in an information repository reasonably calculated to permit inexpensive and convenient access by You for as long as Licensor continues to distribute the Original Work, and by publishing the address of that information repository in a notice immediately following the copyright notice 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 of any contributors to the Original Work, nor any of their trademarks or service marks, may be used to endorse or promote products derived from this Original Work without express prior written permission of the Licensor. Nothing in this License shall be deemed to grant any rights to trademarks, copyrights, patents, trade secrets or any other intellectual property of Licensor except as expressly stated herein. No patent license is granted to make, use, sell or offer to sell embodiments of any patent claims other than the licensed claims dened in Section 2. No right is granted to the trademarks of Licensor even if such marks are included in the Original Work. Nothing in this License shall be interpreted to prohibit Licensor from licensing under different terms from this License any Original Work that Licensor otherwise would have a right to license. 5. External Deployment. The term External Deployment means the use or distribution of the Original Work or Derivative Works in any way such that the Original Work or Derivative Works may be used by anyone other than You, whether the Original Work or Derivative Works are distributed to those persons or made available as an application intended for use over a computer network. As an express condition for the grants of license hereunder, You agree that any External Deployment by You of a Derivative Work shall be deemed a distribution and shall be licensed to all under the terms of this License, as prescribed in section 1(c) herein. 6. Attribution Rights. You must retain, in the Source Code of any Derivative Works that You create, all copyright, patent or trademark notices from the Source Code of the Original Work, as well as any notices of licensing and any descriptive text identied therein as an Attribution Notice. You must cause the Source Code for any Derivative Works that You create to carry a prominent Attribution Notice reasonably calculated to inform recipients that You have modied the Original Work. 7. Warranty of Provenance and Disclaimer of Warranty. Licensor warrants that the copyright in and to the Original Work and the patent rights granted herein by Licensor are owned by the Licensor or are sublicensed to You under the terms of this License with the permission of the contributor(s) of those copyrights and patent rights. Except as expressly stated in the immediately proceeding sentence, the Original Work is provided under this License on an AS IS BASIS and WITHOUT WARRANTY, either express or implied, including, without limitation, the warranties of NON-INFRINGEMENT, MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY OF THE ORIGINAL WORK IS WITH YOU. This DISCLAIMER OF WARRANTY constitutes an essential part of this License. No license to Original Work is granted hereunder except under this disclaimer. 8. Limitation of Liability. Under no circumstances and under no legal theory, whether in tort (including negligence), contract, or otherwise, shall the Licensor be liable to any person for any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or the use of the 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 liability for death or personal injury resulting from Licensors negligence to the extent applicable law prohibits such limitation. Some jurisdictions do not allow the exclusion or limitation of incidental or consequential damages, so this exclusion and limitation may not apply to You. 9. Acceptance and Termination. If You distribute copies of the Original Work or a Derivative Work, You must make a reasonable effort under the circumstances to obtain the express assent of recipients to the terms of this License. Nothing else but this License (or another written agreement between Licensor and You) grants You permission to create Derivative Works based upon the Original Work or to exercise any of the rights granted in Section 1 herein, and any attempt to do so except under the terms of this License (or another written agreement between Licensor and You) is expressly prohibited by U.S. copyright 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 any of the rights granted to You by this License upon Your failure to honor the proviso in Section 1(c) herein. 10. Termination for Patent Action. This License shall terminate automatically and You may no longer exercise any of the rights granted to You by this License as of the date You commence an action, including a cross-claim or counterclaim, against Licensor or any licensee alleging that the Original Work infringes a patent. This termination provision shall not apply for an action alleging patent infringement by combinations of the Original Work with other software or hardware. 11. Jurisdiction, Venue and Governing Law. Any action or suit relating to this License may be brought only in the courts of a jurisdiction wherein the Licensor resides or in which Licensor conducts its primary business, and under the laws of that jurisdiction excluding its conict-of-law provisions. The application of the United Nations Convention on Contracts for the International Sale of Goods is expressly excluded. Any use of the Original Work outside the scope of this License or after its termination shall be subject to the requirements and penalties of the U.S. Copyright Act, 17 U.S.C. 101 et seq., the equivalent laws of other countries, and international treaty. This section shall survive the termination of this License. 12. Attorneys Fees. In any action to enforce the terms of this License or seeking damages relating thereto, the prevailing party shall be entitled to recover its costs and expenses, including, without limitation, reasonable attorneys fees and costs incurred in connection with such action, including any appeal of such action. This section shall survive the termination of this License. 13. Miscellaneous. This License represents the complete agreement concerning the subject matter hereof. If any provision of this License is held to be unenforceable, such provision shall be reformed only to the extent necessary to make it enforceable.
324
Appendix F. The Open Software License v. 2.1
14. Denition of You in This License. You throughout this License, whether in upper or lower case, means an individual or a legal entity exercising rights under, 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 common control with you. For purposes of this denition, control means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fty percent (50%) or more of the outstanding shares, or (iii) benecial ownership of such entity. 15. Right to Use. You may use the Original Work in all ways not otherwise restricted or conditioned by this License or by law, and Licensor promises not to interfere with or be responsible for such uses by You. This license is Copyright 2003-2004 Lawrence E. Rosen. All rights reserved. Permission is hereby granted to copy and distribute this license without modication. This license may not be modied without the express written permission of its copyright owner.
Bibliography
[1] Anon. Approach and Landing Simulation. AGARD report 632, Ames, 1975. [2] Anon. International Standards and Recommended Practices. Annex 10, Volume I, 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), Delft University of Technology, Faculty of Aerospace Engineering, Delft, 1984. [6] Abidin, Z.: Adaptive Self-Tuning Flight Control Systems The Multiple Model Approach. PhD-thesis, Delft University of Technology, Faculty of Aerospace Engineering, 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, Identication, and Simulation 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 Winston Inc., 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 ight control systems. Lockheed Aeronautical Systems Company, Burbank, California, USA, 1988. [13] Cook, J.M., Zyda, M.J., Pratt, D.R., McGhee, R.B.: NPSNET: Flight Simulation Dynamic Modeling Using Quaternions. Naval Postgraduate School, Department 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 Denition of a Linear Aircraft Model. NASA Reference Publication 1207, USA, 1988. [15] Etkin, B., Reid, L.D.: Dynamics of Flight Stability and Control. Wiley, New York, USA, 3nd edition, 1996.
330
BIBLIOGRAPHY
[16] Fogarty, L.E., Howe, R.M.: Computer mechanization of six degree-of-freedom ight equations. NASA Contractor Report 1344, USA, 1969. [17] Forsythe, G.E., Malcolm, M.A., Moler, C.B.: Computer methods for Mathematical Computations. Prentice Hall, Englewood Cliffs, New Jersey, USA, 1977. [18] Gear, C.W.: Numerical Initial Value Problems in Ordinary Differential Equations. Prentice Hall, Englewood Cliffs, New Jersey, USA, 1971. [19] Gerlach, O.H.: Mathematical model of external disturbances acting on an aircraft during an ILS approach and landing. Report VTH-159, Delft University of Technology, Faculty of Aerospace Engineering, Delft, The Netherlands, 1970. [20] Gerlach, O.H.: Lecture Notes on Aircraft Stability and Control. Lecture Notes D-26, Delft University of Technology, Faculty of Aerospace Engineering, Delft, The Netherlands, 1981. [21] Hoogstraten, J.A., Moesdijk, B. van de: Modular programming structure applied to the simulation of non-linear aircraft models. In: IMACS Conference Proceedings on Simulation in Engineering Sciences, Nantes, France, 1983. [22] Johnson, W.A., McRuer, D.T.: Development of a Category II Approach System Model. 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 Design Challenge. Lecture Notes in Control and Information Services 224, Springer Verlag, 1997. [25] McLean, D.: Automatic Flight Control Systems. Prentice Hall, Hertfordshire, UK, 1990. [26] McRuer, D., Ashkenas, I., Graham, D.: Aircraft Dynamics and Automatic Control. 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 Engineering, Delft, The Netherlands, edition 1992. [28] Rauw, M.O.: A S IMULINK environment for Flight Dynamics and Control analysis Application to the DHC-2 Beaver (2 parts). MSc-thesis, Delft University of Technology, Faculty of Aerospace Engineering, Delft, The Netherlands, 1993. [29] Rossiter, S.: The Immortal Beaver: The Worlds 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 M ATLAB ODE Suite. USA, 1997. In: SIAM Journal on Scientic Computing, Volume 18, pp. 1-22, number 1. [33] Stevens, B.L., Lewis, F.L.: Aircraft Control and Simulation. John Wiley & Sons Inc., 1992.
BIBLIOGRAPHY
331
[34] Tjee, R.T.H., Mulder, J.A.: Stability and Control Derivatives of the De Havilland DHC-2 Beaver Aircraft. Report LR-556, Delft University of Technology, Faculty of Aerospace Engineering, Delft, The Netherlands, 1988. [35] Tomlinson, B.N., Padeld, G.D., Smith, P.R.: Computer-Aided control law research from concept to ight test. In: AGARD Conference Proceedings on Computer 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 automatisch besturingssysteem van de De Havilland DHC-2 Beaver. MSc-thesis (in Dutch, not publicly published), Delft University of Technology, Faculty of Aerospace 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 automatische piloot van de DHC-2 Beaver. MSc-thesis (in Dutch, not publicly published), Delft University of Technology, Faculty of Aerospace Engineering, Delft, The Netherlands, 1995.

A Simulink Toolbox For Flight Dynamics and Control Analysis

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

A Simulink Toolbox For Flight Dynamics and Control Analysis

Uploaded by

Copyright:

Available Formats

FDC 1.

4 A S IMULINK Toolbox for Flight Dynamics and Control Analysis

Marc Rauw May 25, 2005

39 40 40 43 43 46 46 48 49 51 55 55 56 63 66 66 68 69 70 71 73 73 74 75 77 83 84 87 87 88 89 90 91 91 92 93 93 96 99 99 100 100 101

7.5 7.6 7.7 7.8 7.9 7.10 7.11 7.12 7.13 8

105 106 106 108 109 113 113 114 115

216 216 217 217 219 221 221

G Common Documentation License Bibliography

Flight control system development

Automatic ight control systems

Chapter 1. Flight control system development

1.2. The FCS design cycle

The FCS design cycle

Chapter 1. Flight control system development

Taking a closer look at the FCS design cycle

1.3. Taking a closer look at the FCS design cycle

Control Surface Deflections ( t )

Figure 1.1: Denition of the aircrafts mission

Specify Control Problem

Design Control Laws

Achieve Specified Behaviour

Model Real World

Chapter 1. Flight control system development

1.4. FCS design environments

FCS design environments

Chapter 1. Flight control system development

Linear FCS design

SIMULINK model-library with nonlinear aircraft model

Nonlinear FCS validation & fine-tuning

Current scope of the FDC environment

Flightsimulator model-library with nonlinear aircraft model

Evaluation in real-time piloted flightsimulation

Update sensor/actuator models

Implementing FCS hardware and software

Update aero/engine models

Evaluation in real flight

Figure 1.3: FCS design cycle using M ATLAB and S IMULINK

FCS design and the FDC toolbox

1.5. FCS design and the FDC toolbox

Graphical SIMULINK system C-code generator Control Laws (block-diagram)

Graphical SIMULINK system

Control Laws (C-code)

Flight Simulator Control Laws (C-code)

Control Laws (C-code)

Flight Control Computer

Figure 1.4: Portable control laws

Chapter 1. Flight control system development

Rigid body equations of motion

General rigid-body equations of motion

General force equation for a rigid body

Chapter 2. Rigid body equations of motion

General moment equation for a rigid body

Angular momentum around the center of gravity

2.1. General rigid-body equations of motion

symbol Ixx Iyy Izz Jxy Jxz Jyz

Table 2.1: Moments and products of inertia

r (Vc.g. + r)m = r Vc.g. m + r ( r)m

and for the second term we can write:

Chapter 2. Rigid body equations of motion

Resulting general equations of motion for a rigid body

2.1. General rigid-body equations of motion

Chapter 2. Rigid body equations of motion