REAL-TIME FLIGHT SIMULATION SUPPORT FOR THE X-31 AIRCRAFT PROGRAM

Steve Zammit and Koos Zwaanenburg Applied Dynamics International

Ann Arbor, Michigan

Abstract

The real-time simulation of aircraft with many different types of hardware in the loop can be a very challeng- ing task-especially when one has to simulate a high- performance aircraft with fast, nonlinear dynamics, a state-of-the-art flight control system, actuators, and other external hardware simultaneously. This paper discusses in detail the use of the AD 100 simulation computer for the real-time simulation requirements of the X-31 project.

Introduction

The X-31 project is the first international X-aircraft development program in which Rockwell Internatio- nal Corporation's North American Aircraft division is working with Messerschmidt-B61kow-Blohm (MBB) of Germany to design and build two Enhanced Fighter Maneuverability (EFM) aircraft for flight testing. This fight testing will focus on controlled flight a t very high angles of attack (post-stall maneuvering).

T h e X-31

The purpose of the X-31 is to prove the feasibility of controlled flight at very high angles of attack, an area where conventional aircraft will stall and fall into a spin. The X-31 will also help to provide a better un- derstanding of the aerodynamics of the high-angle-of- attack flight regime. Instead of losing control a t high angles of attack, the X-31 should be able to perform

Copyright el989 by the American Institute of Aeronautics and Astronautics Inc. All rights reserved.

maneuvers that were until now considered impossible, giving it the advantage of being able to point rapidly in a desired direction. To achieve these goals, the X-31 is equipped with flight-control surfaces like rud- der, elevons, and canards, and also with paddles in the engine exhaust stream, which can provide thrust vectoring. At low angles of attack, the X-31 will fly like any airplane. At high angles of attack, the stalled flight-control surfaces will not be effective for control, and the thrust-vectoring paddles must take over. For coordinated motion of the aircraft, all flight controls will be governed by a sophisticated fly-by-wire control system, since pilots will not be able to perform com- plex maneuvers without it.

The X-31 development time is intended to be short, the budget is fairly low. Consequently, off-the-shelf components will be used as much as possible: F404 engine, the cockpit of the F-18, and the landing gear of the F-16.

Purpose of t h e Simulation

The simulation activities in support of the X-31 project are both real-time and non-real-time in nature. Non- red-time simulation is performed to support the real- time simulations. The real-time models are derived from the non-real-time model, which serves as the &truth modeln for all simulation activities. The real- time simulations are necessary for the following rea- sons: first, for control law and flight-control system verification and validation; second, to verify compli- ance of the aircraft with handling and flying qualities requirements; and finally, to demonstrate correct per-

formance of the flight-control system in real time.

The real-time simulation activities in support of the X-31 program are broken into two phases. The first is the Real-Time All-Digital Simulation (RTADS) phase. A complete mathematical model of the flight dynam- ics of the X-3i aircraft, together with the flight-control system, actuators, and control surfaces, is developed and implemented for the purpose of verification of the flight-control laws, pilot evaluation, and handling quali- ties analysis. In this phase, the simulation program has to communicate with both instruments, stick, and ped- als in the mock-up cockpit and a Computer-Generated Image (CGI) system. In the second phase, called Flight Hardware-In-The-Loop Simulation (FHILS), the code for the flight-control computer is removed from the simulation program and replaced by the actual flight- control computer. Furthermore, the aircraft actuators are made external and all system test equipment, the CGI system, and the cockpit instruments and con- trols are connected to the simulation program. A wide variety of interfacing problems becomes apparent. VMEbus-based systems, 1553-buses, analog hardware for the actuators, and a digital interface to the CGI equipment combine into a complex system that must be orchestrated in a meaningful fashion. The overall result of the FHILS activity will be a full-blown X-31 simulation with hardware in the loop that will be used for overall system evaluation and pilot training.

