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). This document was created with M IKTEX in LATEX 2ε format. The vector figures 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 signifies your agreement to the terms of the License. Instead of a list: All trademarks mentioned in this document are registered to whoever it is that owns them. To contact the author, please send an e-mail to: [email protected]. For the most actual information about the FDC toolbox, see the Dutchroll homepage: http://www.dutchroll.org or http://www.dutchroll.com.

Contents Preface 1

2

3

Flight control system development 1.1 Automatic flight 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

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 flight-path axes . . . . . . . . . 2.2.1 Advantages of relating translations to flight-path axes . . . 2.2.2 Expressing forces and velocities in terms of flight-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 . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

11 11 11 12 12 14 18 18 19 20 20 21 21 23 25

The aircraft model 3.1 General structure of the flight 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 . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

27 27 27 28 28 31 32 32 33 34 38 38

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

ii

CONTENTS

3.7 4

5

6

7

3.6.2 Kinematic accelerations and specific forces . . . . . . . . . . . . 3.6.3 Flight-path related variables . . . . . . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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 flight 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 flight . . . . . . . . . . . . . . . . . . . . . . . . 6.3.1 Definition of steady-state flight . . . . . . . . . . . . . . . . . . 6.3.2 Specification of the flight 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-flight 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

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

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

CONTENTS

7.5 7.6 7.7 7.8 7.9 7.10 7.11 7.12 7.13

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

iii

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

105 106 106 108 109 113 113 114 115

8

Aircraft model block reference 117 8.1 The aircraft model and its subsystem equivalents . . . . . . . . . . . . . 117 8.2 The aircraft model block libraries . . . . . . . . . . . . . . . . . . . . . . 120

9

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-specific 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-flight elevator deflection 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 . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

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 .

. . . . . . . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . . . .

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

CONTENTS

v

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 definitions 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 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 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 deflections 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

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

299 299 299 300

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

C Data structure of the FDC model parameters 305 C.1 Defining the model parameters in the M ATLAB workspace . . . . . . . 305 C.2 Definition 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 Definitions 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

325

Bibliography

329

Chapter 1

Flight control system development During the last decades, active flight control technology has dramatically changed the way aircraft are designed and flown. Flight control systems with mechanical linkages have been replaced by full authority, ‘fly-by-wire’, digital control systems. As a consequence, the flying qualities of modern aircraft are largely determined by 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 flight 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 flight 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 flight control systems

A major factor in Wright brothers’ success in achieving the first powered flight in December 1903 has been the emphasis they placed on making their aircraft controllable by the pilot, rather than inherently stable. However, the difficulties of controlling early aircraft and the progress toward longer flight times, expanded flight-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 flight control systems has been parallelled by the development of closedloop control theories and major achievements in computer technologies [33]. Since the term ‘automatic flight control systems’ can be used to describe a wide variety of controllers, categorizing them into different categories can be beneficial. The first class of automatic controllers are the Stability Augmentation Systems (SAS).

2

Chapter 1. Flight control system development

These systems are used to damp and stabilize high-frequency rotational modes 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 ‘fly-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 flights. 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 flight management system (FMS), which offers flight 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 flight missions can be accomplished and unexpected events can be handled. A modern FCS consists of three main components [24]: (i) sensors, which provide the flight control computers information on air data, inertial data, and cockpit data, (ii) the flight control computers themselves, which are used to evaluate the flight 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 flexibility for the control laws, which provides new opportunities to increase the overall safety level. For example, error-tolerant control laws can provide flight envelope protection, and help the pilot to successfully achieve critical flight manoeuvres and to recover from unusual attitudes. The use of a modern FCS can also be beneficial 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 fly-by-wire systems is often lower than that of conventional control systems. Furthermore, fly-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 significantly reduce pilot training costs. Most importantly, modern flight control systems have contributed to improved dynamical behaviour. Certain military aircraft cannot be flown without a stability augmentation system; they use the open-loop instability, which is related to the

1.2. The FCS design cycle

3

agility of the aircraft, to obtain better performance and improved manoeuvrability of the closed-loop system. For civil aircraft, active flight 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 benefits described above are nullified by higher design and maintenance costs, while the increasing complexity of modern flight 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 definitions, 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. 1 If

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 fly a certain mission.

4

Chapter 1. Flight control system development

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 reflects the FCS design process within a manufacturing environment. In a research context, the design process may have to be modified 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 definition of the requirements, the manufacturing task is to make and deliver a reliable and effective product [35]. Consequently, the first 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 flexibility of the tools will sometimes be required. For instance, it should be possible to rapidly alter the control laws within the flight 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 flight, 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 flight 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 flight 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 eachother’s command signals.

1.3

Taking a closer look at the FCS design cycle

Let’s explore the individual design phases a little further. Figure 1.1 visualizes the first step in the FCS design process: the definition of the mission, which imposes requirements upon the shape of the flight-path and the velocity along this flight-path. This translates into the control problem depicted in figure 1.2: how to generate appropriate deflections of aerodynamic control surfaces or changes in engine power or thrust such that this mission can be fulfilled. 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

5

Mission

Flight-path ( t )

Control Surface Deflections δ ( t )

Figure 1.1: Definition of the aircraft’s mission

Specify Control Problem

Design Control Laws

Achieve Specified Behaviour

Model Real World Figure 1.2: The general flight control problem

the dynamical behaviour by means of trimming, stability and control analysis, and nonlinear open-loop simulations (for stable aircraft), and understanding the influences 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 define 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-

6

Chapter 1. Flight control system development

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 flight-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 deflection 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 configurations, 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 flight-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 pilot–aircraft interaction should be examined thoroughly, especially if the pilot will be actively involved in the aircraft control loop (e.g. for fly-by-wire systems). Based upon these results it is possible to select the best solution if there are more feasible methods to fulfill 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 flight control computer(s) of the aircraft. The actuators and sensors in the aircraft must be installed (if that hasn’t been done already), thoroughly tested, and calibrated. For some purposes, e.g. aircraft certification, 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 flight control computers of the aircraft needs to be carefully verified, to ensure that the control laws used in flight match those analyzed on the ground.1 In order to reduce the risks of such conversion errors, it would be beneficial to be able to couple at least the complete FCC software, but preferably also its hardware, to the real-time flight-simulator and/or off-line design environment. After successfully concluding the simulations and ground tests of the hardware and FCC software, the FCS can be evaluated in real flight. In an ideal world this phase would only be a straightforward verification of the previous results, but in practice it will often be necessary to return to a previous stage in the FCS development for fixing errors or fine-tuning the control laws. It also may be necessary to update the mathematical models if deficiencies in these models are found during the in-flight 1 During

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

1.4. FCS design environments

7

evaluations. Quantitative results from the flight tests need to evaluated on-ground to confirm 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-flight 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 figure the models and tools (software and hardware environments) are shown, while the right-hand side shows the design stages themselves.

1.4

FCS design environments

It is obviously very important to make the transitions between the different 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 (Murphy’s 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 flight 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 flight controllers may excite structural modes of the aircraft and interact with the control-actuator dynamics, and because of the increasing need to integrate flight 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 flight 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 flight. It applies S IMULINK functions to extract linear state-space de-

8

Chapter 1. Flight control system development

Linear FCS design

Linearized models

M

M Trimming & Linearization

S

SIMULINK model-library with nonlinear aircraft model

Nonlinear FCS validation & fine-tuning

Current scope of the FDC environment

S

Future: automatic transfer of models?

F

Flightsimulator model-library with nonlinear aircraft model

F

Update sensor/actuator models

A

Evaluation in real-time piloted flightsimulation

Future enhancements

Implementing FCS hardware and software

Evaluation in real flight

Update aero/engine models

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 flight 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 figure 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 flight simulator and eval-

1.5. FCS design and the FDC toolbox

Graphical SIMULINK system

9

Graphical SIMULINK system C-code generator

Control Laws (block-diagram)

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 flight. 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 flightsimulator and/or the flight 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 figure suggests that automatic transfer of complete simulation models from the S IMULINK environment to a flightsimulator 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 flightsimulator environment could help streamline these conversions. This concept of ‘portable’ flight control laws has been illustrated in figure 1.4, assuming that the language C is used to implement the flight control laws in the flightsimulator 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

Chapter 1. Flight control system development

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 specific experimental hardware setups. By integrating M ATLAB, S IMULINK, and other tools that allow easy interfacing with external simulation devices or FCC’s, quick prototyping of flight control laws becomes feasible, and the transitions between off-line simulations, real-time simulations, and actual flight 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 FDC’s 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 Newton’s laws, which state the connection between force and motion. We start by deriving the general force and moments equations for a rigid body and defining the relations for the angular momentum. This results in six ordinary differential equations, representing the linear and angular accelerations in the body-fixed reference frame.

2.1.1

General force equation for a rigid body

Consider a mass point δm that moves with time-varying velocity V under the influence 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 fixed position of the stars (a.k.a. ‘inertial space’), but it may not accelerate or rotate. Applying Newton’s second law yields: ˙ δF = δm · V (2.1) Applying this equation to all mass points of a rigid body and summing all contributions across this body yields: dV

d Vδm (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

=

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˙

(2.3)

therefore: d

∑ Vδm = ∑(Vc.g. + r˙ )δm = mVc.g. + dt ∑ rδm

(2.4)

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

∑ r δm = 0

(2.5)

so the equation for the total force F acting upon the rigid body, becomes: ˙ c.g. F = mV

2.1.2

(2.6)

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 =

d (r × V)δm = (r˙ × V)δm + (r × V˙ )δm dt

(2.7)

where: r˙ = V − Vc.g.

(2.8)

and:

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

(2.9)

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

(2.10)

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

∑ δMc.g. = ∑ δh˙ + Vc.g. × ∑ Vδm

(2.11)

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

(2.12)

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

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

symbol

definition

Ixx Iyy Izz Jxy Jxz Jyz

∑(y2 + z2 ) δm ∑( x2 + z2 ) δm ∑( x2 + y2 ) δm ∑ xy δm ∑ xz δm ∑ yz δm

13

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

(2.14)

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

∑ δh

=

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

The first term of the right hand side of equation (2.15) is equal to zero:
∑ rδm × Vc.g. = 0 and for the second term we can write:  ∑ r × (Ω × r)δm = ∑ Ω(r · r) − r(Ω · r) δm =

∑



(2.16)

Ωk r k2 − r (Ω · r) δm (2.17)

Substitution of r = i x + j y + k z, (2.16), and (2.17) in equation (2.15) yields: h = Ω ∑( x2 + y2 + z2 )δm − ∑ r ( px + qy + rz)δm

(2.18)

The components of h along the X, Y, and Z axes will be denoted as 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 defined as the inertial moments and products about the X, Y, and Z axes respectively; see table 2.1.1 Using these definitions, 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 defined 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 refinement has been omitted here.

14

Chapter 2. Rigid body equations of motion

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 significant in practice. For example, a number of World War I aircraft had a single ‘rotary’ engine that had a fixed 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 flight 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 h0 , with components h0x , h0y , and h0z in FB , which are assumed to be constant, the total angular momentum of an airplane with spinning rotors can be obtained by simply adding h0 to the angular momentum of the airframe: h = I · Ω + h0

(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 fixed 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 find:   ∂Vc.g. F=m + Ω × Vc.g. (2.24) ∂t and:

∂h ∂ Mc.g. = +Ω×h = I · Ω + h0 + Ω × I · Ω + h0 = ∂t ∂t ∂ = (2.25) (I · Ω) + Ω × (I · Ω) + Ω × h0 ∂t The last term in this equation, Ω × h0 , 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.

2.1. General rigid-body equations of motion

symbol

definition

|I| I1 I2 I3 I4 I5 I6

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

Pl Pm Pn Ppp Ppq Ppr Pqq Pqr Prr

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 |

Ql Qm Qn Q pp Q pq Q pr Qqq Qqr Qrr

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 |

Rl Rm Rn R pp R pq R pr Rqq Rqr Rrr

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: Definition of inertia coefficients

15

16

Chapter 2. Rigid body equations of motion

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, flight simulation, system identification, 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
∂Ω = I−1 Mc.g. − Ω × I · Ω − Ω × h0 (2.27) ∂t These equations can be written-out into their components along the body-axes, using the following definitions 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˙ =

(2.28)

p˙ = Ppp p2 + Ppq pq + Ppr pr + Pqq q2 + Pqr qr + Prr r2 + Pl L + Pm M + Pn N + p˙ 0 q˙ = Q pp p2 + Q pq pq + Q pr pr + Qqq q2 + Qqr qr + Qrr r2 + Ql L + Qm M + Qn N + q˙ 0 r˙ = R pp p2 + R pq pq + R pr pr + Rqq q2 + Rqr qr + Rrr r2 + Rl L + Rm M + Rn N + r˙ 0 (2.29)

The last terms in equations (2.29) express the effects of the gyroscopic couples: p˙ 0 = qh0z − rh0y q˙ 0 = rh0x − ph0z 0

r˙ =

ph0y

(2.30)

− qh0x

Ppp , Ppq , . . . , Rn are inertia coefficients, 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.1. General rigid-body equations of motion

17

3. the Earth is assumed to be fixed in space, i.e. its rotation is neglected, and 4. the curvature of the Earth is neglected. The latter two assumptions allow us to assume that the inertial reference frame in which the motions of the rigid body are considered is fixed 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-fixed reference frame. The orientation of the body-axes in this figure conforms to the definition from section A.7.1 of appendix A. The figure also shows the graphical representation of the airspeed vector V, the angle of attack α, and the sideslip angle β, which define the orientation of the flight-path axes in relation to the aircraft’s body-axes.

XB-axis Fx , u

L, r

α

c.g.

β

V Fy , v Fz , w M, q YB -axis

N, p Z B-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-fixed reference frame of the aircraft.

18

Chapter 2. Rigid body equations of motion

2.2

Expressing translational motions in flight-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 flight-path axes (the airspeed vector V coincides with the flight-path or wind-axis XW , while α and β define the orientation of the flight-path reference frame FW in relation to the body-fixed reference frame FB ; see section A.7.1 of appendix A).

2.2.1

Advantages of relating translations to flight-path axes

Since V, α, and β can be expressed in terms of u, v, and w, and vice-versa, it is 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 difficult 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 flight-path axes. For agile aircraft having an upper limit of the pitch rate q of about 2 rad s−1 , and flying at high airspeeds (e.g. V = 600 m s−1 ), the term u q in equation (2.28) may become as large as 120 g! On the other hand, the factor Fz /m, which represents the normal acceleration due to the external force along the ZB -axis (primarily gravity and aerodynamic lift) has an upper-limit of only a few g’s. Hence, ‘artificial’ 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 first 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 flight-path axes

19

-Z a L

D

α V -Xa

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

2.2.2

Expressing forces and velocities in terms of flight-path axes

Transforming the forces and velocities from body to flight-path axes is quite straightforward (see ref.[14] for a detailed description). From figure 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: p

u2 + v2 + w2 w α = arctan u  v β = arctan √ u2 + w2

V =

(2.32) (2.33) (2.34)

20

Chapter 2. Rigid body equations of motion

Aerodynamic forces and moments are commonly expressed in terms of aerodynamic lift L, drag D, and sideforce Y, which are aligned along the flight-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 figure 2.2. The body-axes components can be derived from the flight-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 definitions (2.31) for u, v, and w, and cancelling terms yields: V˙ = u˙ cos α cos β + v˙ sin β + w˙ sin α cos β (2.37) ˙ v, ˙ and w, ˙ the terms involving the vehicle rotaIf we substitute equations (2.28) for u, tional 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 β ˙ and rewriting terms yields: Substituting equations (2.28) for u˙ and w,   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 find:   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

2.2.5

21

Derivation of the β˙ -equation

Differentiating equation (2.34) with respect to the time yields: v˙ (u2 + v2 ) − v(uu˙ + ww˙ ) √ β˙ = V 2 u2 + w2

(2.44)

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 α

(2.45)

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 1 (− Fx cos α sin β + Fy cos β − Fz sin α sin β) + qw cos α sin β + V m  − 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 find:   ˙β = 1 1 (− Fx cos α sin β + Fy cos β − Fz sin α sin β) + p sin α − r cos α V m

2.3

(2.46)

(2.47)

(2.48)

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 fixed 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 aircraft’s 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 fix 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-fixed 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

Chapter 2. Rigid body equations of motion

or: ue = u a + uw ve = v a + vw

(2.50)

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:   ∂Ve F=m (2.51) + Ω × Ve ∂t Rewriting equation (2.51) yields: ∂Ve F = − Ω × Ve ∂t m For the individual components along the body-axes we thus find:

(2.52)

Fx − qwe + rve m Fy v˙ e = + pwe − rue (2.53) m Fz w˙ e = − 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 ˙ α, ˙ and β˙ in section 2.2, we can find expressions for the time-derivatives of Va , of V, α a , and β a :
1 Fx cos α cos β + Fy sin β + Fz sin α cos β + V˙ a = m − (qww − rvw + u˙ w ) cos α cos β + ( pww − ruw − v˙ w ) sin β + u˙ e =

− ( pvw − quw + w˙ w ) sin α cos β  1 1 α˙ a = (− Fx sin α + Fz cos α) + V cos β m

(2.54)



− ( pvw − quw + w˙ w ) cos α + (qww − rvw − u˙ w ) sin α + + q − ( p cos α + r sin α) tan β  ˙β a = 1 1 (− Fx cos α sin β + Fy cos β − Fz sin α sin β) + V m + (qww − rvw + u˙ w ) cos α sin β + ( pww − ruw − v˙ w ) cos β +  + ( pvw − quw + w˙ w ) 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 aircraft’s 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 finally, we want to be able to track the flight path relative to the Earth, e.g. for simulations of navigational tasks. The orientation of the airplane relative to the Earth is given by a series of three consecutive rotations, the Euler angles ψ, θ, and ϕ, see figure 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Φ

z }|      p ϕ˙ 1 0  q  =  0  +  0 cos ϕ r 0 0 − sin ϕ   1 0 0 +  0 cos ϕ sin ϕ  0 − sin ϕ cos ϕ | {z } TΦ

{ 0 sin ϕ  cos ϕ  cos θ  0 sin θ |

  0  θ˙  + 0   0 − sin θ 0   1 0 0 0 cos θ ψ˙ {z }

(2.57)

TΘ

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-fixed 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

Chapter 2. Rigid body equations of motion

the following kinematic relations: q sin ϕ + r cos ϕ cos θ θ˙ = q cos ϕ − r sin ϕ

ψ˙ =

(2.59)

ϕ˙ = p + (q sin ϕ + r cos ϕ) tan θ = p + ψ˙ sin θ The position of the aircraft with respect to the Earth-fixed reference frame is given by the coordinates xe , ye , and ze . To find these coordinates, we need to resolve the body-axis velocity vector in the Earth-bound reference system FE :     ue x˙ e  y˙ e  = TB→E ·  ve  (2.60) we z˙ e where TB→E = TB→V = TV → B −1 is the transformation matrix from FB to FE , see the definition in section A.7.3 of appendix A. This results in the following equations: x˙ e = {ue cos θ + (ve sin ϕ + we cos ϕ) sin θ } cos ψ − (ve cos ϕ − we sin ϕ) sin ψ y˙ e = {ue cos θ + (ve sin ϕ + we cos ϕ) sin θ } sin ψ + (ve cos ϕ − we sin ϕ) cos ψ z˙ e = −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˙ = −z˙ e

(2.62)

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 airplane’s attitude using the minimum number of three first-order differential equations. However, it should be noted that these equations also have some significant disadvantages. First of all, a division by zero occurs if the pitch angle reaches plus or minus 90◦ . Although in digital simulations, this exact number has an almost zero probability of occurrence, this may still cause significant 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 difficult to determine the attitude uniquely. And finally, 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, five, 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.5. Assembling the state equations

2.5

25

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˙ 0 q˙ = Q pp p2 + Q pq pq + Q pr pr + Qqq q2 + Qqr qr + Qrr r2 + Ql L + Qm M + Qn N + q˙ 0 r˙ = R pp p2 + R pq pq + R pr pr + Rqq q2 + Rqr qr + Rrr r2 + Rl L + Rm M + Rn N + r˙ 0 (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 aircraft’s 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 θ x˙ e = {ue cos θ + (ve sin ϕ + we cos ϕ) sin θ } cos ψ − (ve cos ϕ − we sin ϕ) sin ψ y˙ e = {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

(2.65)

and the resulting equations are combined in a single vector equation: x˙ = f0 (x, Ftot (t), Mtot (t))

(2.66)

26

Chapter 2. Rigid body equations of motion

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)

(2.67)

Substituting in equation (2.66) yields the nonlinear state-space system: x˙ (t) = f (x(t), u(t), v(t), t)

(2.68)

In some cases, the forces and/or moments not only depend on the state vector x but ˙ which causes equation (2.68) to become implicit, as x˙ also on its time-derivative x, now appears on both sides of the equation: x˙ (t) = f(x(t), x˙ (t), u(t), v(t), t)

(2.69)

Luckily, this implicit relation can often be written as: x˙ (t) = f1 (x(t), u(t), v(t), t) + f2 (x˙ (t), t)

(2.70)

which makes it somewhat easier to find a numerical solution for this system, 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.

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 first 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 flight simulation, flight dynamics analysis, and flight control system design.

3.1

General structure of the flight simulation model

Figure 3.1 shows the general closed-loop model of an automatically controlled aircraft that is affected by external disturbances. Most elements in this model are hardware related: the airframe and powerplant determine the aircraft dynamics, the flight 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 flight control system are typically defined in software. This chapter will focus on building the aircraft dynamics model, which obviously forms the core of figure 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 flight 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 figure 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

Discretization effects, computational delay

Aircraft dynamics

Sensor dynamics

AFCS control laws

Mode controller

Reference signals

h

Pilot-

h interface

Figure 3.1: Block-diagram of an automatically controlled aircraft

vector, x0 . In order to obtain the time-derivatives of the state variables the state 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 figure, this is illustrated for the aerodynamic forces and moments, which are transferred from flight-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 influence of nonsteady atmosphere. This comprises an in-flight 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 fly 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 flight condition, defined by the state vector x and the aircraft configuration (i.e. the position of movable elements

u j wind

j

u prop

j

uaero

6

Atmosphere/ Airdata

M, ...

qdyn ,

-

-

-

-

-

Wind Corrections

Gravity

Propulsion

- Aerodynamics -

B Fwind

F Egrav

M Bprop

F Bprop

MW aero

FW aero

- T E→B

- T W →B

F Bgrav

M Baero

F Baero

-

∑

B Mtot

B Ftot

-

x˙ = f(x, Ftot , Mtot )

Equations of Motion

x˙ -

Z

dt

x -

3.3. External forces and moments 29

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

30

Chapter 3. The aircraft model

on the airplane). For the DHC-2 Beaver aircraft, a sophisticated aerodynamic model has been determined from flight tests in 1988 [34]. This model expresses the aerodynamic forces and moments along the aircraft’s body-axes in terms of polynomial functions of the aircraft states, the time-derivative of the state vector, and the flight control inputs: ˙ uaero ) Faero = d · p1 (x, x,

(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 coefficients. The input vector uaero gathers the positions of the elevator, ailerons, and rudder (the primary flight controls for the Beaver), and flaps (the secondary flight controls). For the ˙ Beaver model, the x-term is linear and only takes into account the direct contribu˙ tion of β to the aerodynamic side-force Ya . The pre-multiplication with the diagonalmatrix d converts these non-dimensional coefficients 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 = 12 ρV 2 , see section 3.5). The polynomial functions from p1 , describing the aerodynamic force and moment coefficients in the body-fixed reference frame are: qc CXa = CX0 + CXα α + CXα2 α2 + CXα3 α3 + CXq + CXδr δr + CXδ δ f + CXαδ αδ f f f V ˙ pb rb βb CYa = CY0 + CYβ β + CYp + CYr + CYδa δa + CYδr δr + CYδr α δr α + CYβ˙ 2V 2V 2V qc CZa = CZ0 + CZα α + CZα3 α3 + CZq + CZδe δe + CZδ β2 δe β2 + CZδ δ f + CZαδ αδ f f f e V rb pb + Clr + Clδa δa + Clδr δr + Clδa α δa α Cla = Cl0 + Clβ β + Cl p 2V 2V rb qc + Cmδ f δ f Cma = Cm0 + Cmα α + Cmα2 α2 + Cmq + Cmδe δe + Cmβ2 β2 + Cmr V 2V rb qc pb Cna = Cn0 + Cnβ β + Cn p + Cnr + Cnδa δa + Cnδr δr + Cnq + Cnβ3 β3 2V 2V V (3.3) The stability and control coefficients from these polynomial equations are constant for the entire flight-envelope of the Beaver; table B.3 in appendix B lists their values. Notice the cross-coupling between lateral motions and longitudinal forces and 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]: ! ∆pt P dpt ≡ 1 = C1 + C2 1 3 (3.4) 2 2 ρV 2 ρV The constants C1 and C2 have been given in ref [34]: C1 = 0.08696, and C2 = 191.18. P is measured in [kW kg−1 s3 ]. For the Beaver aircraft, the engine power in [kW ] 1 ρV 3 2

can be calculated with the following expression1 :  P = 0.7355 − 326.5 + (0.00412 ( pz + 7.4)(n + 2010) +    ρ + (n + 2010) + (408.0 − 0.0965 n) 1.0 − ρ0 where: pz n ρ ρ0

= = = =

(3.5)

manifold pressure [00 Hg], engine speed [RPM], air-density [kg m−3 ], air-density at sea level = 1.225 [kg m−3 ].

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 coefficients; 1 The

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 flight simulator of the Faculty during the 1980’s and early 1990’s. 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.

32

Chapter 3. The aircraft model

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 coefficients in the body-fixed reference frame are: CX p = CXdpt dpt + CXα dpt2 α dpt2 CYp = 0 CZp = CZdpt dpt Cl p = Clα2 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 coefficients from these polynomial equations. These coefficients are constant over the entire flight envelope of the Beaver.

3.3.3

Gravitational forces

The weight of the aircraft equals the aircraft’s mass m times the local acceleration of gravity g. It is directed along the positive ZV axis (see the definition 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 defined according to equation (A.4) from appendix A, we find the following equation for the gravity force components along the aircraft’s 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 definitions.

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 aircraft’s body-axes are needed whenever the aircraft is flying in nonsteady at-

3.4. Converting the implicit state equations to explicit equations

mosphere. These corrections are equal to:     u˙ w + qww − rvw Xw Fwind =  Yw  = −m ·  v˙ w − pww + ruw  w˙ w + pvw − quw Zw

3.4

33

(3.11)

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 + CYδa δa + CYδr δr + CYδr α δ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):
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 = 12 ρV 2 S CYa . As a consequence, the time-derivative β˙ appears on both sides of equation (3.13). CYa = CY0 + CYβ β + CYp

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 ˙ explicit. First of all, the contribution of β to the side-force Fy can be written as a separate term:  ˙ 1  βb β˙ = − Fx cos α sin β + Fy ∗ cos β − Fz sin α sin β + 12 ρV 2 S CYβ˙ 2V cos β + Vm

+ p sin α − r cos α

(3.14)

˙ The β-term ˙ where Fy ∗ is the side-force without the contribution of β. on the right hand side of this equation can easily be moved to the left-hand side:   ˙β∗ ≡ β˙ 1 − ρSb 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, to obtain the value β˙ ∗ , and   −1 ρSb 3. compute the true value of β˙ with the expression β˙ = β˙ ∗ 1 − 4m CYβ˙ cos β .

Since the last step ‘corrects’ the originally computed value β˙ ∗ to obtain the actual ˙ the multiplication factor from step 3 represents a correction term. The value of β, 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 coefficients, 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 flight 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

(3.16)

where: h T0 λ

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

The air pressure depends upon the altitude, according the basic hydrostatic equation: dps = −ρ g dh

(3.17)

We assume that the ideal gas law can be applied to the air in the atmosphere: ps Ra T = (3.18) ρ Ma

3.5. Atmosphere and airdata variables

35

where: R a = molar gas constant = 8314.32 [JK −1 kmol−1 ], Ma = molecular weight of the air [kg kmol−1 ]. 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

(3.19)

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

To find ps , equation (3.19) needs to be integrated, yielding:     ps g T0 + λh ln =− ln p0 λR T0 This equation can be written as:   g   λRg λh − λR ps T0 = 1+ = p0 T0 T

(3.20)

(3.21)

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

R a (3.18) p0 = = 287.05 [JK −1 kg−1 ] M0 ρ0 T0

(3.22)

and: p0 = air pressure at sea level = 101325 [Nm−2 ], ρ0 = air density at sea level = 1.225 [kg m−3 ], M0 = molecular weight of the air at sea level = 28.9644 [kg kmol−1 ]. Since the gravitational acceleration g was held constant during the integration 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 aircraft’s weight. The actual gravitational acceleration is then computed with the following equation, which is valid for a round Earth:  2 REarth g = g0 (3.23) REarth + h where: REarth = radius of the Earth = 6371020 [m] 1

The geopotential altitude H is defined as: H ≡

Z h g 0

g0

dh

36

Chapter 3. The aircraft model

The air density ρ (in [kgm−3 ]) 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 ≡ 12 ρV 2

(3.25)

This term originates from Bernoulli’s 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, Bernoulli’s law is usually applied only for airspeeds up to 100 ms−1 . For aircraft flying 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 flow of an ideal gas is used [5]: γ p 1 2 + V = constant (3.27) γ−1 ρ 2 C

where γ = Cvp is the ratio of the specific 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 flow are related as follows: ps = constant (3.28) ργ If we now define the ‘total conditions’ to be the pressure and density where the flow is brought to rest isentropically1 , we find:  γ   γ−γ 1 pt ρt Tt (3.29) = = ps ρ T Applying equation (3.27), the total pressure for a compressible airflow is thus found to be:   γ γ − 1 ρ 2 γ −1 pt = ps 1 + V (3.30) 2γ ps It is possible to re-write this relation using the Mach number M, which is defined as the ratio of the speed of the airflow 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 [ms−1 ]): p a = γRT

37

(3.32)

The Mach number is an important property that appears in many of the isentropic flow 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:   γ γ − 1 2 γ −1 pt = ps 1 + M (3.33) 2 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 flies 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 flow 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 flight-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 flight. The impact pressure is defined 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 Bernoulli’s equation (3.26), except in this case the compressibility of the flow is taken into account. It can be measured using a pitot static system that subtracts the static pressure 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):   γ−1 2 Tt = T 1 + M (3.35) 2 Other important variables are the calibrated and equivalent airspeeds Vc and Ve , which are determined by the equations: v ( ) u  γ −1 u 2γ p0  qc γ t Vc = 1+ −1 (3.36) γ − 1 ρ0 p0 s r 2qdyn ρ Ve = V = (3.37) ρ0 ρ0 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

Chapter 3. The aircraft model

‘equivalent airspeed’ does the same assuming that the airflow is incompressible. Expression (3.37) is used to calibrate less sophisticated flight 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 [m−1 ]), which equals: ρV Re = (3.39) µ In equations (3.38) and (3.39), µ is the coefficient of the dynamic viscosity, which can be calculated with the equation of Sutherland: 3

1.458 · 10−6 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 flight-envelope beyond the troposphere (i.e. to altitudes above 11,000 meters) and beyond the speed of sound will require additional modifications to the equations for pressure, density, and temperature. For more information, refer to ref. [5] or other books about aircraft instrumentation.

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, specific forces, body-axes velocity rates and some flight-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 ˙ v, ˙ the aircraft’s acceleration along its body-axes. These body-axes ‘velocity rates’ u,

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 specific forces

It is possible to calculate accelerations and outputs from accelerometers, which may be useful for post-flight analysis or required for certain flight 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 field of manoeuvre load limiting. The aircraft model from the FDC-toolbox considers accelerations in the vehicle’s 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 ˙ v, ˙ and w˙ – see equainto its components along the body-axes and substituting for u, tion (3.41) – yields: 1 Fx (u˙ + qw − rv) = g0 W Fy 1 = (v˙ + ru − pw) = g0 W 1 Fz = (w˙ + pv − qu) = g0 W

a x,k = ay,k az,k

(3.43)

˙ v, ˙ and w˙ is the inclusion of The difference between the kinematic accelerations and u, 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-fixed reference frame. The outputs of accelerometers which are oriented along the body-axes, and located in the vehicle’s center of gravity are equal to the kinematic body accelerations

40

Chapter 3. The aircraft model

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 aircraft’s center of gravity; they are usually called specific forces.

3.6.3

Flight-path related variables

To determine the flight-path of the aircraft, it is useful to introduce some additional observation variables. First of all, the flight-path angle γ is computed, using the following expression:   H˙ γ = arcsin (3.45) V 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 flight-path acceleration fpa. It is equal to: √ u˙ 2 + v˙ 2 + w˙ 2 V˙ fpa = = (3.46) g0 g0 Other flight-path related variables are the azimuth angle χ and the bank angle Φ, which are obtained with the following equations [30]: χ = β+ψ

(3.47) ◦

Φ = arcsin sin ϕ sin(90 − θ ) = arcsin sin ϕ cos θ





(3.48)

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

3.7

Summary

To recapitulate: we have completed the state-space model of the rigid body 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 figure 3.2. This model was enhanced with several useful output equations, including additional airdata parameters, acceleration quantities, and flight-path variables. The resulting system of equations completes the block ‘Aircraft dynamics’ from figure 3.1; the other elements from that figure 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 coefficients, and time-derivatives of the states). These variables have been listed in table D.2,