The fast dynamics of the X-31 aircraft dictate a frame rate of 2 milliseconds or better for the numerical in- tegration of the model state equations. Furthermore, the aerodynamic data base of the X-31 contains several hundred thousand coefficient values, which makes the nonlinear aerodynamic function evaluation task quite challenging with respect to storage requirements as well as computer speed. The flight-control computer is a discrete time system with a sample time of 20 millisec- onds. The inclusion of such a system in a simulation of a continuous-time system like the aircraft equations of motion introduces some nontrivial problems. The re- quirements mentioned above make it clear that a fast and versatile computer system had to be used. The

choice of a VAX 11/7801 and an AD 100 proved to be instrumental in the successful implementation of the RTADS and FHILS phases with the above-mentioned requirements.

SYSTEM 100 Architecture

Applied Dynamics International (ADI) has been in- volved in solving time-critical simulation of continu- ous dynamic systems since its founding in 1957. The SYSTEM 100 [4] simulation computer system was in- troduced by AD1 in 1984. It consists of an AD 100, a high-speed, floating-point compute engine; a host controller, a general-purpose digital computer of the VAX family; and ADSIM, a user-friendly simulation language designed specifically for the AD 100. The SYSTEM 100 hardware and software work together to form a complete simulation environment.

The AD 100

The AD 100, a synchronous, bus-oriented multiproces- sor compute engine designed for time-critical digital simulation, is the basic fundamental building block of the SYSTEM 100. The AD 100 is a single-user sys- tem without an operating system. It is controlled by a multiprocessing VAX host computer running the VMS operating system. Acting as the controller and user in- terface, the host computer relieves the AD 100 of these interrupt-based tasks. The compute engine needs to be isolated from the overheads and restrictions associated with an operating system in order to achieve and main- tain its optimum computation speed or frame rate.

The AD 100 is capable of 20 million floating-point o p erations per second. The basic system consists of four processors and a host interface tied to a common bus, the PLUSBUS. The PLUSBUS is 105 bits wide, 65 bits of data and 40 bits of address and control. Emitter- Coupled Logic (ECL) devices are used to obtain high computational speed. The four basic processors are the Communication and Control Processor (COM), the

'VAX and VMS are registered trademarks of Digital Equip ment Corporation

Arithmetic Logic Unit (ALU), the Mulitplier (MUL), and the Storage Processor (STO). Each processor has its own program memory, program counter, and in- struction decoder. Each processor has a 64bit instruc- tion. The COM Processor has a 64K program memory, and the other processors have 4K program memories. Timings in the AD 100 are expressed in terms of a mas- ter clock period of 25 nanoseconds. The instruction cycle of the AD 100 consists of four of these phases or periods.

Every arithmetic operation performed on the AD 100 is done in floating-point arithmetic. Calculations are performed using either a 53-bit short-word format or a 65-bit long-word format. Both formats contain 1 sign bit, 12 exponent bits, and either 40 or 53 significand bits. The long-word format is used where additional accuracy is needed, such as in the case of numerical in- tegration to minimize roundoff and truncation errors.

The Storage Processor provides 64K of 65-bit high- speed data storage. Memory accesses and address arithmetic can take place two per instruction cycle. Some simulation tasks such as function generation and memory buffers require large amounts of data storage. It is for these purposes that an optional processor, the Function Memory Unit (FMU), was introduced, which has data memory of 2 million words by 64 bits.

I n p u t / O u t p u t Con t ro l Processor

The use of hardware-in-the-loop simulation is growing rapidly as a design-and-test environment for the devel- opment of products in the aerospace and automotive industries. The interface to hardware in the loop may be either digital as in the case of on-board micropro- cessors, or may be analog for such hardware as motion- based platforms or system test equipment. Both dig- ital and analog interfaces may be necessary. The In- put/Output Control Processor (IOCP) provides both types of interfaces.

The IOCP physically resides in the AD 100 cabinet as a piggyback board to the COM Processor. It does not

interface directly to the PLUSBUS. Instead, it passes data through the use of the dual-ported memory of the COM processor. Synchronization between the AD 100 and the IOCP is maintained through the use of a set of common flags.

The IOCP operates independent of the other proces- sors in the AD 100. It has an independent program counter and program memory. The user writes a low- level program, called an ADRIO program, to control it. It is the user's responsibility to synchronize the program running on the AD 100 and the program run- ning on the IOCP. The additional work this requires is more than offset by the added flexibility. The ADFUO program, or IOCP program, and the ADSIM program communicate through the dual-ported memory of the COM Processor. The user is able to set up common buffers between the two programs for passing data to and from the I/O rack to the ADSIM simulation. There are a series of common flags that can be used to syn- chronize the two programs.

The IOCP is a simple processor capable of seven types of instructions. Each instruction takes 100 nanoseconds to execute. Data transfer instructions are the most widely used of the IOCP1s instructions, which include moving data to and from the data buffer through float- to-fix hardware converters, float-to-logic converters, or paths with no conversion. The IOCP is also capable of logic operations on individual bits using its logic pro- cessor. The common flags can be manipulated in this fashion. The IOCP is tied directly to the I/O bus in the I/O rack. The bus is 16 data lines, 8 address lines, and 2 control lines. The 8 address lines allow up to 256 individual devices to be addressed in the I/O rack.

ADSIM Environment

With a specific application area in mind, namely real- time simulation, AD1 was able to design the AD 100's hardware and ADSIM to handle the necessities of the simulation environment. ADSIM is made up of a high- level simulation language and a run-time interactive control environment.

The ADSIM language is mathematically oriented. Many key elements of a typical simulation are built into the language, such as integration techniques, func- tion generation, and control system nonlinearity func- tions. A control executive consisting of two programs one that runs on the host controller and one that runs on the AD 100, provides the basis for implementing a model. The control structure built into this executive controls such parameters as system time (simulation time), frame time, and integration step size. A dynamic section is provided for the model's differential equa- tions. ADSIM allows the model to be implemented as a series of scalar and first-order differential equations. If conditional code is included as part of the model, the control executive takes care of padding the frame such that each frame is consistent with real time. Sort- ing of the dynamic equations and identifying algebraic loops are examples of some of the capabiites of the ADSIM compiler. Integration is handled using Runge Kutta methods, Adams Bashforth, or Adams Moulton system-level routines. The model development time is much less when a simulation language such as ADSIM is used since many of these standard simulation tech- niques are built into the language.

ADSIM program development including editing, com- piling, and debugging is performed on the host com- puter. There are two ADSIM compilers: one that pro- duces code to be executed on the AD 100 for time- critical work and one that produces code to be executed on the host computer for non-time-critical experimen- tation and debugging. The same ADSIM source can be processed by the two different compilers.

Running a program on the AD 100 involves loading the executable code from the host computer into the AD 100 a t run time. The user run-time interface con- sists of a program called INTERACT running on the host computer. INTERACT provides a user-friendly interface for debugging and experimentation, allowing constants to be changed, variables to be displayed, in- tegration methods changed, breakpoints to be set, etc. This environment reduces the time it takes to get the

simulation into a state where it can be integrated into the design and testing phase.

X-31 Simulation I m ~ l e m e n t a t i o n

The X-31 simulation implementation can be broken down into four phases or tasks. These tasks are listed as follows

a The Aircraft Dynamic Simulation (ADS)

a The Real-Time All-Digital Simulation (RTADS)

a The Flight Hardware-in-the-Loop Simulation (FHILS)

a The On-Aircraft Flight-Control System Validation

Each of these subtasks of the simulation implementa- tion will now be discussed in detail.

T h e Aircraft Dynamic Simulation (ADS)

The ADS version of the simulation was the original X-31 aircraft simulation program. The ADS program is a Rockwell NAAO proprietary internal digital simu- lation program, which may be used as an aid for per- forming flight-control system synthesis and analysis.

The ADS program is coded in FORTRAN IV on an IBM 370 computer. However, during the development of the X-31 simulation program, a version of ADS was modified by Rockwell personnel to run on the DEC VAX system operating under VMS. The program is designed to facilitate the digital simulation of aircraft and control system dynamics. Six-degree-of-freedom nonlinear equations of motion, angular rate transfor- mation equations, and angles are internally computed in the ADS program.