3.7. Summary

41

which can be found appendix E. The input variables to this model are the control surface deflections, 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 flight-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 fine-tuning of flight 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 flight-path. This variation of the mean wind along the flight-path is called windshear.1 The influence of windshear upon the motions of the aircraft is of particular importance during the final approach and landing, and during take-off and initial climb. An idealized profile of the mean wind as a function of height above the ground has been shown in figure 4.1. Much more extreme wind profiles 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 flying 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

H [m ]

350 300 250 200 150 100 50 0

0

0.5

1

1.5

2

2.5

3

Vw [ m/s ]

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

may exceed the aerodynamic and propulsive performance of airplanes, causing 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 final approach to John F. Kennedy airport in New York. Figure 4.2 shows the reconstructed wind profile and the recorded flightpath of this airplane. Based on this data, numerical models of two-dimensional flowpatterns for thunderstorms have been developed [11]; such models are often used for flight crew training in flightsimulators. 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 sufficient; 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 Km−1 ; see for instance ref.[30] for more details. The following equations represent a typical idealized windspeed profile 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)

(4.1)

(h ≥ 300m)

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 profile in

4.1. Deterministic disturbances

45

250 25 sec 30

200

40

Downburst

nt

150

55

ide

100

ind

Gl

fro

50

slo

Se aw

Height [m]

35

pe 20:05 UTC 00 sec

Outburst 50

05

10

0 -3000

-2000

11.4 sec: first ground contact

-1000

Runway

Distance from threshold [m]

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

figure 4.1 is based upon a value Vw 9.15 = 1 ms−1 . Ref.[1] presents some alternative wind profiles, which are typical for other values of the temperature lapse rate. In sections 2.3 and 3.3.4, we described how the influence of the wind on the motions of the airplane can be expressed in terms of correction terms for the external force components in the body-fixed reference frame. If we know the wind velocity relative to the Earth, we can obtain the components of the wind along the aircraft’s body-axes using the following axes transformation: B Vw = TE→ B · VwE

(4.2)

where Vw represents the wind vector, the superscript B represents the aircraft’s 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 figure A.2 in appendix A: TE→ B ≡ TV → B = TΦ · TΘ · TΨ

(4.3)

This transformation has been written out in more detail in equation (A.4) of 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 first 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

Chapter 4. External atmospheric disturbances

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

(4.5)

In this generalized situation, the vertical wind velocity component can be non-zero: E ww = −Vw · sin γw

(4.6)

where the minus sign reflects the fact that the ZE points downwards. Equations (4.3) to (4.6) can be used to model a steady wind pattern, while equation (4.1) can be used to describe the changing wind velocity in the Earth’s 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 figure 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 flows 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 flow field 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 flight 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 sufficient 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. Taylor’s 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 sufficient length. 6. Isotropy, which means that the statistical properties are not changed by a rotation or a deflection 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 satisfied [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]. Taylor’s hypothesis seems to be valid as long as the aircraft’s 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 final approach and landing of S/VTOL aircraft, i.e. aircraft which can fly 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 Earth’s 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 satisfied 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 simplifications will all be maintained for the derivations in the next sections. It is always possible to enhance these models in the future, if

48

Chapter 4. External atmospheric disturbances

S(Ω) S(0)

A

S(Ω) S(0)

1

B

1

.1

.1

Dryden

Dryden .01

.01

Von Kármán

.1

1

10

Von Kármán

.1

ΩLg

1

10

ΩLg

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

a more accurate description of the atmospheric turbulence is required, e.g. for detailed analysis of the final 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 simplifications 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 first 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 Kármán spectral density functions seem to best fit 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 aircraft’s body-axes yields: Sug ug (Ω) = 2σu 2 Lu Svg vg (Ω) = σv 2 Lv

1 5

(1 + (1.339 Lu Ω)2 ) 6 1 + 83 (1.339Lv Ω)2 11

(1 + (1.339 Lv Ω)2 ) 6 1 + 83 (1.339Lw Ω)2

(4.8) (4.9)

Swg wg (Ω) = σw 2 Lw

(4.10) 11 (1 + (1.339 Lw Ω)2 ) 6 where Sug ug represents the longitudinal Von Kármán spectrum, while Svg vg and Swg wg are both instances of the lateral Von Kármán 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.

4.2. Stochastic disturbances

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 Kármán spectra yield an asymptotic behaviour of S(Ω) ∼ Ω−5/3 as Ω approaches infinity. 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 Kármán spectral densities is that they are not rational functions of Ω, which greatly complicates analysis and computations for any application. To overcome this problem, the simplified Dryden spectral density functions were introduced: 1 Sug ug (Ω) = 2σu 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 figure 4.3 typical Dryden spectral density values have been compared with the Von Kármán functions. The most obvious difference is the asymptotic behaviour at large values of the spatial frequency, the former having a slope of − 53 and the latter a slope of −2. Although the Von Kármán form seems to fit 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 filter’, as shown in figure 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 filter can be written as: Syy (ω ) = | Hyu (ω )|2 Suu (ω )

(4.14)

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

(4.15)

so for white noise, relation (4.14) simplifies to: Syy (ω ) = | Hyu (ω )|2 Unfiltered white noise

(4.16)

Linear Filter (Dryden)