The ADS simulation program contains a library of rou- tines normally used in control system simulations; this library includes mathematical, switching logic, func- tion generators, limit functions, dead-zone, hysteresis, and component subroutines.

Many different types of systems can be simulated using ADS; however the major use for the program is aircraft simulation. The ADS program allows a user to develop the system model and then link this model into the ADS interactive shell for run-time analysis. This anal- ysis allows. the inspection and modification of system variables and an interactive method of developing sim- ulation time histories.

The first version of the X-31 aircraft was implemented in ADS employing a modular approach to simulation development. The modular approach allowed for a sys- tematic build of the X-31 simulation in both model complexity and fidelity. The results of the "final" ver- sion of the non-real-time ADS simulation then served as the "truth-model" for the subsequent real-time all- digital simulation, thus allowing for verification and validation of the RTADS software.

The Real-Time All-Digital Simulat ion (RTADS)

The RTADS phase of the simulation program is the setup prior to flight hardware delivery and is used for verification and validation of the real-time aircraft, the control laws, and for initial flying qualities evaluation.

The RTADS simulation was to be implemented on the Applied Dynamics AD 100 digital simulation com- puter using the ADSIM simulation language. Rockwell NAAO personnel determined that internal computer resocrces could not meet the implementation time and iteration rate requirements imposed by the X-31 pro- gram time-line schedule and system dynamics, respec- tively. Thus, the RTADS and FHILS phase work was subcontracted to the Applied Dynamics Applications Department. The time allowed for the RTADS con- version from ADS format t o the ADSIM format was five months, and this requirement was easily satisfied. As previously stated, the Rockwell requirement for the numerical integration of the model state equations is 2 milliseconds, and the sample time of the digital flight- control system is 20 milliseconds. The ADSIM model running on the AD 100 executed the equations in 680 microseconds; however, due to the sample time of the

digital controller set a t 20 milliseconds, an integration step of 1 millisecond was used in order to maintain an integer number of integrations per digital controller sample period. It should also be pointed out that this frame time includes all 1 / 0 requirements imposed by the RTADS phase of the simulation. These 1 /0 requirements include analog-to-digital and digital-to- analog converters, and discrete 1 / 0 systems which in- clude sense-line and control-line registers, a high-speed digital interface to the DEC VAX system to drive an MBT 1553 bus emulator that in turn drives the cockpit Head-UpDisplay (HUD), a high-speed digital interface to the Gould host system for the Evans and Sutherland CGI system to drive the simulation dome graphics, and a high-speed digital interface to the Sun 3 data acqui- sition system.

The RTADS phase simulated all aircraft systems. These include airframe equations, flight-control com- puter, actuators, engine, sensors, thrust vector, hinge, landing gear, and ground models. To get a better feel for the overall complexity of the model, a number of specifics are presented below

0 Equipment used

- Applied Dynamics AD 100 with Function Memory Unit (FMU) and analog and digital 1/0 system

- Digital Equipment Corporation VAX 11/780

- Evans and Sutherland CT-6 with Gould Host System

- mock-up cockpit with flight instruments

- 36-foot diameter Simulation Dome

- Sun 3 Data Acquisition System

- MBT 1553 Bus Emulator

- three 8-Channel Strip Chart Recorders

- McFadden Feel System

0 Simulation Program Summary

- 64 state variables

- 1382 algebraic variables

- 46 generated functions of 1 independent vari- able

- 29 generated functions of 2 independent vari- ables

- 55 generated functions of 3 independent vari- ables

- 3 generated functions of 4 independent vari- ables

- A total of over 200,000 generated function data points

The RTADS phase also required the ability for a user to interactively trim the X-31 aircraft at an arbitrary set of flight conditions. These included the ability to trim the aircraft both longitudinally and laterally. It was de- cided to use the ADS non-real-time model to trim the aircraft and to down load the control surface deflections to the AD 100. This required the "splicingn of ADS to the ADSIM run-time environment named INTER- ACT. Since both ADS and INTERACT are written in FORTRAN, this process, with the help of Rockwell en- gineers, did not pose a problem. This also provided a cross check between the ADS model and the ADSIM model: if the aircraft is trimmed in one model exe- cuting on one system and trimming results are down loaded to a second model executing on a second sys- tem, both aircraft should remain in trimmed flight.

The major problems encountered during the conver- sion process from the ADS FORTRAN to ADSIM were predictable. These problems are inherent in a program- ming language such as FORTRAN and simply do not manifest themselves in a simulation language such as ADSIM. The problems included improperly ordered dynamic equations in the FORTRAN; ADSIM equa- tions are automatically sorted. This resulted in a cor- rectly ordered FORTRAN code. Another problem was improperly equivalenced FORTRAN common areas; in ADSIM all variables are global, and there is no need for common areas. This prompted us to correct the ADS FORTRAN code. The truth of the matter was that Rockwell NAAO ended up with a better X-31 model than they had before the RTADS project started. Keep

in mind however that the ADS model with X-31 code is an extremely large piece of FORTRAN code developed over many years. These comments are not to detract from the utility of or to criticize the X-31 ADS model or the developers; it is simply a fact that a good simula- tion language will help one to find problems in a model that might otherwise go undetected in a FORTRAN- based simulation.

A diagram depicting the RTADS X-31 real-time simu- lation hardware configuration is shown in Figure 1.

T h e Fl ight Hardware-in-the-Loop Simulat ion (FHILS)

The FHILS phase of the simulation implementation is an outgrowth of the RTADS phase. This phase of the simulation will be used for the final validation of the flight-control system (FCS) hardware and software in the laboratory before the installation of the FCS and software into the X-31 aircraft. In addition, evaluation of the system design for compliance with flight control, human factors, flight test objectives, and pilot training are also major objectives of the FHILS task.

A piece of equipment developed by Honeywell provides the interfaces between most of the FHILS simulation system. This piece of hardware, named the System Test Console (STC), provides the interface between the FCS, the cockpit, the system test equipment and the real-time simulation of the aircraft dynamics on the AD 100. Malfunction insertion capability for the test of the redundancy management system is also provided. In short, all systems that can be reasonably replaced by actual hardware and software systems are inserted into the FHILS simulation and removed from the ADSIM RTADS simulation code.

The STC is a VMEbus-based system. The interface between the STC and the AD 100 is accomplished via a high-speed digital interface provided by AD1 (a dual- ported memory with DEC D R l l protocol) and a VME- bus to DR11-W interface provided by VME Microsys- tem International Corporation (VMIC). Software pro-

tocols developed jointly by Honeywell and Applied Dy- namics allow for a high-speed real-time communication between these vastly different computer systems. Data format for the STC is IEEE-754 single precision for- mat, and conversion from the AD 100 internal format to the STC system is performed by the AD 100 in a minimal amount of time.

The Evans and Sutherland with Gould host system is still driven by the AD 100 directly for implementation of the flight dome graphics in the FHILS phase. The AD 100 also communicates with the Sun 3 system for data acquisition and drives the three 8-channel strip chart recorders for the purpose of a real-time monitor of important simulation parameters.

As the implementation of the FHILS task is not yet completed a t the time this paper has been written, specifics about the problems encountered, frame times and other areas of interest are not yet available.

A diagram depicting the FHILS X-31 realtime simula- tion hardware configuration is shown in Figure 2.

The On-Aircraft Flight Control System Valida- t ion

This last phase of the simulation program allows for final validation of the Flight Control Computer as in- stalled on the aircraft while sitting on the runway. The System Test Console has been designed with this phase of the simulation in mind, as this piece of equipment can be rolled out onto the runway and interfaced to the on-board FCC. Open and closed loop test of the FCC may be performed via the STC interface. These "strap- down" tests may be performed with and without the engine running. Again, the FCC provides the interface for fault insertion to most of the X-31 on-board com- puter systems for the purpose of, among other things, the evaluation of the redundancy management systems

PI.

Results