Turbulence velocity (‘coloured noise')

Figure 4.4: Modelling atmospheric turbulence as filtered white noise

50

Chapter 4. External atmospheric disturbances

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 Taylor’s hypothesis implies that the circular frequency ω [rad s−1 ] encountered at the aircraft’s center of gravity is related directly to the spatial frequency Ω [rad m−1 ]: ω = ΩV

(4.17)

The resulting transformation is given by: 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 Kármán 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 definitions of the Dryden spectra in equations (4.11) to (4.13) and relation (4.18) the following expressions are found: Lu 1
V 1 + Lu ω 2 V
ω 2 2 2 Lv 1 + 3 Lv V | Hvg w2 (ω )| = σv 
2 V ω 2 1 + Lv V
ω 2 2 2 Lw 1 + 3 Lw V | Hwg w3 (ω )| = σw 
2 V ω 2 1 + Lw V

| Hug w1 (ω )|2 = 2σu 2

(4.19) (4.20)

(4.21)

Solving equations (4.19) to (4.21) yields the following candidate functions for the frequency responses of the forming filters: r 2Lu 1 (4.22) Hug w1 (ω ) = σu V 1 ± LVu jω √ r Lv 1 ± 3 LVv jω Hvg w2 (ω ) = σv (4.23)  2 V 1 ± LVv jω √ r Lw 1 ± 3 LVw jω Hwg w3 (ω ) = σw (4.24)  2 V 1 ± LVw jω In these equations w1 , w2 , and w3 are independent white noise signals. Choosing the minus sign in the denominators would lead to unstable filters 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.

4.2. Stochastic disturbances

51

500

II

III 0.662

0.318

450

0.666

0.363

400

0.681

0.456

350

I

H [m]

0.690

0.538

0

300

0.565

0.151

250

0.235

0.560

200

0.670

0.508

0.245

150

0.688

0.620 0.382

0.210

100

0.506 0.145

0.229

50

0.307 0.068

0

0.123 0

0.0825

0.1

0.2

0.3

0.4

σwg Vw

0.5

0.6

0.7

0.8

[-]

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 m−1 , curve II: dT dT ◦ −1 ◦ −1 dH = 0.0065 C m , curve III: dH ≥ 0.01 C m .

This representation of the Dryden filters 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 Kármán turbulence spectra can be obtained by using a series of additional lead-lag networks, adding differentiating and integrating terms to the basic first-order Dryden filters. 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

Chapter 4. External atmospheric disturbances

500

III

II

160

300

450 158

301

400

I

48

156

305

350 152

44

310

H [m ]

300 149

42

250

145

38

200

69

26

50 9

18

329

108

33

100

326

139

35

150

315

284

161

36

0 0

50

100

150

200

250

300

350

Lw [ m ]

Figure 4.6: Scale of (longitudinal) turbulence as a function of altitude, given for three dT ≤ 0.005 ◦ C m−1 , curve II: different temperature lapse rates. Curve I: dH dT dT ◦ − 1 0.005 < dH < 0.01 C m , curve III: dH ≥ 0.01 ◦ C m−1 .

sity was represented by the standard deviations σu , σv , and σw . If the turbulence field 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 influence 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 profiles for the boundary layer of the atmosphere experimentally determined at different atmospheric stabilities (see e.g. figure 4.1 for the standard temperature lapse rate λ = −0.0065 K m−1 ), the standard deviation of atmospheric turbulence turns out to be dependent on 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

4.2. Stochastic disturbances

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 figure 4.6. It can be concluded that the structure of the turbulence at low altitudes can be described completely by examining the figures 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 final approach and landing. For higher altitudes, typical values are σg = 1 m s−1 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 flight data without any restrictions, which is very useful for the analysis of flight 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 flight, the relevant flight 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 deflections, 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 flight-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 1940’s, 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

Localizer antenna

Runway

Figure 5.1: Positioning of ILS ground equipment Aircraft track Join glide-path and commence final descent Alt. 1200 ft

Alt. 2500 ft

Outer marker

Alt. 300 ft Glide-path transmitter

Middle marker 3000

ft

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 flying on final 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

Back beam area

35 o

Front beam area

10 o

17 N M

Runway Localizer transmitter

35

o

10

NM

10

o

25 NM

Figure 5.3: Required coverage of localizer signal

Idealized glide-path (straight line)

Localizer plane

Actual glide-path (hyperbola)

Conical surface

Glide-path antenna

Figure 5.4: Hyperbolic intersection of localizer and glideslope reference planes

58

Chapter 5. Radio-navigation, sensors, actuators

Localizer transmitter

8

o

8o

Glideslope 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 figure 5.4. The minimum coverage of the glideslope signals, required by ICAO [2] is shown in figure 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 figure 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 final 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 pilot’s cockpit instrument. The magnitude of the localizer current iloc is proportional to the localizer deviation angle Γloc , shown in figures 5.7 and 5.8, while the glideslope current i gs is proportional to the glideslope deviation angle ε gs , shown in figure 5.8. From these figures, 1 The

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 figure 5.6. Local circumstances, such as special terrain features or radio-interference patterns, may also dictate higher minimums.

5.1. The Instrument Landing System

59

↑ Decision height [ft]

Cat. I 200

-?

100

?

Cat. II -?

A

B C

Cat. III 0

1000

800

600

?

?

400

200

??

50 0

Runway visual range [m] → Cat. I : Cat. II :

Cat. III A:

Cat. III B:

Cat. III C:

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 final 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 sufficient 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

Figure 5.6: ILS performance categories

we can deduce that Γloc is defined 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 final approach, we will call them ‘localizer deviation angle’ and ‘glideslope deviation angle’, respectively. For the simulation of ILS-approaches, we will use the runway-fixed reference frame FRW , which has been defined in appendix A. At time t = 0 the position of the aircraft’s center of gravity coincides with the origin of the Earth-fixed reference frame FE , hence, at that moment xe = 0, ye = 0, and H = H0 . The position of the origin ORW of the runway-fixed reference frame is defined by the coordinates xt and yt , measured relatively to the Earth-fixed 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 figure 5.7. The vertical relation has been depicted in figure 5.9, using the intermediate reference frames FE0 = OE0 XE0 YE0 ZE0 and FE00 = OE00 XE00 YE00 ZE00 to help interpret the spatial orientation. FE0

60

Chapter 5. Radio-navigation, sensors, actuators

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. FE00 has the same orientation as FE0 , except its origin has been shifted to runway level. Hence: xe00 = xe0 = xe − xt xe00

(5.1)

y0e

= ye − yt = (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-fixed reference frame FRW (the index f denotes ‘flight’), and the height of the airplane above the runway threshold, H f . Observing figures 5.7, 5.8, and 5.9, and substituting equations 5.1 and 5.2, we find the following transformations from FE to FRW : x f = ( xe − xt ) cos ψRW + (ye − yt ) sin ψRW (5.3) y f = −( xe − xt ) sin ψRW + (ye − yt ) cos ψRW (5.4) H f = H − Ht (5.5) where ψRW is the heading of the runway, measured relatively to the North, H is 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 figure 5.7, Γloc can be computed from the coordinates x f and y f as follows: q )   dloc Rloc = y f 2 + ( xloc − x f )2 Γloc = arcsin (5.6) Rloc dloc = y f Γloc and dloc are positive if the aircraft flies 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 rad−1 ] (5.8) where xloc is the distance from the localizer antenna to the runway threshold, shown in figure 5.2. All distances are measured in [m], and all angles must be measured in [rad]. The maximum value of the localizer current iloc is limited to ±150 µA, hence ±150 µA represents a full-scale deflection on the cockpit instrument [2]. The locations which provide a constant glideslope current lie on a cone, as shown in figure 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 figure 5.8): i gs = Sgs ε gs

[µA]

(5.9)

Full-scale deflection 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 rad−1 ] (5.10) |γgs |

5.1. The Instrument Landing System

61

xf (-)

xloc X" E

dloc = yf (+)

ΨRW

Runway

XRW

Γloc (+)

YRW

Localizer antenna

Y" E

R loc Position of aircraft’s c.g. at t = 0

XE YE

Figure 5.7: Localizer geometry and definition of XE0 , YE0 , XRW , and YRW -axes

Glideslope antenna dgs (+)

εgs(+)

ygs(-)

γgs (-)

XRW

Γgs (+)

Runway

ZRW YRW

s

Hf

Rg

+)

xgs ( )

x f (yf ( +)

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

62

Chapter 5. Radio-navigation, sensors, actuators

Nominal glidepath

yf Runway

YRW

ψ RW

y" e

x" e Hf

Y" E

xf

ψ RW

X" E

H Ht XRW

Sea level

Y’E X’E Z’E , Z"E , Z RW

No r

th

Figure 5.9: ILS geometry: expressing the aircraft position in the runway-fixed reference frame and the intermediate (Earth-fixed) coordinate systems FE0 and FE00 . 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 figure 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: q R gs = ( x gs − x f )2 + (y f − y gs )2 (5.11)   Hf ε gs = γgs + arctan (5.12) R gs 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 flies above the glideslope reference line. Notice that γgs is always negative!

5.1. The Instrument Landing System

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

± 17

± 10.5

II

± 17

± 7.5

(± 10 where practicable)

(± 4.5 for new installations)

± 10

±3

III

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

± 25

± 0.075 γgs

II

± 20

± 0.075 γgs

III

± 10

± 0.04 γgs

Table 5.2: Maximum permissible glideslope steady-state errors

In order to be able to verify whether the aircraft flies in the glideslope coverage area (figure 5.5), we will also calculate the angle Γ gs :   y f − y gs Γ gs = arcsin (5.14) R gs 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

Chapter 5. Radio-navigation, sensors, actuators

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 h i 1 −1 2 Sloc (Ω) = 2σloc 2 Lloc µA rad m (5.15) 1 + (ΩLloc )2 where: σloc = standard deviation of the localizer noise, Lloc = ‘scale’ of the localizer noise, approximately 130 m Ω = spatial frequency [rad m−1 ] The power spectral density of the glide path noise appears to be similar to the localizer noise and may be approximated by: h i 1 −1 2 Sgs (Ω) = 2σgs 2 L gs µA rad m (5.16) 1 + (ΩL gs )2 where: σgs L gs Ω

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

For atmospheric turbulence it is often assumed that the turbulence velocities are functions only of the position in the atmosphere (the frozen field concept or Taylor’s hypothesis). This assumption can be made because aircraft usually fly at large speeds compared to turbulence velocities. Using Taylor’s hypothesis for the ILS noise will probably introduce errors, especially for aircraft with very low final approach speeds such as the Beaver. Still, this assumption makes it possible to convert the spatial power spectral density 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. 1 Note:

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 definition of the Fourier transform. In this report, the definition of the Dryden filters from ref.[27] has been used, and due to the similarity of the expressions for ILS noise the term π will be omitted here too. See also the footnote on page 48. The definitions of the Fourier transform and the inverse Fourier transform used in ref.[27] are: X (ω ) = F { x (t)} =

Z ∞ −∞

x (t)e− jωt dt;

x (t) = F −1 { X (ω )} =

∞ 1 X (ω )e jωt dω 2π −∞

Z

5.1. The Instrument Landing System

65

σloc ,σgs [µΑ]

σgs (cat. I)

15

t. II,

σgs (ca

III)

. I)

cat

σloc (

10

. at

σ loc

7.5

II,

) III

(c

5

2.5

σloc (cat. III) -600

0

600

1050

7410 Distance to threshold, [m]

Figure 5.10: Maximum allowable ILS localizer and glideslope noise

With Taylor’s 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 filter in the same way as the derivations for atmospheric turbulence shown in figure 4.4. The resulting filters are: r 1 2Lloc Hloc (ω ) = σloc (5.17) L V 1 + loc jω V r 2L gs 1 Hgs (ω ) = σgs (5.18) V 1 + Lgs jω V

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: h i 25 (1.5 + jω )2 −1 2 Sloc = | Hloc (ω )|2 = µA rad s (5.19) (0.35 + jω )2 (10 + jω )2 h i 15.9 −1 2 Sgs = | Hgs (ω )|2 = µA rad s (5.20) (0.25 + jω )2 The filters for these spectral density functions are: 5 (1.5 + jω ) (0.35 + jω )(10 + jω ) 3.9875 Hgs (ω ) = ± 0.25 + jω

Hloc (ω ) = ±

(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 figure 5.10.

66

Chapter 5. Radio-navigation, sensors, actuators

In addition to the ILS noise and steady-state errors, specific deterministic interference patterns may occur due to signal reflections 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 1950’s. 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 final approach guidance if the pilot flies 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 fix 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 fix 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 figure 5.11. Simple generalaviation VOR systems make it possible for the pilot to fly along a reference VOR

5.2. The VOR navigation system

67

ψ

CD

ΓVOR

QDR Reference VOR radial

VO R

R

xVOR

xe

VOR antenna

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 flying 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 deflection is ΓVOR = 10◦ . The bearing information can also be coupled to an automatic control system, allowing the airplane to automatically fly from or to the VOR along a reference radial, or to automatically intercept a VOR bearing. Although many autopilots still 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.

68

Chapter 5. Radio-navigation, sensors, actuators

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-fixed reference frame. If the horizontal position of the VOR ground station is defined by the coordinates ( xVOR , yVOR ) and the horizontal position of the aircraft by ( xe , ye ), we can find the following equations for the QDR and the course deviation angle ΓVOR (see figure 5.11):   ye − yVOR QDR = arctan (5.23) xe − xVOR ΓVOR = CD − QDR (5.24) We also need to know whether the aircraft flies toward the VOR beacon, or away from it. This information is visualized in the cockpit by means of a ‘TO-FROM indicator’, which verifies the difference between the airplane’s heading ψ and the QDR:

|ψ − QDR| > 90◦ ⇒ ‘TO’ |ψ − QDR| < 90◦ ⇒ ‘FROM’

(5.25)

(In figure 5.11 we can observe that the aircraft is flying away from the VOR beacon. This corresponds with the above given relations since ψ − QDR ≈ 40◦ , which 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 flies in an area where the VOR signals can be received with appropriate reliability. This distance is equal to: q RVOR = ( xe − xVOR )2 + (ye − yVOR )2 (5.26) If the aircraft flies 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 figure 5.12. The aircraft flies outside the cone of silence if [5]:   H − HVOR ξ ≡ arctan ≤ 90◦ − (40◦ to 60◦ ) (5.27) RVOR 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 flight tests [7]. Using the M ATLAB function POLYFIT to fit 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 · 10−6 ( H − HVOR )2 +  + 5.7087 · 10−2 ( H − HVOR ) + 80.8612 (5.28)

5.2. The VOR navigation system

40 o

Cone of Silence

to 6

E M

RD

VOR antenna

0o

H - HVOR

o

0

to 6 40 o

69

ξ

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]: √  p 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◦ .

70

Chapter 5. Radio-navigation, sensors, actuators

Height [ft]

VOR range [NM]

1000 5000 20000 30000

50 92 182 220

3000 5000

75 95

Table 5.3: VOR coverage based on two different flight 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 figures suggest.

5.3

Other flight 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-traffic environment, using VOR and DME systems for guidance along airways, standard arrival routes, and standard departure routes. However, in modern air-traffic control environments, it has become increasingly common to define ad-hoc flight-paths along great circles1 between fixed (sometimes arbitrary) waypoints, rather than fly along pre-determined airways, defined 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 1970’s 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 defining the navigation geometry, and include systematic and random system errors thereafter. It should be noted that in flight 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 flight 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 flight control computers of the airplane. In addition, we must remember that this model is based on the actual deflections of control surfaces, which do not necessarily correspond to the intended control inputs generated either directly by the pilot (using the flight controls in the cockpit), or indirectly via an automatic flight control system (using electric signals to define deflections 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 influences. Whether or not such refinements are really necessary obviously depends on the required accuracy for specific tasks. For instance, while it may very well be possible to build a decent set of flight 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 Significant Bit of approximately 4 feet, which would lay well within the

72

Chapter 5. Radio-navigation, sensors, actuators

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 filtering 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 flight control system design tasks and flight simulation, this report will not further elaborate on this subject. However, the toolbox does take into account some specific 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 flight, 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 figure corresponds to the upper part of figure 1.3 from chapter 1, which depicted the flight 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 fulfil 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

Initialisation data

Nonlinear state-space model . x ( t ) = f ( x( t ) , u ( t ) , t ) y ( t ) = g ( x ( t ), u ( t ) , t )

Control system simulation

Linearise

Coefficient data

Nonlinear simulation

Linear statespace model . x(t) = A x (t) + B u (t) y( t ) = C x ( t ) + D u ( t )

Trial design

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

6.1.1

The type of problems considered

The numerical integration methods considered here are used to determine time-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 specified. 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

75

x

Initial value

x0

x2

x1

x3

Euler solution

t0

t1

t2

t3

t

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 , xn−1 , . . . , xn−k+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 )

(6.3)

This method is used by the S IMULINK integrator ode1.

6.1.2

Stability, errors, and order of a numerical integration method

Figure 6.2 shows a typical family of solutions of a first-order differential equation 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 figure 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 finite 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

Chapter 6. Analytical tools

x

t

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 figure 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 figure 6.5, which demonstrates a system where the numerical error of the Euler method is amplified in each step. The order of a numerical integration method is defined 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)

6.1. Numerical integration methods

77

C may depend on the derivatives of the function which defines 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:   hn 2 hn p d p x xn+1 = xn + hn x˙ n + x¨ n + . . . + (6.6) 2! p! dt p x (t + hn ) = x (t) + hn x˙ (t) +

The derivatives x˙ n , x¨ n , etc. can be expressed in terms of the partial derivatives of the function f from the state equation (6.2). The first 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 first. 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 first 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

Chapter 6. Analytical tools

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

(6.8)

To determine the coefficients, k1 and k2 are expanded in a Taylor series about (tn , xn ), giving: k1 = hn f n       ∂f ∂f k2 = hn f n + βk1 + αhn + ... ∂x n ∂t n

(6.9)

Hence: x n +1 =

xn + (γ1 + γ2 )hn f n + γ2 βh2n



∂f ∂x



f n + γ2 αh2n



n

∂f ∂t



+ ...

(6.10)

n

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 ): h2 zn (tn+1 ) = zn (tn ) + hn z˙ n (tn ) + n z¨n (tn ) + . . .  2    2 hn ∂f ∂f = xn + hn f n + fn + + ... 2 ∂x n ∂t n

(6.11)

Matching the coefficients of the powers of hn yields three equations involving the unknown coefficients: γ1 + γ2 = 1 γ2 β = γ1 α =

1 2 1 2

(6.12)

It is now possible to choose one coefficient 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)

Obvious choices of α are 21 , 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.

6.1. Numerical integration methods

αi

79

β ij

0 1 5

1 5

3 10

3 40

9 40

4 5

44 45

56 − 15

32 9

8 9

19372 6561

− 25360 2187

64448 6561

212 − 729

1

9017 3168

− 355 33

46732 5247

49 176

5103 − 18656

1

35 384

0

500 1113

125 192

− 2187 6784

11 84

γi ∗

γi

35 384

5179 57600

0

0

500 1113

7571 16695

125 192

393 640

− 2187 6784

92097 − 339200

11 84

187 2100

0

1 40

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

In order to reduce the number of function evaluations, mathematicians have 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 specified 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 β coefficients 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 defined by: i −1

k i = hn f ( xn + ∑ β ij k i , tn + αi hn )

(6.14)

j =1

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

x n + 1 = x n + ∑ γi k i i =1 N

xn∗ +1 = xn + ∑ γi∗ k i

(6.15)

i =1

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 =

N

∑ (γi − γi∗ )

i =1

is determined and used for step-size control.

(6.16)

80

Chapter 6. Analytical tools

The coefficients αi , β ij , and γi can again be found by by expanding the k’s 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 k’s. A popular strand of explicit Runge-Kutta methods are the Dormand-Prince pairs. Table 6.1 lists the coefficients of the fourth- and fifth-order methods (represented by the coefficients γ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 efficiently 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 classified as ‘stiff’ or ‘nonstiff’ automatically. Linear multistep methods can be considered as special cases of the formula: x n +1 =

k

k

i =1

i =0

∑ α i x n +1− i + h n ∑ β i f n +1− i

(6.17)

where f i = f ( xi , ti ) = x˙ i , k is an integer, and either αk or β k is not zero. This formula defines 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 , xn−1 , . . . , xn−k+1 , and f n , f n−1 , . . . , f n−k+1 . If β 0 is nonzero, the algorithm is implicit because in that case the solution xn+1 is needed to evaluate f n+1 = x˙ n+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.

6.1. Numerical integration methods

81

i:

1

β 1i

1

2β 2i

3

−1

12β 3i

23

−16

5

24β 4i

55

−59

37

−9

720β 5i

1901

−2774

2616

−1274

251

1440β 6i

4277

−7923

9982

−7298

2877

2

3

4

5

6

−475

Table 6.2: Coefficients for the Adams-Bashforth integration method

i:

1

β 1i ∗

1

2β 2i ∗

1

1

12β 3i ∗

5

8

−1

24β 4i ∗

9

19

−5

1

720β 5i

∗

251

646

−264

106

−19

1440β 6i

∗

475

1427

−798

482

−173

2

3

4

5

6

27

Table 6.3: Coefficients for the Adams-Moulton integration method

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

xn+1 = xn + hn ∑ β ki f n+1−i

(6.18)

i =1

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

∑ βki ∗ f n+1−i

(6.19)

i =0

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

Chapter 6. Analytical tools

x x2

f (t)

x0 x1

t0

t1

x3

t2

t3

t

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

x f (t) x0

t0

x1

x2

t1

t2

x3

t3

t

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

6.1. Numerical integration methods

83

k:

2

3

4

5

6

β0

2 3

6 11

12 25

60 137

60 147

α1

4 3

18 11

48 25

300 137

360 147

α2

− 13

9 − 11

− 36 25

− 300 137

450 − 147

2 11

16 25

200 137

400 147

3 − 25

75 − 137

225 − 147

12 137

72 147

α3 α4 α5 α6

10 − 147

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

6.1.4

Stiff differential equations

‘Stiffness’ of the differential equations can roughly be defined as the presence of 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 defined as the time in which a solution to a differential equation decays by a factor 1e . In a physical system, different elements often have different 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 insignificant 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

Chapter 6. Analytical tools

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

xn =

∑ α i x n −i + h n β 0 f n

(6.21)

i =1

The coefficients α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 briefly discuss the theoretical backgrounds. We start with the nonlinear state equation: x˙ (t) = f( x(t), u(t) )

(6.22)

(the disturbance vector v has been neglected this time; for this discussion we 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 first-order terms, we find: ∂f ∂f x˙ (t) ≈ ( x − x0 ) + (u − u0 ) + x˙ 0 (6.23) ∂x ∂u where x˙ 0 = f( x0 , u0 ) and both partial derivative matrices are determined for the operating point (x0 , u0 ). Moving x˙ 0 to the left-hand side of the equation yields: x˙ − x˙ 0 =

∂f ∂f ( x − x0 ) + ( u − u0 ) ∂x ∂u

(6.24)

Now define: x0 = x − x0 , a vector of length n u0 = u − u0 , a vector of length m and: ∂f A = ∂x (x0 ,u0 ) ∂f B = ∂u (x0 ,u0 ) Substitution into equation (6.24) yields the small-perturbations formula: x˙ 0 = Ax0 + Bu0

(6.25)

which is the desired linear state equation, with x0 and u0 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 flight 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 first 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 don’t need to perform this complete analysis just to find 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  ∂ f1 1 . . . ∂xn  ∂x. 1 ..   . 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 ) ∆ f1 f 1 (x0 +∆xn ,u0 )− f 1 (x0 ,u0 ) 1 1 0 1 0 1 0 0 . . . . . . ∆xn ∆x1 ∆xn  ∆x. 1    . .   (6.27)   . . . A ≈  . . = .  ∆ fn ∆ fn f n (x0 +∆xn ,u0 )− f n (x0 ,u0 ) f n (x0 +∆x1 ,u0 )− f n (x0 ,u0 ) . . . . . . ∆x1 ∆xn ∆x1 ∆xn with:



 δi,1  δi,2    ∆xi = ∆xi ·  .   .. 

 δi,j =

0 if i 6= j 1 if i = j

δi,n The columns of A can be written as vectors, yielding: h i h f(x0 +∆xn ,u0 )−f(x0 ,u0 ) 0 )− f ( x0 ,u0 ) A ≈ f(x0 +∆x1 ,u = . . . ∆x ∆x 1

n

(6.28)

x˙ x1 −x˙ 0 ∆x1

...

x˙ xn −x˙ 0 ∆xn

i

(6.29)

In this equation we used the definition: x˙ xi ≡ f(x0 + ∆xi , u0 )

(6.30)

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

Chapter 6. Analytical tools

A similar method can be used to find the matrix B. This time, we need to perturb the elements of the input vector u, which results in the following approximation: h i h i x˙ u1 −x˙ 0 f(x0 ,u0 +∆um )−f(x0 ,u0 ) x˙ um −x˙ 0 f(x0 ,u0 +∆u1 )−f(x0 ,u0 ) B≈ = (6.31) ... . . . ∆u ∆u ∆u ∆u m

1

with:



  ∆ui = ∆ui ·  

δi,1 δi,2 .. .

1

m

    

 δi,j =

0 if i 6= j 1 if i = j

(6.32)

δi,m and: x˙ ui ≡ 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) ≈