The ADS version of the X-31 aircraft simulation was successfully converted to the RTADS simulation by Ap- plied Dynamics personnel in the required time period and with the desired iteration rate requirements. Dy- namic fidelity of the X-31 model was increased during the conversion process. A frame time of 680 microsec- onds was achieved by using the ADSIM simulation lan- guage and AD 100 system. Input/output requirements were easily satisfied and verified by Rockwell NAAO personnel.

The work on the FHILS version of the simulation is underway at the time this paper is being written (June 1989). To summarize the FHILS version of the model, one takes the RTADS model and basically eliminates the software controller and actuators. These systems will be replaced by the STC along with the actual hard- ware (FCS and analog simulation of aircraft actuators). Since we in Ann Arbor do not have the STC and related systems, the following approach has been taken. Using two AD 100 systems, the analogous environment is cre- ated: basically using a single AD 100 to simulate the FCS and actuators and the second AD 100 to simulate the airframe dynamics. This has been done in real-time in Ann Arbor and has produced the same results as when the whole system was on a single AD 100. Thus, when we are on-site at Rockwell NAAO, we should need only to plug in the STC and debug the model from there, safe in knowledge that the system has already performed in a predictable manner a t least with the second AD 100.

Alternative Implementation Methods

Since most people who work in an engineering en- vironment are not paid to continually reinvent the wheel, i t is extremely important that simulation mod- els, functions, and subsystems of a project can be shared by groups of people. ADSIM allows personal libraries, project-related libraries, or even department- and company-wide libraries, which may contain fre- quently used functions and models. Furthermore, it

1 is possible to set up simulation executives, which are called EXECUTE pairs. A simulation executive is the outer layer of a simulation that takes care of macro- scopic phenomena like synchronization of the simu- lation with the outside world, graphics, starting and stopping the simulation, and the order in which cer- tain combinations of dynamic systems are solved. For example, in a mixed-data system, the continuous-time part will be solved on a frame-by-frame basis, while the discrete-time part will only be solved every T, sec- onds. An EXECUTE pair can control the relations between the continuous-time and discrete-time subsys- tem in a meaningful fashion. In the case of the X-31 simulation, an EXECUTE pair could simplify the inter- actions between the discrete-time model of the flight- control system and the continuous-time model for the airframe. However, the methodology explained in this section was not used for the X-31 simulation.

An EXECUTE pair is defined as two separate ADSIM blocks; a simulation executive named SIMEXEC and an interactive executive named INTEXEC. The SIMEXEC block is written in ADSIM and defines the order of execution of blocks in the user's ADSIM pro- gram. The INTEXEC block is a FORTRAN subrou- tine which is linked into and called by the INTERACT process. The INTEXEC subroutine allows a user to execute user-written FOIYTRAN code before and after the AD 100 is started or halted. The INTEXEC sub- routine also starts the AD 100 simulation beginning with the control structure as defined in the SIMEXEC block. Since the simulation executives are written in high-level languages, they are readily modified by the user. Three simulation executives are currently avail- able with the ADSIM software. These are:

0 An EXECUTE pair for continuous system simula- tion [I]

An EXECUTE pair for multiple-frame-rate inte- gration [2]

0 An EXECUTE pair for mixed-data system simu- lation [5]

The EXECUTE pair for continuous system simulation is used in ADSIM programs with a single dynamic block named DYNAMIC continuous. The ordinary dif- ferential equations representing the system to be sim- ulated are simply placed into the dynamic block, The ADSIM compiler sorts the equations into the proper order to ensure correct evaluation of all quantities. All differential equations are integrated with a single in- tegration step size. For real-time simulation, this in- tegration step size is set equal to the amount of time it takes the AD 100 to execute a single frame. This task is transparent to the user and is performed by the INTERACT task. The general format of ADSIM programs using EXECUTE continuous follows:

TITLE (Simulation T i t l e}

D Y N A M I C continuous

( D i f f e r e n t i a l and a lgeb ra i c equat ions t o represent continuous time systems. )

END DYNAMIC continuous

EXECUTE 'continuousJ

The EXECUTE pair for mixed-data system simulation, named EXECUTE mixed-data, is also used in ADSIM programs along with two dynamic blocks. Simula- tions of this nature are easily partitioned into two or more subsystems. One subsystem consists of algebraic and difference equations that represent the digital or discrete-time control laws. The other subsystem con- sists of the algebraic and differential equations that describe the behavior of the continuous time system. When creating the control structure for simulation of mixed-data systems, the following factors should be considered:

0 Numerical integration of discontinuities introdu- ced by the digital controller residing in the continuous-time subsystem

0 Selection of numerical integration methods

Adjustment of either the sample period or integr* tion step size

0 Representation of computational delay in the dig- ( Difference and a lgebra ic equations ital subsystem t o represent d i g i t a l c o n t r o l l e r . 3

The first point to take into consideration is the selec- DYNAMIC discrete tion of the integration method. Single-step predictor- type methods that use the current and past deriva- DYNAMIC continuous tives t o predict the new state values do so under the presumption of continuous derivatives. This presump Differential and algebraic equations tion does not hold when simulating mixed-data sys- t o represent continuous-time p l a n t . 3 terns. Strong discontinuites are introduced by the con- trol command as determined by the discrete time sys- END continuous tem. Self-starting methods, such as the classical, multi- - step Runge Kutta second-, third- and fourth-order va- riety, do not rely on this assumption, and thus these methods will be used. However, the classical Runge Kutta methods are not suited for real-time simulation as these methods require external inputs to the inte- gration method before they become available in time. At Applied Dynamics we have anticipated this problem and developed our own Runge Kutta real-time meth- ods with similar accuracy and stability characteristics as the traditional versions. See [I] and [5] for details.

Another consideration is the correct simulation of the digital controllers computational delay. Actual micro- processor hardware does not produce control action to the continuous system instantaneously. The most common method is to compute the control effort and output as soon as the results become available. How- ever, when simulating delay time, the lag must be an integer multiple of the continuous-system integration step size. If you have an estimate of the computational delay for your particular piece of hardware, EXECUTE mixed-data will allow you to simulate the effect of

EXECUTE 'mixed-data ' Figure 4 shows the control structure provided by EXECUTE mixed-dat a.

Let us consider an example of a mixed-data system sim- ulation using ADSIM and EXECUTE mixed-data. The system simulated is a simple second-order closed-loop system with a digital PID type controller. Errors intro- duced due to the digital-to-analog (D/A) and analog- to-digital (A/D) converters are also modelled by invok- ing a standard ADSIM model named quant izer [I]. Scaling of the input and output quantities is also per- formed, as would be needed if actual controller hard- ware were to be used. The system simulated is shown in Figure 5.

The digital controller transfer function, D(z), is defined using z-transform notation and has the following form:

both fixed and time-var~ing On The continuous-time transfer function, H ( $ ) , is defined your Figure the re- using Laplace transform notation and has the following lation of delay time to the sample time. form:

The general format for ADSIM programs using the con- x ( s ) H(a) = - - K , trol structure of EXECUTE mixed-data follows: M(s) - (71s + l ) ( ~ + 1) (2)

TITLE {Simulation T i t l e 3

DYNAMIC d i s c r e t e

The ADSIM language supports both continuous- time derivatives and discrete-time difference equations. Therefore, the above defined transfer functions, D(z) and H(s), are simply converted to ADSIM notation

and placed into the discrete and continuous dynamic blocks, respectively. Note that the transfer function for

method r k r t 2

a zero-order hold is not represented in either the block diagram or in the ADSIM program. The reason for this is that the simulation control structure as defined by the SIMEXEC block in the EXECUTE mixed-data pair supplies this effect implicitly. The following program fragment displays the use and the invocation of the EXECUTE pair by the EXECUTE mixed-data state- ment.

TITLE "Plant & d i g i t a l con t ro l l e r "

(* Scale and quant ize c o n t r o l l e r ou tput , m *)

(* Second order p l a n t equat ions *)

(* D i g i t a l c o n t r o l l e r d i f f e r ence equat ions *) end dynamic c o n t h ~ ~ o u s

dynamic d i s c r e t e (* Specify d e f a u l t d a t a s e t *)

(* Generate re ference p o s i t i o n *) da ta t a u 1 = 4.0, ...

xref = test~signal(s~time,system~time) (* Specify c o n t r o l l e r cons tan ts *)

(* Scale and quant ize i npu t , x *) da ta b l = 0.540, b2 = 0.460, ...

(* Generate e r r o r s i g n a l and sequence *)

(* Specify s imula t ion run s p e c i f i c a t i o n s *)

runspecs endtime = 10.0, sampletime = 1.0 , frametime = 50.06-6, delaytime = 10.0e-3, speedup = 1 . 0

(* Execute p a i r f o r mixed-data s imula t ion *)

(* Generate c o n t r o l s i g n a l and sequence *) execute "mixed-data"

Conclusions.

end dynamic d i s c r e t e The performance numbers of the AD 100 show that it is possible to implement a high-performance aircraft

(* Second order p l a n t d i f f e r e n t i a l equat ions like the X-31 in a real-time hardware-in-the-loop simu- * lation without the problems associated with an imple-

mentation on a general purpose digital computer using dynamic continuous FORTRAN. It has also been shown that the use of spe-

cialized EXECUTE pairs can simplify the implementa-

tion effort of systems with digital controllers governing continuous time systems.

References

[I] ADSIM Reference Manual Version 6.1. ADI, Ann Arbor, MI, 1989.

[2] Haraldsdottir, A., and Howe, R.M. Multiple Frame Rate Integration. AIAA Flight Simulation Tech- nologies Conference, September 1988.

[3] Snyder, G. The X-31-A Aircraft Flight Hardware- in-the-Loop Simulation. Applied Dynamics Inter- national Users Society Conference, Keystone, CO, June 1989.

[4] Wright, M. System 100 Simulation Computer Ar- chitecture. European Simulation Multiconference, June 1989.

[5] Zammit, S., and Zwaanenburg K. Simulation of Mized-Data Systems Using the Applied Dynamics Simulation Language ADSIM. European Simula- tion Multiconference, June 1989.

Hard D isk c Tape D r i v e c

Opera to r Console c

VAX 11/780 I AD 1 00 Hos t I S i m u l a t i o n

Con t ro l

Bus E m u l a t o r S i m u l a t i o n

M o n i t o r

P r i n t e r P Applied

Dynamics Osc i 1 1 oscope AD 100

S t r i p Cha r t c Real -T ime S i m u l a t i o n

Aerodynamics A c t u a t o r s

Sensors Propu ls ion

Con t ro l L a w s

S t i c k and T h r o t t l e P o s i t i o n s and D i s c r e t e s I Pedal P o s i t i o n

Ex te rna l V i s u a l s Dome CGI D isp lay D isp lay

Processor

Figure 1: RTADS simulation hardware configuration.

VAX 11/780

AD 100 Hos t

S i m u l a t i o n Con t ro l

S i m u l a t i o n

App l i ed Dynamics

Osc i 1 l oscope AD 100

Rea l -T ime S i m u l a t i o n

Aerodynamics Sensors

P ropu l s i on

Bus E m u l a t o r

P i l o t Con t ro l

S t i c k and T h r o t t l e P o s i t i o n s and D i s c r e t e s

Rudder Feel Sys tem Pedal P o s i t i o n

F a u l t I n s e r t i o n A c t u a t o r Dynamics Opera to r Console Ex te rna l l e c t r i c a l CompatJ V i s u a l s Dome CGI

D i sp lay D i sp lay Processor

I

Computer F l i g h t Con t ro l L a w s Figure 2: FHILS simulation hardware configuration

Redundancy Management

Ielay Time -

r--- Sample Time- Sample Time- Sample Time-+

Figure 3: Relation of delay time and sample time.

Figure 5: Mixed-data system.

* E M* M X

- -a D(z)

t D-A G(s) b

initialize simulation

dynamic continuous

\ / I increment I

1 Figure 4: Control structure of EXECUTE

continuous

mixed