y0 ≡ y − y0 = Cx0 + Du0

(6.36)

with: ∂g C = ∂x (x0 ,u0 ) ∂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 flight

6.3

87

Steady-state trimmed flight

The FDC toolbox contains a specialized utility ACTRIM, which determines steadystate trimmed flight 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

Definition of steady-state flight

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 reflects 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 satisfies: ˙ x, u) = 0 , with: x˙ = 0 and: u = 0 or constant f(x,

(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 flight can be defined as a condition in which all of the motion variables are constant or zero, and all acceleration components are zero. This definition is very restrictive, unless some simplifying assumptions are made. We will assume the aircraft’s mass to remain constant, and restrict the analysis to the flat-Earth equations of motion, so that the definition will allow steady wings-level flight and steady turning flight. 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 flight conditions.

88

Chapter 6. Analytical tools

One method to find a steady-state flight 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 flexibility 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 figure 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 flight. 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

Specification of the flight condition

We must first decide how to specify the steady-state flight 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 flight condition, as they no longer couple back into the other equations of motion. Steady-state flight conditions that are important for flight control system design can then be defined in terms of the remaining nine state variables of the flatEarth equations: ˙ α, ˙ q, ˙ r, ˙ V, ˙ β˙ (or u, ˙ v, ˙ w˙ ) ≡ 0 and u = constant p,

(6.40)

Additional constraints have to be made to define the exact flight condition. Here we will consider steady wings-level flight, steady turning flight, steady pull-up or push-over, and steady rolls, which are defined by the following constraints: ˙ ψ˙ ≡ 0 (i.e. p, q, r ≡ 0) ˙ θ, steady wings-level flight: ϕ, ϕ, ˙ θ˙ ≡ 0, ψ˙ = turn rate steady turning flight: ϕ, ˙ ψ˙ ≡ 0, θ˙ = pull-up rate steady pull-up or push-over: ϕ, ϕ, ˙ ψ˙ ≡ 0, ϕ˙ = roll rate steady roll: θ, ˙ q, ˙ r˙ ≡ 0, the angular rates must be zero (as in level flight) To satisfy the conditions p, ˙ α, ˙ β˙ ≡ 0 require the airspeed, or constant (as in steady turns). The conditions V,

6.3. Steady-state trimmed flight

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 configuration (such as the position of the landing gear and the aircraft loading) and secondary flight controls (flaps, slats, speedbrakes) are pre-specified. In addition, we must specify the ‘secondary engine controls’ (target RPM for a constant-speed propeller, mixture control for a piston engine) and configuration settings that affect engine power (bleed air requirements for jet engines, thrust limit settings for specific phases of flight). For the Beaver model, we will pre-specify the flap position δ f and the engine RPM n. For steady-state flight, we expect to be able to specify the (initial) altitude 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 fix the flight-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 flight-path angle, changes in airspeed are achieved by increasing or decreasing engine power. 2. Alternatively, we can fix the engine thrust, without putting any constraints on the flight-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 flight with an engine thrust that exceeds the weight of the airplane, as even for vertical flight that would result in a linear acceleration. The first method introduces an additional constraint on the pitch angle, while letting the engine thrust be determined numerically. In the latter case, the pitch angle will be adjusted numerically, but the thrust will be pre-specified. Notice that nonzero values of the flight-path angle will result in ‘instantaneous’ steady-state flight 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 flight 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-specified (‘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-specified. 1 Because of this requirement,

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 flight conditions and use the resulting operating point values of x and u for aircraft model linearisation, because flight control systems must operate there too.

90

Chapter 6. Analytical tools

In steady-state translational flight conditions, the state variables ϕ, p, q, and r are identically zero and ψ can be selected freely. Since V and H are also specified 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 flight-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 specified by the user (‘speed on pitch’), the pitch angle can be adjusted by the trim algorithm. In steady-state turning flight conditions, the state variables ϕ, p, q, and r will differ from zero. The turn can be specified 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 specified 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 define the turn by specifying the roll angle ϕ directly. However, that will in general introduce a significant sideslip angle β, resulting in a skidding turn, in which a side-force is experienced by the flight 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 z˙ e part of equation (2.61), and equations (2.31), (2.62), and (3.45): H˙ z˙ e sin γ = = − = V V = − ue sin θ + (ve sin ϕ + we cos ϕ) cos θ =

=

a sin θ − b cos θ

(6.42)

with: a ≡ cos α cos β b ≡ sin ϕ sin β + cos ϕ sin α cos β

(6.43)

6.3. Steady-state trimmed flight

91

Solving for θ, the resulting rate-of-climb constraint is found to be [33]: q a b + sin γ a2 − sin2 γ + b2 , θ 6= ± π2 tan θ = (6.44) a2 − sin2 γ which allows us to compute θ, knowing the pre-specified value of γ and the current value of ϕ. Obviously, this constraint is not applicable for ‘speed on pitch’.

6.3.5

The coordinated turn constraint

In the Earth-fixed reference frame, assuming a flat Earth, the velocity vector is 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

(6.46)

From the kinematic relations (2.59), we can derive: p = −ψ˙ sin θ r =

ψ˙ cos θ cos ϕ

(6.47)

Substituting these equations in equation (6.46), and replacing u and v by the corresponding relations from equation (2.31), we find:   ˙ g0 cos θ sin ϕ − ψV sin θ sin α cos β + cos θ cos ϕ cos α cos β = 0 (6.48) Finally, by substituting equation (6.45) and re-writing terms, the resulting coordinated turn constraint is found: sin ϕ = G cos θ (sin α tan θ + cos α cos ϕ)

6.3.6

(6.49)

Combined constraints

Equation (6.49) must be used in conjunction with (6.44) if we want to trim the aircraft for a coordinated turning flight with a specified 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: q ˜ 2 ) + b˜ tan α c˜ (1 − b˜ 2 ) + G2 sin2 β ˜ ( a − b cos β tan ϕ = G (6.50) cos α a˜ 2 − b˜ 2 (1 + c˜ tan2 α) where: a˜ ≡ 1 − G tan α sin β sin γ b˜ ≡ cos β c˜ ≡ 1 + G2 cos2 β

(6.51)

92

Chapter 6. Analytical tools

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 flight-path angle is zero, equation (6.50) reduces to: tan ϕ =

G cos β cos α − G sin α sin β

(6.52)

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

6.3.7

The resulting steady-state trimmed-flight algorithm

We can now develop a general aircraft-trim algorithm that determines steady-state flight conditions by searching for the state and control vectors for which the state ˙ p, ˙ α, ˙ β, ˙ q, ˙ and r˙ are identically zero, as specified in equation (6.40). derivatives V, 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 p˙ 2 + c5 q˙ 2 + 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 flight condition must be specified. 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 find the ˙ Substituting the results in equation (6.53) yields time-derivative of the state-vector, x. 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 finish 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 figure 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 difficulties 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 artificial 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 find 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 figure 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 first input u minus the output y, which equals K · e: y = K · e = K (u − y) The solution of this simple loop is:   K y= u 1+K but most algebraic loops cannot be solved so easily [4].

(6.54)

(6.55)

94

Chapter 6. Analytical tools

e

u

y

K

+_

Figure 6.8: Gain with unity feedback: an algebraic loop

4 Input: unit step at t = 0

3

2

K / )

t 1 ( y

K = 0.5

0

K = 1.0 K = 1.5

-1

-2

0

1

2

3

4

t[s]

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

Algebraic Equations

x

ALB

g(x)

Figure 6.10: Iterative solution of an algebraic loop

5

6.4. Miscellaneous simulation issues

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 artificial computation sequence as follows: e n = u n − y n −1 yn = Ken = K (un − yn−1 )

(6.56)

where yn ≡ y(n · hn ) and yn−1 ≡ y((n − 1)·hn−1 ) for an integer value n. Taking 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 figure 6.10. This block has an input g( x ) and an output x. The block attempts to find 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

(6.58)

This is done by applying the Newton-Rhapson method [8]: x i +1 = x i −

G ( xi ) G 0 ( xi )

(6.59)

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 filter or an artificial time-delay. However, the effect of such measures needs to be weighted carefully – remember the inadvertent dynamics from figure 6.9. Sometimes, it is possible to write out the system equations in an explicit form. For instance, the algebraic loop from figure 6.8 can be eliminated by replacing 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 aircraft’s sideslip angle was averted by re-writing the differential equation in an explicit form. G 0 ( xi ) =

96

Chapter 6. Analytical tools

bn b n-1 b n-2

b1 sn V

U(s) +

1/s

s n-1 V

1/s

sn-2 V

sV

1/s

++ ++

++

V(s)

b0

++ ++

++ ++

Y(s)

an-1 an-2

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 coefficients. 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 + . . . + a + a1 + a0 y = 2 n − 1 dtn dt2 dt dtn−1 m m − 1 d u d u d2 u du = bm m + bm−1 m−1 + . . . + 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

6.4. Miscellaneous simulation issues

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 + bm−1 sm−1 + . . . + 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 finding 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 first 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) − an−1 sn−1 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 figure 6.11. This diagram is constructed from a series of cascaded first-order integrals (the 1s blocks) and simple gain blocks; V (s) is the output of the last integrator and 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 first integrator to the transfer function input U (s) and the feedback signals from later integrators. This equation corresponds to the lower half of figure 6.11. Equation (6.64) establishes the resulting output signal Y (s); the output connections have been drawn in the upper half of the figure. Notice that the figure assumes the highest order of the input and output derivatives to be equal, i.e. m = n. For m < n, some of the bi coefficients are zero. If we now assign state variables to the integrator outputs, working from right to left and starting with the rightmost integrator, we can define 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

Chapter 6. Analytical tools

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

(6.68)

d = bn

This form of the system matrix A is known as a companion-matrix: all elements are zero, except for the superdiagonal 1’s 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 figure 6.11 has been applied for the implementation of the Dryden turbulence filters, which are defined by transfer functions with airspeed-dependent coefficients, and for a filter in the Altitude Select mode of the Beaver autopilot, which also uses non-constant coefficients. Obviously, the standard Transfer Fcn block from S IMULINK is more convenient for the implementation of transfer functions with constant coefficients.

Chapter 7

Getting started with the FDC toolbox Having treated the underlying theory, it is now time to introduce the Flight 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

Let’s 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 flight simulation, open-loop analysis of aircraft dynamics, and closed-loop analysis of flight 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 flight conditions and linearized flight 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 flight 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

7.2

Chapter 7. Getting started with the FDC toolbox

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 filesystem used and the amount of ‘file slack’ for the relatively large number of small files. 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 -file that is shipped with the software itself.

7.3

License Agreement

The FDC toolbox version 1.4 is distributed as Open Source software, licensed 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 flat-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 modified files, 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 flight dynamics modelling into practice, and which provides the flexibility 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 file 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

Chapter 7. Getting started with the FDC toolbox

path by running a dedicated initialisation utility. The following instructions will guide you through this installation process: LAB

1. Copy the archive file 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 fine 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 that’s fine 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 file also contains a copy of these installation instructions), and COPYING . TXT and LICENSE . TXT for the terms of use. Other documentation files 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 files. 5. Start M ATLAB version 5.3 or later and use the command cd or chdir to go to the FDC directory specified above (from now on denoted as ‘FDC root-directory’). This has been illustrated in figure 7.1, where it is assumed that the FDC 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 figure 7.2 will appear, to signal that the toolbox is being started; click on the splash screen with the mouse pointer, or press any key to continue.1 After closing the splash screen, the command window will look like figure 7.3. 7. The toolbox will now be initialized by appending the FDC subdirectories to the M ATLAB-path. As shown in figure 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 sufficient 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 figure 7.4, from where you can change the root-directory, change or delete the subdirectories, or add new subdirectories to the toolbox. Select ‘ready’ to return to the directory-check window from figure 7.3. 9. If the FDC path is correct, you can leave the directory-check window by 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 file FDC . M, contained in the FDC root-directory.

7.4. Installation and initialisation of FDC 1.4

Figure 7.3: Verify the FDC directory structure during initialisation

Figure 7.4: Specifying a new FDC 1.4 root-directory during initialisation

103

104

Chapter 7. Getting started with the FDC toolbox

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 confirmation, as shown in figure 7.5. 10. Next, the welcome message from figure 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 helpfiles 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 , where 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 find 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 files 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 datafiles 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 files, 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. 1 If

it is desired to restore the directory check and editing features for later FDC sessions, the file must be deleted from the FDC root-directory. This will cause the FDC initialisation routine to assume that the toolbox is run for the first time, and reset the FDC path to its default status. FDCINIT. INI

106

7.6

Chapter 7. Getting started with the FDC toolbox

The FDC directory structure

Let’s take a closer look at the contents of the FDC toolbox, starting with an overview of its directory structure. The files 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 defines 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 datafiles (in particular *. TRI files, which are used to store trimmed flight conditions, *. LIN files, to store system matrices of linearized aircraft models, and *. DAT files, to store model parameters), DOC contains program documentation files (README-file, list of new features, list of features for future versions of the toolbox, a complete list of all files 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 deflection curve for trimmed flight conditions, HELP contains the HTML helpfiles for the FDC models and programs, NAVIGATE contains the library NAVLIB and its sublibraries, which include 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 datafiles, 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 fix 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 figure 7.7, which can be opened by typing fdclib at the command-line.

7.7. The FDC model libraries

107

Figure 7.7: Main block-library of the FDC toolbox

FDCLIB includes the six aircraft model sublibraries FDCLIB1 till FDCLIB6, which con-

tain the blocks from the nonlinear dynamic model of the Beaver. In addition, it 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

Chapter 7. Getting started with the FDC toolbox

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 figure 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 figure 7.9 will be shown. The first 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 figure 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 figure 7.9. The subsystem includes four masked blocks, which have been linked from a S IMULINK library, and five 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 figure 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 figure 7.10. Double-clicking this block results in the mask-dialog from figure 7.11. As we have seen before in figure 7.9, the mask-dialog includes a short description of the block, a

110

Chapter 7. Getting started with the FDC toolbox

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

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

111

112

Chapter 7. Getting started with the FDC toolbox

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 field, although it has been locked because the parameter definition for this particular block can only be changed in the library in which it is defined. 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, figure 7.12 will be opened, with the Gravity block being activated as shown in the figure. 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 figure 7.12. The internal structure of this block can again be shown by unmasking it first. This yields figure 7.13, which shows the deepest level of this block, i.e. the level in which the actual equations are evaluated. The expressions within the individual Fcn blocks will probably look rather cryptic at first 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 first 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 figure 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 block’s 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 first 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 definitions (e.g. increase the number of outputs), or change the names of blocks within a library. The latter is important, because library links are defined

7.10. Summary of the model and library structure

113

by reference to the blocknames (changing blocknames in models doesn’t matter, because in that case only the name of the link placeholders is modified). A save method to implement big changes is to create a clone of the original block first, by copying the block and breaking its library link.

7.10

Summary of the model and library structure

Let’s summarize these last two sections before proceeding. All FDC models have 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 fields. 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 first, 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 first. 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

Chapter 7. Getting started with the FDC toolbox

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 first 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 helpfiles, 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 difficult 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 files 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 filenames for your own adaptations of the FDC models and tools to prevent possible mix-ups in the future. Don’t 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 doesn’t make this toolbox entirely error-proof. If you are not keen on reading before experimenting, it is recommended to at least study the relevant helpfiles and read chapter 13, which contains some examples of the practical use of this toolbox.

7.13. About the block and function reference chapters

7.13

115

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 don’t 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 doesn’t 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 figure 3.2 of chapter 3. The resulting S IMULINK model has been shown in figure 8.1. This model differs from figure 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 figure 3.2 should be clearly recognisable in the S IMULINK model. Apart from the aerodynamic and propulsive forces, all elements from figure 3.2 are independent of the airplane under consideration. This is also true for the S I MULINK model from figure 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 suffix ‘(Beaver)’. From left to right and from top to bottom we can distinguish the following blocks and subsystems in the S IMULINK model from figure 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 first 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 find 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 figure 8.1, we see the external inputvectors uaero and uprop , which contain the control inputs to the aerodynamic and engine models (control surface deflections, 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 aircraft’s 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 definitions of the input vectors. The output vectors from the blocks in figure 8.1 are all gathered on the left-hand side of this model. In total there are 18 output vectors, which have been defined in table D.2 of appendix D. In order to handle the input/output functions for this flight 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 figure 8.1, which is why this level will be designated ‘Beaver Level 1’ in the remainder of this report. The actual aircraft model is consid-

8.1. The aircraft model and its subsystem equivalents

119

yatm yad1 x

yad2 yad3

Airdata Group

x uaero

1 uaero

yad1

18 yad3

ydl Caero FMaero

x uprop

2 uprop

yatm yad1

17 yad2

11 FMaero

Aerodynamics Group (Beaver)

15 yatm

16 yad1

5 ydl

9 Caero

ypow Cprop FMprop

12 FMprop

Engine Group (Beaver) Gravity

13 Fgrav

Gravity forces Fwind W ind forces

14 Fwind

FMsort Ftot

Add/sort forces and moments

3 uwind

7 ypow

10 Cprop

x

Mtot uwind yatm yhlp

2 xdot

1

ybvel

Aircraft Equations of Motion (Beaver) x xdot yhlp Ftot Fgrav

1 x

1

xdot

3 ybvel

yfp yuvw yacc

Additional outputs

6 yfp

4 yuvw

8 yacc

hlpfcn (co)sines of alpha, beta, psi, theta, phi

yhlp xdot x

Figure 8.1: Block-diagram of the main level of the aircraft model (Beaver Level 2) time Clock In

1 deltae 3 deltar

5 n 7 uw 9 ww 11 vwdot

To Workspace

Mux click 2x for info!

To Workspace Out

To Workspace

2 alpha

Mux 4 p

Double-click for info!

2 deltaa

x Mux

Demux

uaero

4 deltaf

8 theta Mux

uprop

6 pz 8 vw

6 r

Mux

DeHavilland DHC-2 Beaver dynamics and output equations

10 xe

3 beta 5 q 7 psi 9 phi 11 ye

12 H

uwind xdot

Demux

10 uwdot ydl

12 wwdot

1 V

Demux

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

Chapter 8. Aircraft model block reference

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 definitions. The stand-alone model and the first subsystem equivalent use the I/O structure from figure 8.2; the second subsystem equivalent uses a slightly different output structure, creating two output vectors instead of 16 scalar output signals. From figure 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 figure 8.2.1 The current choice of output signals provides sufficient 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 figure 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

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.

121

122

Chapter 8. Aircraft model block reference

12 ODEs

Beaver level 1 / Beaver level 2 / Aircraft Equations of Motion / 12 ODEs Main FDC library / Equations of motion

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 flat, 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

computes time-derivatives of true airspeed, angle of attack, and sideslip angle,

pqrdot

computes time-derivatives of the angular velocities along the body-axes of the aircraft,

Eulerdot

computes time-derivatives of the Euler angles,

xyHdot

computes time-derivatives of the coordinates and the altitude above sea-level.

Inputs x Ftot Mtot yhlp

= = = =

[ 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

ybvel

∗

= [ u + uw v + v w w + ww

]T

body-axes velocity components plus wind, ybvel∗

Outputs x˙ = [ V˙ α˙ β˙ p˙ q˙ r˙ ψ˙ θ˙ ϕ˙ x˙ e y˙ e 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 definitions of GM1 and GM2 can be found in appendix C. These variables can be loaded from the file AIRCRAFT. DAT, using the utility DATLOAD (see section 12.4.2). If this datafile has somehow inadvertently been deleted, it can be re-created by 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.

8.2. The aircraft model block libraries

123 Beaver level 1 / Beaver level 2 / Additional Outputs / Accel

Accel

Main FDC library / Other (output-) equations

Type Aircraft-independent masked subsystem block, not essential for solving the equations of motion. Description The block Accel computes some accelerations and specific forces (outputs of accelerometers) in the aircraft’s center of gravity. These output variables are useful for several FCS design tasks, e.g. turn-coordination by means of feedback of the specific 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 vehicle’s 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 ˙ v, ˙ and w, ˙ which are kinematic accelerations differ from the body-axes velocity rates u, computed in the block uvwdot, because the latter do not contain the angular and translational velocity cross-product terms. • Outputs of body-axis accelerometers (specific forces) A x , Ay , and Az , measured at the vehicle’s 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 specific forces are also measured in units of g. Inputs Ftot Fgrav

= [ Fx Fy Fz ]T = [ Xgr Ygr Zgr ]T

Outputs yacc

= [ A x Ay Az a x,k ay,k az,k ]T

total external forces, Ftot gravity forces, Fgrav

specific 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 definition of GM1 can be found in appendix C. GM1 can be loaded from the file AIRCRAFT. DAT, using the utility DATLOAD (see section 12.4.2). If this datafile

124

Chapter 8. Aircraft model block reference

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.

8.2. The aircraft model block libraries

Additional Outputs

125 Beaver level 1 / Beaver level 2 / Additional Outputs Main FDC library / Other (output-) equations

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 fit 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

computes specific forces (outputs of accelerometers) and kinematic accelerations,

Flpath

computes some flight-path related variables,

uvwdot

computes the time-derivatives of the body-axes velocity components.

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˙ ψ˙ θ˙ ϕ˙ x˙ e y˙ e 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

flight-path variables, yfp time-derivatives of body-axes velocities, yuvw specific 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 file AIRCRAFT. DAT, using the utility DATLOAD (see section 12.4.2); its definition can be found in appendix C. If this datafile 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 file 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

Chapter 8. Aircraft model block reference

Connections in: x comes from the block Integrator; x˙ comes from xfix; yhlp comes from Hlpfcn; Ftot comes from FMsort; Fgrav comes from Gravity. out: yfp from Flightpath, yuvw from uvwdot, and yacc from Accel are not connected to any other block in the aircraft model. Type browse moreouts at the command-line for on-line help.

8.2. The aircraft model block libraries

127

Aerodynamics Group (Beaver)

Beaver level 1 / Level 2 / Aerodynamics Group (Beaver) Main FDC library / Aerodynamics

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 coefficients 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 coefficients 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 definitions 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 pb qc

rb T ydl = [ 2V V 2V ] dimensionless angular velocities, ydl T Caero = [ CXa CYa CZa Cla Cma Cna ] aerodynamic force and moment coefficients, Caero FMaero = [ Xa Ya Za L a Ma Na ] T dimensional aerodynamic forces and moments, FMaero

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 definitions of these variables can be found in appendix C. The variables can be loaded from the file AIRCRAFT. DAT, using the utility DATLOAD (see section 12.4.2). If this datafile has somehow inadvertently been deleted, it can be re-created by 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

Chapter 8. Aircraft model block reference

Aeromod (Beaver)

Beaver level 1 / Beaver level 2 / Aerodynamics Group / Aeromod (Beaver) Main FDC library / Aerodynamics

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 define 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 coefficients 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 influence of compressibility, as airspeed is assumed to be low [34]. The equations have been described in more detail in section 3.3.1.

• Coefficients of the aerodynamic forces and moments, measured in the body-fixed reference frame: qc CXa = CX0 + CXα α + CX 2 α2 + CX 3 α3 + CXq + CXδr δr + CXδ δ f + CXαδ αδ f α α f f V  ˙  rb βb pb CYa = CY0 + CYβ β + CYp + CYr + CYδa δa + CYδr δr + CYδr α δr α +CYβ˙ 2V 2V 2V qc CZa = CZ0 + CZα α + CZ 3 α3 + CZq + CZδe δe + CZ 2 δe β2 + CZδ δ f + CZαδ αδ f α δe β f f V rb pb + Clr + Clδa δa + Clδr δr + Clδa α δa α Cla = Cl0 + Clβ β + Cl p 2V 2V rb qc Cma = Cm0 + Cmα α + Cmα2 α2 + Cmq + Cmδe δe + Cm β2 β2 + Cmr + Cmδ δ f f V 2V pb rb qc Cna = Cn0 + Cn β β + Cn p + Cnr + Cnδa δa + Cnδr δr + Cnq + Cn β3 β3 2V 2V V The coefficients 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 coefficient CYa has not been taken into account in this block: the

8.2. The aircraft model block libraries

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

= [ V α β p q r ψ θ ϕ xe ye H ] T = [ δe δa δr δ f ]T pb qc rb T = [ 2V V 2V ]

Outputs Caero

= [ CXa CYa CZa Cla Cma Cna ]T

state vector, x aerodynamic control inputs, uaero dimensionless angular velocities, ydl

aerodynamic force and moment coefficients, Caero

Parameters The block Aeromod reads the parameter matrix AM from the M ATLAB workspace. AM contains the stability and control coefficients of the Beaver; see appendix C for its exact definition. This matrix can be loaded from the file AIRCRAFT. DAT, using the utility DATLOAD (see section 12.4.2). If this datafile has somehow inadvertently been deleted, it can be re-created by 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

Chapter 8. Aircraft model block reference

Aircraft Equations of Motion (Beaver)

Level 1 / Level 2 / Aircraft Equations of Motion Main FDC library / Equations of Motion

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

computes the body-axes velocity components as a function of the true airspeed, angle of attack, and sideslip angle,

xdotcorr

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

= [ Fx Fy Fz ]T = [ L M N ]T

total external forces, Ftot total external moments, Mtot

uwind

= [ uw vw ww u˙ w v˙ w w˙ w ]T

yatm

= [ ρ ps T µ g ] T

yhlp

= [ cos α sin α cos β sin β tan β sin ψ cos ψ sin θ cos θ sin ϕ cos ϕ ]T

wind velocity components along body-axes and their time-derivatives, uwind basic atmospheric properties, yatm

frequently used sines and cosines, yhlp

Outputs x x˙ ybvel

= [ V α β p q r ψ θ ϕ xe ye H ] T = [ V˙ α˙ β˙ p˙ q˙ r˙ ψ˙ θ˙ ϕ˙ x˙ e y˙ e 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 definitions of these variables can be found in appendix C. The variables

8.2. The aircraft model block libraries

131

can be loaded from the file AIRCRAFT. DAT, using the utility DATLOAD (see section 12.4.2). If this datafile has somehow inadvertently been deleted, it can be re-created by 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 file 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 aircraft model; x˙ from xfix 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

Chapter 8. Aircraft model block reference

Airdata1

Beaver level 1 / Beaver level 2 / Airdata Group / Airdata1 Main FDC library / Airdata, atmosphere

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 flying 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 m−2 ]: qdyn = 21 ρV 2

• Speed of sound a, [ms−1 ]: p a = γRT where γ = 1.4 is the ratio of specific heats of air with constant pressure and constant volume, respectively, and R = R a /M0 = 287.05 JK −1 kg−1 is the specific gas constant of the air (R a = 8314.32JK −1 kmol−1 is the molar gas constant, and M0 = 28.9644 kg kmol−1 is the molecular weight of the air at sea level).

• Mach number M, [ – ]: 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 defined 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.

8.2. The aircraft model block libraries

Airdata2

133 Beaver level 1 / Beaver level 2 / Airdata Group / Airdata2 Main FDC library / Airdata, atmosphere

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 flight 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 , [Nm−2 ]: ( )  γ γ − 1 2 γ −1 qc = ps 1+ −1 M 2 where γ = 1.4 is the ratio of specific heats of air with constant pressure and constant volume respectively.

• Calibrated airspeed Vc , [ms−1 ]: v   u  γ −1 u   γ qc u 2γ p0 Vc = t 1+ −1  γ − 1 ρ0  p0 where p0 = 101325 Nm−2 is the air pressure at sea level, and ρ0 = 1.225 kgm−3 is the air density at sea level. • Equivalent airspeed Ve , [ms−1 ]: s r ρ 2qdyn Ve = V = ρ0 ρ0 Inputs yatm yad1

= [ ρ ps T µ g ] T = [ a M qdyn ]T

Outputs yad2

= [ qc Ve Vc ]T

basic atmospheric properties, yatm basic airdata variables, yad1

additional airdata (-related) variables, yad2

Parameters All parameters for Airdata2 are defined 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

Chapter 8. Aircraft model block reference

Airdata3

Beaver level 1 / Beaver level 2 / Airdata Group / Airdata3 Main FDC library / Airdata, atmosphere

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 flight 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]:   γ−1 2 Tt = T 1 + M 2 • Reynolds number Rc , [ – ]: ρVc Rc = µ • Reynolds number per unit length Re , [m−1 ]: ρV Re = µ Inputs x yatm yad1

= [ V α β p q r ψ θ ϕ xe ye H ] T = [ ρ ps T µ g ] T = [ a M qdyn ]T

Outputs yad3

= [ 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 definition of GM1 can be found in appendix C. The variable can be loaded from the file AIRCRAFT. DAT, using the utility DATLOAD (see section 12.4.2). If this datafile has somehow inadvertently been deleted, it can 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.

8.2. The aircraft model block libraries

135 Beaver level 1 / Beaver level 2 / Airdata Group

Airdata Group

Main FDC library / Airdata, atmosphere

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,

Airdata1

computes the most important airdata variables which in general are required to solve the equations of motion of an aircraft,

Airdata2

computes additional airdata (-related) variables which may be useful for such purposes as comparing simulations with real flight experiments, windtunnel measurements, etc.,

Airdata3

computes some more additional airdata (-related) variables.

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

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

Outputs yatm yad1 yad2 yad3

= = = =

[ ρ 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 defined internally. Airdata3 reads the parameter vector GM1 from the M ATLAB workspace; its definition can be found in appendix C. GM1 can be loaded from the file AIRCRAFT. DAT, using the utility DATLOAD (see section 12.4.2). If this datafile has somehow 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

Chapter 8. Aircraft model block reference Beaver level 1 / Beaver level 2 / Airdata Group / Atmosph

Atmosph

Main FDC library / Airdata, atmosphere

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 Km−1 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 , [Nm−2 ]:  g T0 λR p s = p0 T where p0 = 101325 Nm−2 is the air pressure at sea level and R = R a /M0 = 287.05 JK −1 kg−1 is the specific gas constant of the air (R a = 8314.32JK −1 kmol−1 is the molar gas constant, and M0 = 28.9644 kg kmol−1 is the molecular weight of the air at sea level). • Air density ρ, [kgm−3 ], according to the gas law for ideal gasses: ps ρ= RT • Coefficient of the dynamic viscosity µ, [kg m−1 s−1 ], according to Sutherland’s equation [30]: 3

1.458 · 10−6 T 2 µ= T + 110.4

• Gravitational acceleration g, [ms−2 ]:  2 R Earth g = g0 R Earth + h where g0 = 9.80665 ms−2 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 flat-Earth model! This equation only takes into account the altitude-dependency of the gravitational acceleration.

8.2. The aircraft model block libraries

Inputs x

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

Outputs yatm

= [ ρ ps T µ g ] T

137

state vector, x

basic atmospheric properties, yatm

Parameters All parameters for Atmosph are defined 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

Chapter 8. Aircraft model block reference Beaver level 1 Main FDC library / Complete system Beaver

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 first level of the aircraft model (see figure 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 flavours: 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 first 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, flaps, 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 :

8.2. The aircraft model block libraries

uaero uprop

= [ δe δa δr δ f ]T = [ n pz ] T

uwind

= [ uw vw ww u˙ w v˙ w w˙ w ]T

139

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 definitions 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˙ ψ˙ θ˙ ϕ˙ x˙ e y˙ e 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 first 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 defined in the M ATLAB workspace. The definitions of these variables can be found in appendix C; they can be loaded from the file AIRCRAFT. DAT, using the utility DATLOAD (see section 12.4.2). If this datafile has somehow inadvertently been deleted, it can be re-created by 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 file, using TRILOAD (see section 12.4.2). Of course, it is also possible to manually enter xinco, if required. Furthermore, an optional vector xfix may be defined in the M ATLAB workspace, to artificially fix certain states to their initial values; see the description of the block xfix for an explanation. If xfix 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 xfix. If it is desired to artificially fix certain states, xfix 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 definitions.

140

Chapter 8. Aircraft model block reference

Beaver level 2

Beaver level 1 / Beaver level 2 Main FDC library / Complete system Beaver / 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 signifies that this is in fact the core module of the toolbox (the first 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 figure 3.2 from chapter 3. See figure 8.1 for a picture of Beaver Level 2 itself. Subsystems and/or blocks The subsystem Beaver level 2 contains five 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 aircraft’s 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 = [ uw vw ww u˙ w v˙ w w˙ w ]T

= = = = = = =

[ V α β p q r ψ θ ϕ xe ye H ] T [ V˙ α˙ β˙ p˙ q˙ r˙ ψ˙ θ˙ ϕ˙ x˙ e y˙ e H˙ ]T [ u v w ]T [ u˙ v˙ w˙ ]T pb qc rb T [ 2V V 2V ] [ γ fpa χ Φ ]T [ dpt P ]T

aerodynamic control inputs, uaero external propulsion inputs, uprop wind velocity components along body-axes and their time-derivatives, uwind

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 flight-path variables, yfp engine power related variables, ypow

8.2. The aircraft model block libraries

yacc Caero Cprop FMaero FMprop Fgrav Fwind yatm yad1 yad2 yad3

= = = = = = = = = = =

141

[ A x Ay Az a x,k ay,k az,k ]T specific forces and accelerations, yacc T aerodynamic force and moment coefficients, Caero [ CXa CYa CZa Cla Cma Cna ] T [ CX p CYp Cz p Cl p Cm p Cn p ] propulsive force and moment coefficients, 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 defined in the M ATLAB workspace. The following list provides an overview of the parameter requirements: AM

Aerodynamics Group (Beaver), Aircraft Equations of Motion (Beaver)

EM

Engine Group (Beaver)

GM1

Additional Outputs, Aerodynamics Group (Beaver), Aircraft Equations of Motion (Beaver), Airdata Group, Engine Group (Beaver), Fwind, Gravity

GM2

Aircraft Equations of Motion (Beaver)

xfix

Aircraft Equations of Motion (Beaver)

xinco

Aircraft Equations of Motion (Beaver)

The definitions for AM, EM, GM1, and GM2 can be found in appendix C. These variables can be loaded from the file AIRCRAFT. DAT, using the utility DATLOAD (see section 12.4.2). If this datafile has somehow inadvertently been deleted, it can be re-created by 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 file, using TRILOAD (see section 12.4.2). Of course, it is also possible to manually enter xinco, if required. The vector xfix is optional: if this variable is not present in the workspace when the aircraft model equations are evaluated, it will automatically be set to its default value ones(1,12) by the block xfix (which is contained in the subsystem Aircraft Equations of Motion (Beaver). If it is desired to artificially fix certain states, xfix 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

Chapter 8. Aircraft model block reference Beaver level 1 / Beaver level 2 / Aerodynamics Group / Dimless

Dimless

Main FDC library / Aerodynamics

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

state vector, x

Outputs ydl

= [

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 definition of GM1 can be found in appendix C. GM1 can be loaded from the file AIRCRAFT. DAT, using the utility DATLOAD (see section 12.4.2). If this datafile has somehow 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.

8.2. The aircraft model block libraries

Engine Group (Beaver)

143 Beaver level 1 / Beaver level 2 / Engine Group (Beaver) Main FDC library / Engine forces and moments

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: computes the power of the engine and the dimensionless increase in air pressure across the plane of the propeller,

Power

Engmod computes dimensionless force and moment coefficients which are caused by

the operation of the powerplant, including propeller slipstream effects, converts the dimensionless force and moment coefficients to dimensional forces and moments.

FMdims

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 coefficients, 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 definitions of these variables can be found in appendix C. The variables can be loaded from the file AIR CRAFT. DAT , using the utility DATLOAD (see section 12.4.2). If this datafile has 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

Chapter 8. Aircraft model block reference Beaver level 1 / Beaver level 2 / Engine Group / Engmod (Beaver)

Engmod (Beaver)

Main FDC library / Engine forces and moments

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 coefficients which are caused by the operation of the powerplant (this includes the engine thrust, gyroscopical effects caused by the rotating propeller, and the influence 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 coefficients 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 coefficients measured in the body-fixed reference frame: CX p = CXdpt dpt + CX

α dpt2

α dpt2

CYp = 0 CZ p = CZdpt dpt Cl p = Cl

α2 dpt

α2 dpt

Cm p = Cmdpt dpt Cn p = Cn

dpt3

dpt3

The coefficients 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: h

dpt dpt3 α · dpt2 dpt · α2

iT

with the constant parameter matrix EM in which the engine stability and control derivatives of the Beaver are contained. Inputs x ypow

= [ V α β p q r ψ θ ϕ xe ye H ] T = [ dpt P ]T

engine power related variables, ypow

Outputs Cprop

= [ CX p CYp Cz p Cl p Cm p Cn p ]T

propulsive force and moment coefficients, Cprop

state vector, x

8.2. The aircraft model block libraries

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 coefficients of the engine forces and moments model. The definition of this matrix can be found in appendix C. EM can be loaded from the file AIRCRAFT. DAT , using the utility DATLOAD (see section 12.4.2). If this datafile has somehow inadvertently been deleted, it can be re-created by running the 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

Chapter 8. Aircraft model block reference Beaver level 1 / Beaver level 2 / Aircraft Equations of Motion / 12 ODEs / Eulerdot

Eulerdot

Main FDC library / Equations of motion

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 s−1 ]: q sin ϕ + r cos ϕ ψ˙ = cos θ θ˙ = q cos ϕ − r sin ϕ ϕ˙ = p + ψ˙ sin θ Inputs ueul

= [ x T Ftot T Mtot T yhlp T ]T

input vector to Eulerdot, ueul

where: x Ftot Mtot yhlp

= = = =

[ 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 frequently used sines and cosines, yhlp

Outputs yeul

= [ ψ˙ θ˙ ϕ˙ ]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.

8.2. The aircraft model block libraries

147 Beaver level 1 / Beaver level 2 / Additional Outputs / Flpath

Flpath

Main FDC library / Other (output-) equations

Type Aircraft-independent masked subsystem block, not essential for solving the equations of motion. Description The block Flpath is used to compute some flight-path (-related) variables. These output variables are useful for flight 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 ms−1 the gravitational acceleration at sea level. • Azimuth angle χ, [rad]: χ = β+ψ

• Bank angle Φ, [rad]: Φ = arcsin sin ϕ cos θ Inputs x x˙ yhlp




= [ V α β p q r ψ θ ϕ xe ye H ] T state vector, x T ˙ ˙ ˙ ˙ ˙ = [ V α˙ β p˙ q˙ r˙ ψ θ ϕ˙ x˙ e y˙ e H ] time-derivative of state vector, xdot = [ cos α sin α cos β sin β tan β sin ψ cos ψ sin θ cos θ sin ϕ cos ϕ ]T frequently used sines and cosines, yhlp

Outputs yfp

= [ γ fpa χ Φ ]T

flight-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 xfix; yhlp comes from the block Hlpfcn. out: yfp is not used by any other block from the aircraft model. Type browse flpath at the command-line for on-line help.

148

Chapter 8. Aircraft model block reference

FMdims

Beaver level 1 / Beaver level 2 / Aerodynamics Group or Engine Group / FMdims Main FDC library / Aerodynamics or Engine forces and moments

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 coefficients as determined by the aerodynamic model Aeromod (Beaver) and the propulsion model Engmod (Beaver). It should be noted that the relation between the dimensionless coefficients 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 definitions. 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

aerodynamic force and moment coefficients, Caero

= [ CX p CYp Cz p Cl p Cm p Cn p ]T

propulsive force and moment coefficients, Cprop

Outputs FMaero = [ Xa Ya Za L a Ma Na ] T or: FMprop = [ X p Yp Z p L p M p Np ] T

basic airdata variables, yad1

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 definition of GM1. This vector can be loaded from the file AIRCRAFT. DAT, using the utility DATLOAD (see section 12.4.2). If this datafile has somehow 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).

8.2. The aircraft model block libraries

out: FMaero or FMprop are connected to FMsort. Type browse fmdims at the command-line for on-line help.

149

150

Chapter 8. Aircraft model block reference Beaver level 1 / Beaver level 2 / FMsort

FMsort

Main FDC library / Other (output-) equations

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

= [ Fx Fy Fz ]T = [ L M N ]T

[ 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

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.

8.2. The aircraft model block libraries

151 Beaver level 1 / Beaver level 2 / Fwind

Fwind

Main FDC library / Gravity and wind forces

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 aircraft’s body-axes when considering flight in nonsteady atmosphere. These correction terms depend upon the components of the wind velocity vector Vw along the aircraft’s 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 (u˙ w + qww − rvw ) Yw = −m (v˙ w − pww + ruw ) Zw = −m (w˙ w + pvw − quw ) Inputs x uwind Outputs Fwind

= [ V α β p q r ψ θ ϕ xe ye H ] T = [ uw vw ww u˙ w v˙ w w˙ w

= [ Xw Yw Zw ]T

]T

state vector, x body-axes components of the wind velocity, and their time-derivatives, uwind

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 definition of this vector can be found in appendix C. GM1 can be loaded from the file AIRCRAFT. DAT , using the utility DATLOAD (see section 12.4.2). If this datafile has somehow 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

Chapter 8. Aircraft model block reference Beaver level 1 / Beaver level 2 / Gravity

Gravity

Main FDC library / Gravity and wind forces

Type Aircraft-independent masked subsystem block, essential for solving the equations of motion. Description The block Gravity computes the resolution of the aircraft’s 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 aircraft’s weight to the body-axes force components, [N]: Xgr = − W sin θ Ygr = W cos θ sin ϕ Zgr = W cos θ cos ϕ where W = mg is the weight of the aircraft, measured in [N]. Inputs x yatm

= [ V α β p q r ψ θ ϕ xe ye H ] T = [ ρ ps T µ g ] T

Outputs Fgrav

= [ 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 definition of GM1 can be found in appendix C. GM1 can be loaded from the file AIRCRAFT. DAT, using the utility DATLOAD (see section 12.4.2). If this datafile has somehow 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.

8.2. The aircraft model block libraries

153 Beaver level 1 / Beaver level 2 / Hlpfcn

Hlpfcn

Main FDC library / Other (output-) equations

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

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

Outputs yhlp

= [ cos α sin α cos β sin β tan β sin ψ cos ψ sin θ cos θ sin ϕ cos ϕ ]T

state vector, x

frequently used sines and cosines, yhlp

(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

Chapter 8. Aircraft model block reference Beaver level 1 / Beaver level 2 / Aircraft Equations of Motion / Integrator

Integrator

Main FDC library / Equations of motion

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 defined 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 ) +

Z 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˙

= [ V˙ α˙ β˙ p˙ q˙ r˙ ψ˙ θ˙ ϕ˙ x˙ e y˙ e H˙ ]T

time-derivative of state vector, xdot

Outputs x

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

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 file, 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.

8.2. The aircraft model block libraries

Power (Beaver)

155 Beaver level 1 / Beaver level 2 / Engine Group / Power (Beaver) Main FDC library / Engine forces and moments

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, [–]: ! ∆pt P dpt = 1 = C1 + C2 1 2 3 2 ρV 2 ρV with

P

1 ρV 3 2

measured in [kW kg−1 s3 ], and: C1 = 0.08696, C2 = 191.18, see ref.[34].

• Engine power P, [Nm s−1 ]:     ρ P = 0.7355 −326.5 + 0.00412( pz + 7.4)(n + 2010) + (408.0 − 0.0965n) 1.0 − ρ0

Inputs x uprop yatm

= [ V α β p q r ψ θ ϕ xe ye H ] T = [ n pz ] T = [ ρ ps T µ g ] T

Outputs ypow

= [ 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 defined 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

Chapter 8. Aircraft model block reference Beaver level 1 / Beaver level 2 / Aircraft Equations of Motion / 12 ODEs / pqrdot

pqrdot

Main FDC library / Equations of motion

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 s−2 ]: 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 coefficients Ppp , Ppq , Ppr , ... , Rm , and Rn are inertia coefficients, see the definition in table 2.2. Inputs upqr

= [ x T Ftot T Mtot T yhlp T ]T

input vector to pqrdot, pqr

where: x Ftot Mtot yhlp

= = = =

[ 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

Outputs ypqr

= [ p˙ q˙ r˙ ]T

time-derivatives of the angular velocities ˙ around the body-axes, ypqr (part of x)

Parameters The block pqrdot needs the parameter matrix GM2 to be present the M ATLAB workspace, in order to extract the inertia coefficients (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 definition of this matrix can be found in appendix C. GM2 can be loaded from the file AIRCRAFT. DAT, using the utility DATLOAD (see section 12.4.2). If this datafile has somehow inadvertently been deleted, it can be re-created by 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.

8.2. The aircraft model block libraries

157

Beaver level 1 / Beaver level 2 / Aircraft Equations of Motion / uvw

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, [ms−1 ]: u = V cos α cos β

• Velocity component v, directed along the YB -axis, [ms−1 ]: v = V sin β

• Velocity component w, directed along the ZB -axis, [ms−1 ]: w = V sin α cos β Inputs x yhlp

= [ V α β p q r ψ θ ϕ xe ye H ] T = [ cos α sin α cos β sin β tan β sin ψ cos ψ sin θ cos θ sin ϕ cos ϕ ]T

state vector, x

frequently used sines and cosines, yhlp

Outputs ybvel

= [ 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

Chapter 8. Aircraft model block reference Beaver level 1 / Beaver level 2 / Additional Outputs / uvwdot

uvwdot

Main FDC library / Other (output-) equations

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, [ms−2 ]: u˙ = V˙ cos α cos β − V (α˙ sin α cos β + β˙ cos α sin β) • Time-derivative of the velocity component along the YB -axis, [ms−2 ]: v˙ = V˙ sin β + V β˙ cos β • Time-derivative of the velocity component along the ZB -axis, [ms−2 ]: w˙ = V˙ sin α cos β + V (α˙ cos α cos β − β˙ sin α sin β) Inputs x x˙ yhlp

= [ V α β p q r ψ θ ϕ xe ye H ] T state vector, x = [ V˙ α˙ β˙ p˙ q˙ r˙ ψ˙ θ˙ ϕ˙ x˙ e y˙ e H˙ ]T time-derivative of state vector, xdot = [ cos α sin α cos β sin β tan β sin ψ cos ψ sin θ cos θ sin ϕ cos ϕ ]T frequently used sines and cosines, yhlp

Outputs yuvw

= [ 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 xfix; yhlp comes from the block Hlpfcn. out: yuvw is not used by any other block from the aircraft model. Type browse uvwdot at the command-line for on-line help.

8.2. The aircraft model block libraries

159

Beaver level 1 / Beaver level 2 / Aircraft Equations of Motion / 12 ODEs / Vabdot

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, [ms−2 ]: 1 V˙ = ( Fx cos α cos β + Fy sin β + Fz sin α cos β) m • Time-derivative of the angle of attack α, [rad s−1 ]:   1 1 α˙ = (− Fx sin α + Fz cos α) + q − ( p cos α + r sin α) tan β V cos β m • Time-derivative of the sideslip angle β, [rad s−1 ]:   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

= = = =

[ 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

Outputs yVab

= [ V˙ α˙ β˙ ]T

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 definition of GM1 can be found in appendix C. GM1 can be loaded from the file AIRCRAFT. DAT, using the utility DATLOAD (see section 12.4.2). If this datafile has somehow 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

Chapter 8. Aircraft model block reference

xdotcorr (Beaver)

Beaver level 1 / Beaver level 2 / Aircraft Equations of Motion / xdotcorr (Beaver) Main FDC library / Equations of motion

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˙ To avoid this from renamic component of the sideforce itself is directly dependent on β). sulting 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 suffix ‘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. artificially 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 − Fx cos α sin β + Fy ∗ cos β − Fz sin α sin β + 21 ρV 2 S CYβ˙ 2V cos β + Vm

+ p sin α − r cos α ˙ The β-term ˙ where Fy ∗ is the side-force without the contribution of β. on the right-hand side of this equation can easily be moved to the left-hand side:   ˙β∗ ≡ β˙ 1 − ρSb CY cos β = β˙ 4m
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   −1 ρSb 3. compute the actual value of β˙ using the expression β˙ = β˙ ∗ 1 − 4m CYβ˙ cos β (xdotcorr).

8.2. The aircraft model block libraries

Inputs x˙ yhlp

161

= [ V˙ α˙ β˙ p˙ q˙ r˙ ψ˙ θ˙ ϕ˙ x˙ e y˙ e H˙ ]T uncorrected time-derivative of state vector, xdot = [ cos α sin α cos β sin β tan β sin ψ cos ψ sin θ cos θ sin ϕ cos ϕ ]T frequently used sines and cosines, yhlp

yatm Outputs x˙

= [ ρ ps T µ g ] T = [ V˙ α˙ β˙ p˙ q˙ r˙ ψ˙ θ˙ ϕ˙ x˙ e y˙ e H˙ ]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 definition of AM and GM1 can be found in appendix C. Both variables can be loaded from the file AIRCRAFT. DAT, using the utility DATLOAD (see section 12.4.2). If this datafile has somehow inadvertently been deleted, it can be re-created by 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. ˙ is connected to the block xfix. out: x˙ (with a corrected value of β) Type browse xdotcorr at the command-line for on-line help.

162

Chapter 8. Aircraft model block reference Beaver level 1 / Beaver level 2 / Aircraft Equations of Motion / xfix

xfix

Main FDC library / Equations of motion

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 artificially fix 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 artificially 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 artificially neglected. The block xfix can be used to force state variables from the aircraft model to remain fixed 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 first situation, the computed time-derivative is used, in the second situation, the time-derivative is artificially set to zero, causing the corresponding state variable to stay constant. Equations The block xfix modifies the time-derivative of the state vector by performing an elementby-element multiplication (in the equation below denoted with the symbol ?) with the vector xfix. 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.

• Modified time-derivative of the state vector:     V˙ xfix(1)  α˙   xfix(2)       β˙   xfix(3)        p˙   ..     .   q˙        ..   r˙   0 .     where: xfix(i) = x˙ new = x˙ old ? xfix =  ˙  ?   ψ 1 ..       θ˙   .     ..   ϕ˙       .   x˙ e       ..   y˙ e   . xfix(12) H˙

i ∈ {1, 2, . . . , 12}

Inputs x˙ old

= [ V˙ α˙ β˙ p˙ q˙ r˙ ψ˙ θ˙ ϕ˙ x˙ e y˙ e H˙ ]T

unmodified time-derivative of state vector, xdot

Outputs x˙ new

= [ V˙ α˙ β˙ p˙ q˙ r˙ ψ˙ θ˙ ϕ˙ x˙ e y˙ e H˙ ]T

modified time-derivative of state vector, xdot

Parameters The block xfix tries to read the multiplication vector xfix from in the M ATLAB workspace. If the variable xfix 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 artificially fix specific states, xfix should either be entered

8.2. The aircraft model block libraries

163

manually (it must be a vector of length 12, with all elements being either one or zero), or be defined by running the utility FIXSTATE (see section 12.6.2). Connections in: the unmodified vector x˙ comes from the block xdotcorr (Beaver). ˙ whose elements may have been artificially set to zero, is out: the modified vector x, 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

Chapter 8. Aircraft model block reference Beaver level 1 / Beaver level 2 / Aircraft Equations of Motion / 12 ODEs / xyHdot

xyHdot

Main FDC library / Equations of motion

Type Aircraft-independent masked subsystem block, contains three (out of twelve) state equations. Description The block xyHdot computes the time-derivatives of the aircraft’s X and Y-coordinates xe and ye , measured with respect to the Earth-fixed 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 , [ms−1 ]: x˙ e = {ue cos θ + (ve sin ϕ + we cos ϕ) sin θ } cos ψ − (ve cos ϕ − we sin ϕ) sin ψ

• Time-derivative of the Y-coordinate ye , [ms−1 ]: y˙ e = {ue cos θ + (ve sin ϕ + we cos ϕ) sin θ } sin ψ + (ve cos ϕ − we sin ϕ) cos ψ

• Rate of climb or descent, [ms−1 ]: H˙ = −z˙ e = ue sin θ − (ve sin ϕ + we cos ϕ) cos θ Inputs ybvel ∗ uxyH

= [ 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

where: x Ftot Mtot yhlp

= = = =

[ 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 frequently used sines and cosines, yhlp

Outputs yxyH

= [ x˙ e y˙ e 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 figure 9.1. This library can be accessed from the main FDC library (shown in figure 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 figures 9.2 and 9.3.

Figure 9.1: Wind and turbulence library WINDLIB

166

Chapter 9. Wind and turbulence block reference

Figure 9.2: Sublibrary with wind-models

Figure 9.3: Sublibrary with turbulence models

The remainder of this chapter (pages 167 to 177) provides detailed 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

BLwind

167

Main FDC library / Wind and turbulence / Wind models / BLwind Wind and turbulence library / Wind models / BLwind

Type Masked subsystem block. Description The block BLwind calculates components of the wind velocity along the aircraft’s 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 defined 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], [ms−1 ]: H 0.2545 − 0.4097 1.3470 Vw = 2.86585 Vw9.15

Vw = Vw 9.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, [ms−1 ]: Vwhor = Vw · cos γw Vwvert ≡ ww = −Vw · sin γw where γw is the ‘vertical wind direction angle’, i.e. the angle between the wind vector and the horizontal plane. • Horizontal components of the wind velocity, aligned along the Earth-fixed reference frame, [ms−1 ]: uw = Vwhor · cos(ψw − π ) vw = Vwhor · sin(ψw − π ) where ψw is the ‘horizontal wind direction angle’, i.e. the direction from where the 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, [ms−1 ]: 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 defined 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 definition 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

Chapter 9. Wind and turbulence block reference

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 aircraft’s body-axes, [uw,vw,ww]’

Parameters BLwind does not require any workspace parameters to be specified. 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 flight-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.

9.1. The wind and turbulence blocklibrary

169

Main FDC library / Wind and turbulence / Wind models / Cwind

Cwind

Wind and turbulence library / Wind models / Cwind

Type Masked subsystem block. Description The block Cwind calculates components of the wind velocity along the aircraft’s 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, [ms−1 ]: Vwhor = Vw · cos γw Vwvert ≡ ww = −Vw · sin γw where γw is the ‘vertical wind direction angle’, i.e. the angle between the wind vector and the horizontal plane. • Horizontal components of the wind velocity, aligned along the Earth-fixed reference frame, [ms−1 ]: uw = Vwhor · cos(ψw − π ) vw = Vwhor · sin(ψw − π ) where ψw is the ‘horizontal wind direction angle’, i.e. the direction from where the 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, [ms−1 ]: 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 aircraft’s body-axes, [uw,vw,ww]’

Parameters Cwind does not require any workspace parameters to be specified. 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 flight-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

Chapter 9. Wind and turbulence block reference

Turbulence Group 1

Main library / Wind & turbulence / Atmosph. turb. models / Turbulence Group 1 Wind and turbulence library / Atmospheric turbulence models / 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 filters with constant coefficients. The user must specify the mean airspeed, scale length, and standard deviation in each of the Dryden filters from this subsystem (longitudinal, lateral, and vertical). Variations of the filter coefficients with the airspeed are neglected, as the influence 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

generates the turbulence velocity component along the XB -axis of the aircraft (‘longitudinal turbulence’), and its time-derivative,

VDRYD1

generates the turbulence velocity component along the YB -axis of the aircraft (‘lateral turbulence’), and its time-derivative,

WDRYD1

generates the turbulence velocity component along the ZB -axis of the aircraft (‘vertical turbulence’), and its time-derivative.

Inputs None. Outputs uwind

= [ u g v g w g u˙ g v˙ g w˙ g ]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 specified. 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 define 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 first, before entering the aircraft model. Type browse turb1 at the command-line for on-line help.

9.1. The wind and turbulence blocklibrary

Turbulence Group 2

171

Main library / Wind & turbulence / Atmosph. turb. models / Turbulence Group 2 Wind and turbulence library / Atmospheric turbulence models / Turbulence Group 2

Type Non-masked subsystem. 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 filters with airspeed-dependent coefficients. The user must specify the scale length and standard deviation in each of the Dryden filters from this subsystem (longitudinal, lateral, and vertical). Variations of the filter coefficients are computed ‘on-the-fly’, as a function of the airspeed. Since the resulting variations in filter characteristics are usually relatively small, the turbulence library also offers a simplified subsystem Turbulence Group 1, which uses constant filter coefficients. Subsystems and/or blocks The subsystem Turbulence Group 2 contains three blocks: UDRYD2

generates the turbulence velocity component along the XB -axis of the aircraft (‘longitudinal turbulence’), and its time-derivative,

VDRYD2

generates the turbulence velocity component along the YB -axis of the aircraft (‘lateral turbulence’), and its time-derivative,

WDRYD2

generates the turbulence velocity component along the ZB -axis of the aircraft (‘vertical turbulence’), and its time-derivative.

Inputs V Outputs uwind

true airspeed of the aircraft, V

= [ u g v g w g u˙ g v˙ g w˙ g ]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 specified. 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 define 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 first, before entering the aircraft model. Type browse turb2 at the command-line for on-line help.

172

Chapter 9. Wind and turbulence block reference

UDRYD1

Main FDC library / Wind and turbulence / Atmospheric turbulence models / UDRYD1 Wind and turbulence library / Atmospheric turbulence models / 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 filter with constant coefficients. 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 filter coefficients with the airspeed, as the influence 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, [ms−1 ]: 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 filter.

• Transfer function of the longitudinal turbulence filter: r 2Lu g 1 Hu g w1 (s) = σu g V 1 + Lu g s V

Note: the value of the airspeed V, used by UDRYD1, is kept constant during simulations. This value must be specified by the user; obviously, the most realistic result is 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 u˙ g

longitudinal turbulence velocity, ug time-derivative of longitudinal turbulence velocity, ug dot

Parameters UDRYD1 does not require any workspace parameters to be specified. The user must spec-

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.

9.1. The wind and turbulence blocklibrary

UDRYD2

173

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 filter with coefficients 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 filter coefficients of UDRYD2 are computed ‘on-the-fly’, as a function of the airspeed. Since the resulting variations in filter characteristics are usually relatively small, the turbulence library also offers the simplified block UDRYD1, which uses constant filter coefficients. Equations For a detailed discussion of the equations from the block UDRYD2 and the underlying theory, refer to section 4.2.

• Longitudinal turbulence velocity, [ms−1 ]: 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 filter.

• Transfer function of the longitudinal turbulence filter: r 2Lu g 1 Hu g w1 (s) = σu g V 1 + Lu g s V

Note: the filter coefficients are computed ‘on-the-fly’, 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 u˙ g

true airspeed of the aircraft, V longitudinal turbulence velocity, ug time-derivative of longitudinal turbulence velocity, ug dot

Parameters UDRYD2 does not require any workspace parameters to be specified. The user must

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

Chapter 9. Wind and turbulence block reference

VDRYD1

Main FDC library / Wind and turbulence / Atmospheric turbulence models / VDRYD1 Wind and turbulence library / Atmospheric turbulence models / 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 filter with constant coefficients. 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 filter coefficients with the airspeed, as the influence 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, [ms−1 ]: 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 filter.

• Transfer function of the lateral turbulence filter: r √ L 2Lv g 1 + 3 Vvg 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 specified 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 v˙ g

lateral turbulence velocity, vg time-derivative of lateral turbulence velocity, vg dot

Parameters VDRYD1 does not require any workspace parameters to be specified. The user must spec-

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.

9.1. The wind and turbulence blocklibrary

VDRYD2

175

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 filter with coefficients 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 filter coefficients of VDRYD2 are computed ‘on-the-fly’, as a function of the airspeed. Since the resulting variations in filter characteristics are usually relatively small, the turbulence library also offers the simplified block VDRYD1, which uses constant filter coefficients. Equations For a detailed discussion of the equations from the block VDRYD2 and the underlying theory, refer to section 4.2.

• Lateral turbulence velocity, [ms−1 ]: 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 filter.

• Transfer function of the lateral turbulence filter: r √ L 2Lv g 1 + 3 Vvg s Hv g w2 (s) = σv g 2 Lv V  1 + Vg s Note: the filter coefficients are computed ‘on-the-fly’, 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 v˙ g

true airspeed of the aircraft, V lateral turbulence velocity, vg time-derivative of lateral turbulence velocity, vg dot

Parameters VDRYD2 does not require any workspace parameters to be specified. The user must spec-

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

Chapter 9. Wind and turbulence block reference

WDRYD1

Main FDC library / Wind and turbulence / Atmospheric turbulence models / WDRYD1 Wind and turbulence library / Atmospheric turbulence models / 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 filter with constant coefficients. 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 filter coefficients with the airspeed, as the influence 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, [ms−1 ]: 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 filter.

• Transfer function of the vertical turbulence filter: r √ L 2Lwg 1 + 3 Vwg 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 specified 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 w˙ g

vertical turbulence velocity, wg time-derivative of vertical turbulence velocity, wg dot

Parameters WDRYD1 does not require any workspace parameters to be specified. The user must

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.

9.1. The wind and turbulence blocklibrary

WDRYD2

177

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 filter with coefficients that will vary with airspeed. The user must specify the lateral scale-length of the turbulence Lwg and the standard deviation σwg , but the filter coefficients of WDRYD2 are computed ‘on-the-fly’, as a function of the airspeed. Since the resulting variations in filter characteristics are usually relatively small, the turbulence library also offers the simplified block WDRYD1, which uses constant filter coefficients. Equations For a detailed discussion of the equations from the block WDRYD2 and the underlying theory, refer to section 4.2.

• Vertical turbulence velocity, [ms−1 ]: 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 filter.

• Transfer function of the vertical turbulence filter: r √ L 2Lwg 1 + 3 Vwg s Hwg w3 (s) = σwg 2 Lw V  1 + Vg s Note: the filter coefficients are computed ‘on-the-fly’, 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 w˙ g

true airspeed of the aircraft, V vertical turbulence velocity, wg time-derivative of vertical turbulence velocity, wg dot

Parameters WDRYD2 does not require any workspace parameters to be specified. The user must

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 figure 10.1. It can be accessed from the main FDC library (shown in figure 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 figures 10.2 and 10.3.

Figure 10.1: Radio-navigation library NAVLIB

180

Chapter 10. Radio-navigation block reference

Figure 10.2: Sublibrary with ILS models

Figure 10.3: Sublibrary with VOR models

The remainder of this chapter (pages 181 to 192) provides detailed 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

GSerr

181 Main FDC library / ILS/VOR radio-nav / ILS signals / GSerr Radio-navigation library / ILS signals / GSerr

Type Masked subsystem block. 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 figure 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

Chapter 10. Radio-navigation block reference Main FDC library / ILS/VOR radio-nav / ILS signals / GSnoise1 (2)

GSnoise1 (2)

Radio-navigation library / ILS signals / 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∗gs (s) = Hgs (s) w4 (s) where ∆i∗gs is the glideslope noise, w4 is a white noise signal, generated internally within the block GSnoise1 or GSnoise2, and Hgs is the transfer function of the glideslope noise filter. • Transfer function of the glideslope noise filter according to AGARD R-632, used for GSnoise1: r 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 (final) 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 filter 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) doesn’t require any parameters to be entered. Connections in: no connections. out: ∆i∗gs is meant to be added to the original glideslope current i gs . If steady-state errors are also taken into account, this summation must take place after sending the glideslope current through the block GSerr first. 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.

10.1. The radio-navigation blocklibrary

183 Main FDC library / ILS/VOR radio-nav / ILS signals / ILS

ILS

Radio-navigation library / ILS signals / ILS

Type Masked subsystem block. 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 verified 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-fixed 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]: q R gs = ( x gs − x f )2 + (y f − y gs )2 q Rloc = y f 2 + ( xloc − x f )2 • Two flags, 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 figures 5.5 and 5.3 in chapter 5. These flags are called GS_flag and LOC_flag, respectively; they are set equal to 1 if the signals are reliable, and 0 if they are not. These flags 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

Chapter 10. Radio-navigation block reference

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_flag LOC_flag ]T

nominal currents through ILS indicators, yils1 angles between nominal and current ILS planes, yils2 distances defining the aircraft’s approach position, yils3 flags defining the validity of the ILS signals, yils4

Parameters The following parameters can be defined 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-fixed 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 figure 5.1), • the distance x gs from the threshold to the position on the runway centerline that is perpendicular to the glideslope antenna (see figure 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 figure 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.

10.1. The radio-navigation blocklibrary

185

Main FDC library / ILS/VOR radio-nav / ILS signals / ILS example

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 modified 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 five masked subsystem blocks: ILS

computes the nominal ILS signals,

GSerr

incorporates a steady-state error in the glideslope signal,

GSnoise1

computes glideslope noise,

LOCerr

incorporates a steady-state error in the localizer signal,

LOCnoise1 computes localizer noise.

The disturbance models used in ILS example are all based upon ref.[1]. If you want 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

state vector from the aircraft model, x

glideslope deviation angle, including system offset and noise, epsilon_gs

Γloc

localizer deviation angle, including system offset and noise, Gamma_loc

During simulations, the time-trajectories of the nominal ILS signals (excluding ILS 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_flag LOC_flag ]T

nominal currents through ILS indicators, yils1 angles between nominal and current ILS planes, yils2 distances defining the aircraft’s approach position, yils3 flags defining the validity of the ILS signals, yils4

The flags in yils4 provide information about the validity of the ILS signals, based on the

186

Chapter 10. Radio-navigation block reference

ILS coverage depicted in figures 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-fixed 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 define 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 definition of a scale length, the standard deviation of the noise, and the final approach speed of the airplane. And finally, the multiplication factors 1/Kgs and 1/Kloc require the definition of the nominal glideslope angle and the distance from the threshold to the localizer antenna. Note: some parameters have to be defined multiple times in different blocks within 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 modified 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.

10.1. The radio-navigation blocklibrary

187 Main FDC library / ILS/VOR radio-nav / ILS signals / LOCerr

LOCerr

Radio-navigation library / ILS signals / LOCerr

Type Masked subsystem block. 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 figure 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

Chapter 10. Radio-navigation block reference

LOCnoise1 (2)

Main FDC library / ILS/VOR radio-nav / ILS signals / LOCnoise1 (2) Radio-navigation library / ILS signals / 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) ∗ is the localizer noise, w is a white noise signal, generated internally within where ∆iloc 5 the block LOCnoise1 or LOCnoise2, and Hloc is the transfer function of the localizer noise filter. • Transfer function of the localizer noise filter according to AGARD R-632, used for LOCnoise1: r 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 (final) 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 filter 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) doesn’t require any parameters to be entered. Connections in: no connections. ∗ is meant to be added to the original localizer current i . If steady-state errors out: ∆iloc loc are also taken into account, this summation must take place after sending the localizer current through the block LOCerr first. 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.

10.1. The radio-navigation blocklibrary

189 Main FDC library / ILS/VOR radio-nav / VOR signals / VOR

VOR

Radio-navigation library / VOR signals / VOR

Type Masked subsystem block. Description The block VOR computes the nominal VOR signals that will be received on board the aircraft if it flies at a certain position relatively to the VOR ground station. In addition, it computes the ground-distance to the VOR antenna, warning flags which alert the user if the aircraft flies outside the VOR range, and a flag 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]:   ye − yVOR QDR = arctan xe − xVOR • Deviation from the desired VOR bearing, [rad]: ΓVOR = CD − QDR

• Ground-distance from the aircraft to the VOR station, [m]: q RVOR = ( xe − xVOR )2 + (ye − yVOR )2 • A Cone of Silence flag (‘C.O.S.-flag’) is set equal to 1 if the airplane flies inside the Cone of Silence region, i.e. if:   H − HVOR > 90◦ − (40◦ to 60◦ ) arctan RVOR In practice, the smallest cone-size has been used; this corresponds to an opening angle of 2 ∗ 40◦ . See figure 5.12 in chapter 5 for more details. • A Range flag is set to 1 if the aircraft flies outside the area where the VOR signals can reliably be received, i.e. if: RVOR > Range where:   Range = 1000 −2.3570 · 10−6 ( H − HVOR )2 + 5.7087 · 10−2 ( H − HVOR ) + 80.8612

• A To/From flag is set to 1 if the aircraft is heading towards the VOR station, i.e. if: |ψ − QDR| > 90◦ Inputs uvor ψ

= [ xe ye H ] T

Outputs yvor1 = ΓVOR yvor2 = RVOR yvor3 = [ C.O.S.-flag Range-flag ]T yvor4 = ToFrom

aircraft coordinates and altitude, uvor heading of the aircraft, psi

nominal VOR bearing, excluding system offset, yvor1 ground distance from aircraft to VOR station, yvor2 flags specifying validity of VOR signals, yvor3 To/From flag, 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

Chapter 10. Radio-navigation block reference

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.

10.1. The radio-navigation blocklibrary

191 Main FDC library / ILS/VOR radio-nav / VOR signals / VORerr

VORerr

Radio-navigation library / VOR signals / VORerr

Type Masked subsystem block. 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 beare ing. It is equal to 1 + 100 with e the overall percentile VOR system error, specified 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 figure 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

Chapter 10. Radio-navigation block reference

VOR example

Main FDC library / ILS/VOR radio-nav / VOR signals / VOR example Radio-navigation library / VOR signals / 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 modified 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

computes the nominal VOR signal,

VORerr

incorporates a steady-state error in the VOR signal.

Inputs x = [ V α β p q r ψ θ ϕ xe ye H ] T Outputs ΓVOR

state vector from the aircraft model, x

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 defined as: yvor = [ yvor1 yvor2 yvor3 T yvor4 ] T with: yvor1 yvor2 yvor3 yvor4

= = = =

ΓVOR RVOR [ C.O.S.-flag Range-flag ]T ToFrom

nominal VOR bearing, excluding system offset, yvor1 ground distance from aircraft to VOR station, yvor2 flags specifying validity of VOR signals, yvor3 To/From flag, 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 flag, 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.

10.1. The radio-navigation blocklibrary

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 modified 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-specific functions help with the definition 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 five 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 datafiles in general. DATLOAD, LINLOAD, MATLOAD, and TRILOAD apply this utility to retrieve datafiles with extensions . DAT, . LIN, . MAT, and . TRI, respectively.

208

Chapter 12. Support functions reference

4. Generic helper functions BROWSE displays HTML helpfiles 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-specific helper functions MODBUILD is used to generate the datafile AIRCRAFT. DAT, which contains the aircraft model parameters. FIXSTATE can be used to initialize the xfix 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 first call FDC_SPLASH, which displays the splash-screen from figure 7.2, and next FDCINIT, which manages the list of FDC directories and appends them to the M ATLAB search path (figures 7.3 to 7.5). Finally, the welcome message from figure 7.6 will be shown to indicate that the software is ready. The source file 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 modifications 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 first.

12.2. Toolbox initialisation functions

$FDCROOT$

209

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 helpfiles. 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 modified 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 confirms the directory definitions. The confirmed list will be stored in the file FDC . INI in the directory PROGRAMS (the location that also holds the file FDCINIT. M). Each next time FDCINIT is started, it will use the list from FDC . INI instead of the default list from figure 12.1. The default list will be used if the file FDC . INI cannot be found; deleting this file makes FDCINIT behave as if it was run for the first time.

210

Chapter 12. Support functions reference

Notice that FDCINIT will not verify if specified directories actually exist. Therefore, if the user uses the options to add, remove, or rename (sub-) directories, a 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 flexibility, the mandatory directory verification during initialisation may become rather inconvenient if you don’t 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 modification options afterward, it is necessary to delete the file FDC . INI. Figure 7.5 shows the directory verification process and the ‘suppress’ option in action.

12.2.3

FDC_SPLASH

FDC_SPLASH displays the splash screen for the FDC toolbox, which was shown ear-

lier in figure 7.2, until the user presses ‘Enter’ or clicks inside the splash-screen 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-file FDC _ SPLASH . M can be found in the directory PROGRAMS.

12.3

Directory functions

Some FDC functions require access to specific subdirectories. To assure flexibility 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 flexibility 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 specified in the string variable NAME. D = fdcdir(NAME1,NAME2) returns the complete path of the FDC sub-subdirectory specified in the string variable NAME2, which itself is contained in the FDC subdirectory specified 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: Let’s assume that the FDC root-directory as specified in ated by the function FDCINIT) is:

FDC . INI

(which was gener-

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 specified 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.

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 files that need to be changed to reflect 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 flight conditions, and

212

Chapter 12. Support functions reference

system matrices of linearized models. Although different file-extensions will be used to distinguish different kinds of data, all datafiles will use the M ATLAB data format which is normally used for MAT-files. Model parameter files can be recognized by the extension . DAT, linearized model datafiles use the extension . LIN, and trimmed flight conditions use the extension . TRI. A support function FDCLOAD allows quick retrieval of arbitrary datafiles from the data-directory, while some dedicated functions are available to retrieve files of a specific type (e.g. DATLOAD for DAT-files).

12.4.1

FDCLOAD

The utility FDCLOAD retrieves datafiles 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 datafiles; the exact location of this directory is retrieved using the function DATADIR (see section 12.3.2). Usage: fdcload(’ext’) opens a file browser, listing all files with extension ext that are present in the data directory, and loads the selected file into the base workspace. fdcload(’ext’,’datatype’) additionally allows the specification of a short description of the data type, which will be shown in the title bar of the file browser window (see for instance figure 12.2, where the specified ’datatype’ description is ’model-definition data’). In both cases, the user can select a file from the list, or navigate to a different directory to select a file from elsewhere. It is allowed to use wildcards ? and *, and the fileextension may have more than three characters. Double extensions are possible too, e.g. ’ext1.ext2’. In addition, a default filename can be specified by replacing ’ext’ by [filesep ’filename.ext’], where ’filename.ext’ is the required default file. Notice that there is no initial protection against specifying a non-existing filename; a warning message will be displayed only when the user actually tries to open a non-existing file from the load dialog window. If the selected file 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 specified extension, the datafile must use the M ATLAB file-format (i.e. the format normally used for MAT-files); FDCLOAD uses the LOAD command with the -mat option. FDCLOAD does not yet support ASCII datafiles. To change this load behaviour, it will be necessary to edit the FDCLOAD . M file accordingly.

12.4.2

DATLOAD, LINLOAD, MATLOAD, and TRILOAD

The following default file-extensions are used to store specific types of FDC data: •

DAT -files,

used to store model definition data (e.g. aircraft model parameters),

•

LIN -files,

used to store system matrices of linearized aircraft models,

•

TRI -files,

used to store trimmed flight conditions.

12.4. Data load functions

213

Figure 12.2: File browser window that is displayed when using DATLOAD

In addition, MAT-files may be used to store general M ATLAB data. The functions DATLOAD, LINLOAD, TRILOAD, and MATLOAD have been designed to simplify the handling of these datafiles. They each call FDCLOAD for their respective file-extension, which means that an appropriately configured file-browser will be displayed, allowing the user to select a file for loading into the base M ATLAB workspace. Usage: datload will open a file browser, listing all available DAT-files in the FDC datadirectory. The user must select a file from the list; no default file is specified. It is still possible to select a different filetype and/or navigate to a different directory, using the selection options from the file browser. datload(’fname’) does the same, but pre-selects the file fname.dat. The file, extension, and directory can be overruled via the file browser. linload, matload, and triload do the same for LIN-, MAT-, and tively, again allowing optional pre-selection of a specific file.

TRI -files,

respec-

Example: Figure 12.2 shows the file browser that will be displayed after typing datload at the command-line.1 In this example, the file AIRCRAFT. DAT has been selected by the user (and thus highlighted in the file list); this file will be loaded into the base 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 filename AIRCRAFT. DAT will be highlighted in the ’File name’ field, instead of the file-list. 1 The figure shows what the file browser will look like on a Windows system. The lay-out will differ for other operating systems, but the functionality of the file browser will be roughly the same.

214

12.5

Chapter 12. Support functions reference

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 files 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 specifically designed to deal with FDC helpfiles, it can also be used to display HTML files 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 helpfile 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 file BROWSE . M accordingly. Usage: browse name or browse(’name’) opens the specified HTML file in the standard web browser browse name -mlhelp or browse(’name’,’-mlhelp’) opens the HTML file 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 helpfile C : \ TOOLBOX \ HELPFILES \ FILENAME . HTML. In order to display this file in the web browser, the following entries for ’name’ are valid: • the full path, including the filename and the file-extension: C : \ TOOLBOX \ HELPFILES \ FILENAME . HTML • a part of the pathname, including the filename and the file-extension: HELPFILES \ FILENAME . HTML • the filename and file-extension only:

FILENAME . HTML

12.5. Generic helper functions

215

• the full path, including the filename, but excluding the file-extension: C : \ TOOLBOX \ HELPFILES \ FILENAME • a part of the pathname, including the filename, but excluding the extension: HELPFILES \ FILENAME • the filename only, excluding the file-extension:

FILENAME

The directory in which the helpfile is located must be present in the M ATLAB search path. An error message will be shown if the specified file cannot be found. Suitable file-extensions are .htm, .html, .HTM, and .HTML; all other extensions will be disregarded and will result in a ’file not found’ error, even if the file does exist! For instance, if a file README . TXT can be read from the M ATLAB path, browse(’readme.txt’) will still yield a ’file not found’ error, because BROWSE will search for README . TXT. HTM and README . TXT. HTML (both upper and lower-case), not README . TXT.

12.5.2

NEWMSGBOX

The function NEWMSGBOX is an alternative for M ATLAB’s 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 fit an appropriately sized dialog window. Message may be a string vector, string matrix or cell array. newMsgBox(Message,Title) allows the user to specify the title of the message box. newMsgBox(Message,Title,Font) allows the user to specify both the title and the font settings for the message box. Font is a structure that contains the font definitions; valid fields 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 ATLAB’s 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

Chapter 12. Support functions reference

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 fit, it is rounded to a value which does fit 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 figures and graphical user-interface windows. Usage: s = screensize returns the screen dimensions in pixels, s = screensize(units) returns the screen dimensions in the units of 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 defined 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-specific helper functions

217

Usage: choice = txtmenu(header, item1, item2, ..., item_n) displays a header string, followed in sequence by the menu-item strings: item1, item2, ... , item_n. 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-specific 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 definition 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 datafile containing aerodynamic, propulsive, geometrical, and mass-distribution parameters for the S IMULINK model of the Beaver dynamics. To maintain flexibility, 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

Chapter 12. Support functions reference

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 coefficients. The exact definitions of these variables can be found in appendix C. The purpose of MODBUILD is to build these variables and save them to a datafile. By default, the model parameters will be stored in AIRCRAFT. DAT in the 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 datafile is inadvertently deleted. Please do not be mislead by the name MODBUILD, the utility does not actually ‘build’ complete models, it merely defines their parameters! If it is desired to change the values of one or more model parameters (including mass and/or mass-distribution), the source file MODBUILD . M must be edited, as MODBUILD does not feature a user-interface to change parameter values 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 won’t be required very often.2 The file MODBUILD . M has been included in the AIRCRAFT directory, to reflect 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 flexibility 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 definition 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 airplane’s 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 file, 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.

12.6. Model-specific helper functions

219

Since the mass and mass-distribution are assumed to be constant during simulations, MODBUILD also computes the inertia coefficients from equation (2.29) by substituting the pre-specified 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 significant sudden changes in mass and/or mass-distribution, e.g. airplanes with a variable wing-sweep or airplanes that drop significant loads in-flight. 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 definitions) as a guideline or starting point, this is not required. However, it is recommended to re-use at least the MODBUILD . M code that defines GM1 and GM2, changing only the figures 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 definition of a vector xfix in the M ATLAB workspace, which is used as a multiplication factor by the block xfix in the aircraft model (see chapter 8). This block is used to constrain state variables to their initial 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 artificially 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’ flight control law by artificially fixing the value of the airspeed. To this means, the block xfix performs an element-by-element multiplication of ˙ and a gain vector of the same length, xfix. the time-derivative of the state vector, x, The elements of xfix 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 xfix. FIXSTATE offers four user choices, as shown in figure 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 fixed as well.

220

Chapter 12. Support functions reference

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 fix 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 fixed. With the state vector being x = [ V α β p q r ψ θ ϕ xe ye H ] T , we can for instance fix θ and xe by specifying the vector [8 10], as θ and xe are the eighth and tenth elements of x, respectively. 4. Don’t fix any states. This option resets the default value of xfix, 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 xfix from the workspace altogether. After specifying the states to be fixed, 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 datafile 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 xfix needs to be defined 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 define xfix, as the block xfix within the aircraft model will automatically use the default value of ones(1,12) if xfix hasn’t been defined.

12.6. Model-specific helper functions

12.6.3

221

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 definitions 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 deflection δr ). This simplifies 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 definitions from appendix D. If the input/output definitions 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 definitions of the matrices In and Out itself and it does not offer any internal errorchecking mechanisms to protect against incorrect sizing or definition of the output matrices. The source file 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 deflections δ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 sourcefile 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 first 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 definitions This appendix defines 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 specifically 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 [ ms−1 ] [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 (specific force) in c.g. along XB -axis output of accelerometer (specific force) in c.g. along YB -axis output of accelerometer (specific 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

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

Appendix A. Symbols and definitions

[–] [N] [m] [m] [–]

[N] [N] [N] [g] [ ms−2 ] [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 kmol−1 ] [ kg kmol−1 ] [ RPM ] [ Nm ] [ rad s−1 ] [ Nm s−1 ]

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 2 ρV

body-fixed reference frame, see section A.7.1 Earth-fixed reference frame, see section A.7.1 measurement reference frame, see section A.7.1 special body-fixed 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 flight-path reference frame, see section A.7.1 total external force along XB -axis, see figure 2.1 total external force along YB -axis, see figure 2.1 total external force along ZB -axis, see figure 2.1 flight-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 coefficient (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 figure 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 figure 2.1 molecular weight of the air molecular weight of the air at sea level engine speed total yawing moment, see figure 2.1 angular rate of roll, see figure 2.1 engine power

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 V∆δa V∆δe V∆δr w w1 , w2 , w3

287

inertia coefficients for p-equation, see table 2.2 [ Nm−2 ] [ 00 Hg ] [ rad s−1 ] [ Nm−2 ] [ Nm−2 ]

ambient or free-stream pressure manifold pressure angular rate of pitch, see figure 2.1 impact pressure dynamic pressure

inertia coefficients for q-equation, see table 2.2 [ rad s−1 ] [ JK −1 kg−1 ] [ JK −1 kmol−1 ] [ − ] [ m −1 ] [m] [m]

angular rate or yaw, see figure 2.1 R a /M0 , specific 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 coefficients for r-equation, see table 2.2 [ m2 ] [ µA rad−1 ] [ µA rad−1 ] [s] [s] [K] [K] [ ms−1 ] [ ms−1 ] [ ms−1 ] [ ms−1 ] [ ms−1 ] [ ms−1 ] [ ms−1 ] [ ms−1 ] [ ms−1 ] [ ms−1 ] [ ms−1 ] [ ms−1 ] [ ms−1 ] [V] [V] [V] [ ms−1 ] [ − ]

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 figure 2.1 calibrated airspeed equivalent airspeed wind velocity wind velocity at 9.15 m altitude (reference velocity) command signal to actuators (change in deflection of the ailerons) command signal to actuators (change in elevator deflection) command signal to actuators (change in rudder deflection) velocity component along ZB -axis independent white noise signals

288

Appendix A. Symbols and definitions

wg ww wwe W Xa xe xf Xgr Xp Ya ye yf Ygr Yp Za ze zf Zgr Zp α β γ γ γgs Γ gs

[ ms−1 ] [ ms−1 ] [ ms−1 ] [N] [N] [m] [m] [N] [N] [N] [m] [m] [N] [N] [N] [m] [m] [N] [N] [ rad ] [ rad ] [ rad ] [–] [ rad ] [ rad ]

Γloc

[ rad ]

ΓVOR δa

[ rad ] [ rad ]

δe δf δr ∆ ∆pt ∆δa ∆δe ∆δr ε gs θ λ µ µ ρ σ σgs σloc σu σv σw ϕ Φ

[ rad ] [ rad ] [ rad ] [ Nm−2 ] [ rad ] [ rad ] [ rad ] [ rad ] [ rad ] [ Km−1 ] [ rad ] [ kg m−1 s−1 ] [ kg m−3 ] [ µA ] [ µA ] [ ms−1 ] [ ms−1 ] [ ms−1 ] [ 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-fixed reference frame FE X-coordinate in runway-fixed reference frame FF gravity force along XB -axis propulsive force along XB -axis aerodynamic force along YB -axis Y-coordinate in Earth-fixed reference frame FE Y-coordinate in runway-fixed reference frame FF gravity force along YB -axis propulsive force along YB -axis aerodynamic force along ZB -axis Z-coordinate in Earth-fixed reference frame FE Z-coordinate in runway-fixed reference frame FF gravity force along ZB -axis propulsive force along ZB -axis angle of attack, see figure 2.1 sideslip angle, see figure 2.1 flight-path angle ratio of specific heats of air nominal glide-path angle on final 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 deflection of ailerons (δa = δaright − δaleft ), see figure A.5 deflection of elevator deflection of flaps deflection of rudder increment increase of total pressure over the propeller change in deflection of the ailerons change in elevator deflection change in rudder deflection 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

χ ψ ψw ψRW ω ω0 ωn Ω

A.2 a Caero Cprop F h M r u... V Vw x y... Ω

A.3 A B C D TP→Q Θ Φ Ψ

A.4 f(t) g(t) H (ω ) S(ω ) S(Ω)

A.5 0 0 a

[ rad ] [ rad ] [ rad ] [ rad ] [ rad s−1 ] [ rad s−1 ] [ rad s−1 ] [ rad m−1 ]

289

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

Vectors body-axes acceleration vector vector with non-dimensional aerodynamic force and moment coefficients vector with non-dimensional engine force and moment coefficients (‘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

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 first Euler rotation from FE to FB transformation matrix for second Euler rotation from FE to FB transformation matrix for second Euler rotation from FE to FB

Functions general vector-equation for the time-derivatives of the state variables general vector-equation for the output variables frequency response of forming filter power spectral density function power spectral density function

Indices and subscripts nominal value value at sea level ailerons

290

Appendix A. Symbols and definitions

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 α

A.6

relative to the surrounding atmosphere (used for velocity components) aerodynamic forces and moments or force and moment coefficients center of gravity stability derivative with respect to non-dimensional pressure increase across propeller elevator relative to Earth axes (used for velocity components) flaps referenced to runway-fixed reference frame FRW , f stands for ‘field’ 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 defining runway parameters engine forces and moments or force and moment coefficients (‘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 deflection of ailerons stability derivative with respect to δa α stability derivative with respect to deflection of elevator stability derivative with respect to δe β2 stability derivative with respect to deflection of flaps stability derivative with respect to deflection of rudder stability derivative with respect to δr α

Abbreviations

AFCS ALH ALS CACSD CAS CD c.g. DHC DME

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)

A.7. Reference frames and sign conventions

DUT FCC FCS FDC GA GPS GS HH IAS ILS IRS LOC MLS NAV NDB PAH ODE RAH STOL TAS VOR VTOL

A.7 A.7.1

291

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

Reference frames and sign conventions Definitions

Many different reference frames have been used throughout this report. The most important onces have been listed below: Body-fixed 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 aircraft’s 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-fixed reference frame, used in the study of small deviations from a nominal flight 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 flight 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-fixed 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

Appendix A. Symbols and definitions

fixed in space. Its origin can be placed at an arbitrary position, but will be chosen to coincide with the aircraft’s center of gravity at the start of a flight 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-fixed reference axes, although the origin OV moves relatively to the Earth-fixed reference frame. Measurement reference frame FM : This is a left-handed orthogonal reference 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 flight 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-fixed 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-fixed reference point, which has been selected to coincide with a c.g. position that was actually used during one flight. 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 define 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-fixed reference frame, FRW : This reference frame is used to define the geometry of the final approach to a runway. Its origin lies on the runway threshold, and it is aligned in the direction of the runway centerline. The XRW -axis 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 final approach. See also figures 5.9 and 5.7 from chapter 5.

A.7.2

Summary of the application of the reference systems

The equations for translational and angular velocities, which were derived in 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 defined with respect to the Earth-fixed reference frame FE , while the definition of the aircraft attitude in terms of the Euler angles ψ, θ, and ϕ required the introduction of the vehicle-carried vertical reference frame FV . The runway-fixed reference frame is used for the definition of the final approach geometry, i.e. the position of the airplane in relation to the landing runway. Finally, two special body-fixed reference frames FM and FR are used to define the reference flight condition for the Beaver model in table B.5 of appendix B; these reference frames are not relevant for other purposes.

A.7. Reference frames and sign conventions

293

XV (north) YV (east) c.g. XE (north)

YE (east)

r

ZV (down)

g ZE (down)

Figure A.1: Relationship between the vehicle-carried vertical reference frame FV and the Earth-fixed reference frame FE

A.7.3

Relationships between the reference frames

In figure A.1 the relationship between the Earth-fixed and vehicle-carried vertical reference systems is shown. As can be seen from this figure, 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 figure A.2. The Euler angles ψ, θ, and ϕ define the orientation of FB with respect to FV , hence they define 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

Appendix A. Symbols and definitions

XV

-

t 

ψ

  

X0



Horizontal plane



Y0

  

ψ YV

• A rotation by ψ about the ZV -axis to the intermediate position X 0 Y 0 ZV ZV ? XB

1      θ  t 

XV

-

ψ X0 Y0

ψ 

YV

θ ZV ?

• A rotation by θ about the Y 0 -axis to the intermediate position XB Y 0 Z 0 Z0 XB

1       θ t  
A
A
A
A
A ψ
A Y0
A
A ϕ 
A ϕA
YV A θ YB 

A ZB UA

ZV ?

XV

-

ψ X0

• A rotation by ϕ about the XB -axis to the final position XB YB ZB

Z0

Figure A.2: Relationship between the vehicle-carried vertical reference frame FV and the body-fixed reference frame FB

A.7. Reference frames and sign conventions

295

XV

Y0

  

χ





 





-

t

χ X0 Horizontal plane

YV • A rotation by χ about the ZV -axis to the intermediate position X 0 Y 0 ZV ZV ? X

:W

XV

-

t

γ

χ X0

Y0

χ YV



γ ZV ?

• A rotation by γ about the Y 0 -axis to the intermediate position XW Y 0 Z 0 Z0 X

:W

XV t B  B  B  B  B χ B Y0  B µ  B /  Y B

YW

V

γ ZV ?

-

γ

χ X0

B B

B

µ B Z0

B NB ZW

• A rotation by µ about the XW -axis to the final position XW YW ZW

Figure A.3: Relationship between the vehicle-carried vertical reference frame FV and the flight-path reference frame FW

296

Appendix A. Symbols and definitions

YB = YS XB βo

αo

XW

YW

V c.g.

βo XS

αo

ZB ZS = ZW

Figure A.4: Relationship between the body-fixed reference frame FB , flight-path reference frame FW and stability reference frame FS δr (+)

δe (+)

δa

right

(+)

δa

left

( )

δa = δa δa right left

Figure A.5: Sign conventions for control surface deflections

A.7. Reference frames and sign conventions

297

Thus, we find 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 flight-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 figure A.3. The Euler angles ψ, θ, and φ define the orientation body axes FB in relation to the vehicle-carried vertical reference frame FV ; the angles χ, γ, and µ define the orientation of the flight-path axes FW in relation to FV . Figure A.4 shows the relationships between the body, flight-path, and stability reference frames. These three reference systems all have their origin in the aircraft’s center of gravity. The XW -axis is aligned with the velocity vector of the aircraft. The orientation of the flight-path axes with respect to the body-fixed reference frame is defined by the angle of attack α and the sideslip angle β. The stability reference system is displaced from the flight-path axes by a rotation β and from the body axes by a rotation −α. For the orientation of the runway-fixed reference frame relatively to the Earthfixed 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 deflections of control surfaces

Figure A.5 shows the positive directions of control surface deflections. To summarize: • The positive elevator deflection is measured downwards; a positive value of δe results in a pitch-down moment for the aircraft. • The deflections of the rudder and ailerons are positive if they force the aircraft to turn to the left. If one aileron deflection is positive, the deflection of the opposite aileron consequently will be negative. The ‘total’ aileron deflection is defined as: δa = δa right − δa left . • The flap angle is positive if the flaps deflect downwards (which they always do), similar to the elevator deflection. 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 definitions, especially for the aileron deflection (some resources use the mean deflection of the left and right ailerons, rather than the total deflection).

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 1950’s 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 ‘flying laboratory’ for flight 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 figure B.1; some basic technical data has been presented in table B.1. The aircraft has a fixed undercarriage. Under normal circumstances, the flapsettings ‘up’ (0◦ ), ‘climb’ (15◦ ), and ‘take-off’ (35◦ ) are used in flight. Other possible flapsettings are ‘landing’ (50◦ ) and ‘full’ (58◦ ), but those are rarely applied in practice, due to the short take-off and landing (STOL) flight characteristics of the Beaver. The flight model data from ref.[34] were based on measurements in actual flights, which were made during the 1977-1978 period. Table B.2 lists some typical flight conditions for the Beaver.

B.2

Flight envelope

Figure B.2 shows the flight envelope of the Beaver, including the manoeuvre points that were used for the flight-test measurements from ref.[34]. The flight 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 figure B.2 is higher than the maximum speed from table B.1; the latter value probably representing the maximum operational speed Vmo .

300

B.3

Appendix B. Beaver model parameters

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 flight conditions, roughly covered by the flight envelope boundaries of figure B.2. The corresponding model parameters have been listed in tables B.3 and B.4, 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 profile 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 figures have been marked by a star symbol: ? .

Figure B.1: The De Havilland DHC-2 Beaver aircraft

B.3. Aerodynamic and engine model parameters

301

12000 flight envelope manoeuvre point

10000 5510

8000

tf H6000 ] [

3506

4506

5506

3502

4502

5502 6002

4000 3004

2000

Vs = 26.75 0 10

20

Vne = 80.25 30

40

50

V m/s [

60

70

80

90

]

Figure B.2: The flight envelope of the De Havilland DHC-2 Beaver aircraft

Flight condition

δ f [deg]

n [RPM]

pz ["Hg]

V [kts]

H˙ [ft/min]

Take-off Climb Cruise Descend Approach

35 15/0 0 0 15

2350 2000 1800 1800 2000

36.5 30.0 28.0 15.0 15.0

70 70 100 120 80

800/900 700/800 0 (level flight) -1000 -400/-500

Table B.2: Typical flight conditions for the Beaver (the given values are an average of normally applied flap deflections, engine settings, and airspeeds); see ref. [34].

302

Appendix B. Beaver model parameters

CX

CY

CZ

parameter

value

parameter

value

parameter

value

0

−0.03554 0.002920 5.459 −5.162 −0.6748 0.03412 −0.09447

0

0

δr α

−0.002226 −0.7678 −0.1240 0.3666 −0.02956 0.1158 0.5238

δf

−0.05504 −5.578 3.442 −2.988 −0.3980 −15.93 −1.377

1.106

˙ βb 2V

−0.1600

αδ f

−1.261

α α2 α3 qc V

δr δf αδ f

β pb 2V rb 2V

δa δr

Cl

α α3 qc V

δe δe β2

Cm

Cn

parameter

value

parameter

value

parameter

value

0

0.0005910

0

0.09448

0

β

−0.06180 −0.5045 0.1695 −0.09917 0.006934 −0.08269

α

−0.6028 −2.140 −15.56 −1.921 0.6921 −0.3118 0.4072

−0.003117 0.006719 −0.1585 −0.1112 −0.003872 −0.08265 0.1595 0.1373

pb 2V rb 2V

δa δr δa α

α2 qc V

δe β2 rb 2V

δf

β pb 2V rb 2V

δa δr qc V β3

Table B.3: Coefficients in the aerodynamic model of the Beaver, valid within the 35-55 ms−1 TAS range

CX

CY

CZ

parameter

value

parameter

value

parameter

value

dpt

0.1161

−

−

dpt

−0.1563

α · dpt

2

0.1453

Cl

Cm

parameter

value

parameter

α2 · dpt

−0.01406

dpt

dpt ≡

∆pt 1 2 2 ρV

Cn value

−0.07895 (

P with: 3 2 ρV

= C1 + C2 1

parameter

value

dpt3

−0.003026

C1 = 0.08696 C2 = 191.18

Table B.4: Coefficients in the engine forces & moments model of the Beaver, valid within the 35-55 ms−1 TAS range

B.3. Aerodynamic and engine model parameters

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 m−3 ]

303

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 defined 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

Defining 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 definitions of the vector GM1 and matrix GM2, which contain mass-distribution data and information about the airplane’s 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 file AIRCRAFT. DAT, which can normally be found in the DATA subdirectory, using the utility DATLOAD (see section 12.4.2). If this datafile has somehow inadvertently been deleted, it can be re-created by running the program MODBUILD (see section 12.6.1). The definitions 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 shouldn’t be too diffi-

306

Appendix C. Data structure of the FDC model parameters

cult to identify the aircraft-dependent parameters that need to be changed, and the generic aircraft-independent code that determines the inertia coefficients from table 2.2 of chapter 2. It is recommended to save the altered parameters to a new datafile, such as AIRCRAFT 1 . DAT, BOEING 747 . DAT, or something similar. See section 12.6.1 for more details about MODBUILD.

C.2

Definition of the parameter matrices for the Beaver model

Aerodynamic model The stability and control derivatives used by the aerodynamic model of the Beaver aircraft have been combined in the parameter matrix AM. The definition of AM has been given in table C.2, while the numerical values of these coefficients can be found in table B.3 from appendix B. The numerical values have been implemented in MODBUILD, which generates the datafile AIRCRAFT. DAT. See section 3.3.1 for more details about the aerodynamic model itself.

Engine forces & moments model The coefficients used by the propulsion model of the Beaver aircraft have been combined in the parameter matrix EM. The definition of EM has been given in table C.2, while the numerical values of these coefficients can be found in table B.4 from 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 definition 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 coefficients from table 2.2 in chapter 2, with numerical values that correspond to the moments and products of inertia from the vector GM1. The definition 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. Definition of the parameter matrices for the Beaver model



AM

=

                                              

C X0

CY0

CZ0

Cl0

Cm0

Cn0

CXα

0

CZα

0

Cmα

0

CXα2

0

0

0

Cmα2

0

CXα3

0

CZα3

0

0

0

0

CYβ

0

Clβ

0

Cnβ

0

0

0

0

Cmβ2

0

0

0

0

0

0

Cnβ3

0

CYp

0

Cl p

0

Cn p

CXq

0

CZq

0

Cmq

Cnq

0

CYr

0

Clr

Cmr

Cnr

0

0

CZδe

0

Cmδe

0

0

CZδ

0

Cmδ f

0

0

CYδa

0

Clδa

0

Cnδa

CXδr

CYδr

0

Clδr

0

Cnδr

0

CZαδ

0

0

0

0

CYδr α

0

0

0

0

0

0

0

Clδa α

0

0

0

0

CZδ β2

0

0

0

0

CYβ

0

0

0

0

1

2

3

4

5

6

CXδ

f

CXαδ

f

f

f

e

307

T                                               

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

Table C.1: Coefficients of the aerodynamic model of the Beaver

 EM

=

CXdpt

  0    C  Xαdpt2  0 1

0

CZdpt

0

Cmdpt

0

0

0

0

0

Cndpt

0

0

0

0

0

0

0

Clα2 dpt

0

0

2

3

4

5

6

T 1

      

Table C.2: Coefficients of the engine forces & moments model of the Beaver

2 3 4

308

GM1

Appendix C. Data structure of the FDC model parameters

=

h

c

b

S

Ixx

Iyy

Izz

Jxy

Jxz

Jyz

m

1

2

3

4

5

6

7

8

9

10

Pl

Pm

Pn

Ppp

Ppq

Ppr

Pqq

Pqr

Prr

  Ql Rl

Qm

Qn

Q pp

Q pq

Q pr

Qqq

Qqr

Qrr

Rm

Rn

R pp

R pq

R pr

Rqq

Rqr

Rrr

2

3

4

5

6

7

8

9

 GM2

=

1

Table C.3: Beaver geometry and mass-distribution

iT

1

T

1

 

2 3

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 file. 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 definition 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 definitions 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:

Outputs:

δe

δa

δr

n

pz

uw

vw

ww

1

2

3

4

5

6

7

8

9

u˙ w 10

v˙ w 11

12

V

α

β

p

q

r

ψ

θ

ϕ

xe

ye

H

1

2

3

4

5

6

7

8

9

10

11

12

pb 2V 14

qc V 15

rb 2V 16

H˙ 13

δf

w˙ w

Table D.1: Definition 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

Output signals from the aircraft model, logged in the matrix Out

Subvector

x x˙ ybvel yuvw ydl yfp ypow

311

V

α

β

p

q

r

ψ

θ

ϕ

1

2

3

4

5

6

7

8

9

xe 10

ye 11

12

V˙

α˙

β˙

p˙

q˙

r˙

ψ˙

θ˙

ϕ˙

x˙ e

y˙ e

H˙

13

14

15

16

17

18

19

20

21

22

23

24

u

v

w

25

26

27

u˙

v˙

w˙

28

29

30

pb 2V 31

qc V 32

rb 2V 33

γ

fpa

χ

Φ

34

35

36

37

dpt

P

38

39

Ax

Ay

Az

40

41

42

a x,k 43

ay,k 44

az,k 45

Caero

CX a 46

CYa 47

CZa 48

Cla 49

Cma 50

Cna 51

Cprop

CX p 52

CYp 53

CZ p 54

Cl p 55

Cm p 56

Cn p 57

Za 60

La 61

Ma

Na

62

63

Lp 67

Mp

Np

68

69

yacc

FMaero FMprop Fgrav Fwind yatm

Xa

Ya

58

59

Xp

Yp

Zp

64

65

66

Zgr 72

Xgr

Ygr

70

71

Xw

Yw

73

74

Zw 75

ρ

ps 77

T

µ

g

78

79

80

76

a

M

81

82

qdyn 83

yad2

qc 84

Ve 85

Vc 86

yad3

Tt 87

Re 88

Rc 89

yad1

H

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

uaero uprop uwind

Input signals from the aircraft model, logged in the matrix In

δe

δa

δr

δf

1

2

3

4

u˙ w 10

n

pz

5

6

uw

vw

ww

7

8

9

v˙ w 11

w˙ w 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

yils1 yils2 yils3 yils4

Output signals from the system ILS example, logged in the matrix yils

igs 1

iloc 2

εgs

Γloc

3

4

xf

yf

Hf

dgs

Rgs

5

6

7

8

9

LOC_flag

GS_flag

11

12

Rloc 10

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

yVOR1

Output signals from the system VOR example, logged in the matrix yvor

ΓVOR 1

yVOR2

RVOR 2

yVOR3 yVOR4

Cone of silence flag

Range flag

3

4

To/From flag 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, royalty- free, 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 modifications 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 defined 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 identified 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 modified 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 Licensor’s 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 conflict-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. Definition 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 definition, “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 fifty percent (50%) or more of the outstanding shares, or (iii) beneficial 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 modification. This license may not be modified 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, Identification, 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 flight 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 Definition 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 flight 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 World’s Greatest Bush Plane. Douglas & McIntyre, Canada, 1997. [30] Ruijgrok, G.J.J.: Elements of Airplane Performance. Delft University Press, Delft, The Netherlands, 1990. [31] Stengel, R.F., Sircar, S.: Computer-Aided Design of Flight Control Systems. AIAA-91-2677-CP, Princeton, New Jersey, USA, 1991. [32] Shampine, L.F., Rechelt, M.: The M ATLAB ODE Suite. USA, 1997. In: SIAM Journal on Scientific 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., Padfield, G.D., Smith, P.R.: Computer-Aided control law research – from concept to flight 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.