SIMULATION TECHNOLOGY FOR FREE FLIGHT SYSTEM PERFORMANCE AND SURVIVABILITY ANALYSIS

Transcription

1 SIMULATION TECHNOLOGY FOR FREE FLIGHT SYSTEM PERFORMANCE AND SURVIVABILITY ANALYSIS John C Knight, Stavan M Parikh, University of Virginia, Charlottesville, VA Abstract Before new automated technologies can be incorporated into the air-traffic-management system, they need to be analyzed and tested extensively. This analysis and testing is required not only to demonstrate functionality, but also to determine overall system performance and dependability. The risks and costs of operational testing preclude its routine use, especially to test system survivability where intentional serious failures will be forced to occur to ensure that they are handled properly. Fortunately, simulation provides a practical alternative. This paper describes a simulation system designed to assess the performance and survivability of various automated technologies in terminal area flight. It also presents some preliminary results of the system s use. Introduction The Federal Aviation Administration (FAA) expects air traffic to double by the year 2025 [1]. To avoid overwhelming current facilities, the FAA has launched a modernization program called Free Flight, with the goal of increasing automation in all areas of flight, including terminal area [2]. The first stage of automating terminal area entails developing self-spacing algorithms for terminal-area flight. The safety criticality of ATC system components requires that all new automation technologies, including self-spacing, undergo extensive testing and analysis before their incorporation into the ATC system. Simulation allows the modeling of costly and high-risk settings in a low cost and risk free environment. This paper describes the Flight Automation & Performance Simulator (FLAPS), developed to provide a platform to test Free Flight algorithms in a realistic traffic environment. FLAPS is a generalpurpose simulator for rapid prototyping of different algorithms, analysis of various algorithm features, visualization of flight, and testing of a system s ability to survive catastrophic failures. The FLAPS software generates a variety of output data that can be used to visualize flight motion and the behavior of Free Flight algorithms. The data can be filtered and stored in a database for further analysis at a later time. This paper is organized as follows: In the next section, the FLAPS system is summarized. To provide an example of the use of FLAPS, we then present a preliminary analysis of a terminal-area self-spacing algorithm developed at NASA s Langley Research Center (LARC) [3]. Finally, we present our conclusions. The FLAPS System Overview The FLAPS system is a flexible and easily extensible platform for rapid prototyping, performance investigation, and survivability analysis of Free Flight algorithms. It is designed to execute on any typical modern workstation running Microsoft Windows 2000 or later. The high-level architecture is shown in Figure 1. The basic mechanism for simulation that the system provides is the ability to model quickly and easily any number of arbitrary objects together with any desired interaction between the objects being modeled. Thus, for example, individual aircraft and relevant ground services can be modeled as objects and communication modeled as interactions. More complex structures can be modeled using the basic facilities as building blocks. Thus, for example, a single aircraft that has radio links with other aircraft and with the ground can be modeled as a set of basic objects with a communication topology that reflects the radio links. Ease of use of this facility is obtained by automatic creation of the objects and their interactions from a specification contained in an input file. 1

2 Since we are interested in being able to investigate any ATC algorithm from a centralized system operating on the ground to a fully distributed system housed onboard the aircraft, we have to be able to describe the requisite algorithms in a convenient way. Rather that trying to use an existing simulation language or inventing a new one, we chose to exploit the inherent generality of a familiar programming language (C++). Thus, generality is achieved by allowing the user to program the actions of each object in C++. The code developed by the user is specific to each type of object in the simulation, and so if there are three object types (two types of aircraft and a groundbased system, for example) then the user prepares only three fragments of code even if there are thousands of objects in the simulation. FLAPS maintains a virtual clock in order to provide a mechanism for sequencing and for modeling loads. Event ordering is guaranteed by the clock but simulations can use the clock directly to simulate loads. For example, any object can control the rate at which its software executes by periodically stopping execution until the clock Figure 1: FLAPS Software Structure ticks. In this way, processing load can be modeled. Communication loads and delays can be modeled using the virtual clock also. Any transmission from one object to another can be forced to be delivered after a specified delay if the originating object chooses. An important research topic that we wish to address with FLAPS is the survivability of new ATC system designs. Survivability is precisely defined elsewhere [4], but, informally, what we mean by the term is the ability of a system to provide critical services after some serious form of damage has occurred. The types of damage of interest include major power failures, loss of a critical radar, loss of part of the communications infrastructure, and so on. If such events occur during operation, it is essential that the system behave in a predictable and safe manner. Any data that is generated during a simulation can be captured and stored in an Access database rather than in a file. Visualization of results can be obtained by taking the output data stream and 2

3 feeding it to either a display that is part of FLAPS or a display program that the user supplies. Architecture FLAPS was built using a network simulation system called RAPTOR that was developed at the University of Virginia [5]. The key mechanism that RAPTOR provides is the implementation of the objects and their interactions. Objects are programs that are built from the code fragments supplied by the user. These programs are then executed as threads that are created by RAPTOR with one thread being created for each object. This thread implementation of objects is critical because it ensures that the objects operate in a truly concurrent way. Thus the inherent non-determinism that is present in any real system is present in the model. Another major advantage that the threaded implementation provides is full utilization of the actual hardware upon which the simulation is being executed. Since the threads are dispatched by the operating system and in most simulations there are a large number of threads (objects), all available processing units will be kept as busy as it is possible to keep them. Interaction between objects is implemented by in-memory message passing. Any object can communicate with any other by writing a message into the target object s input message buffer. This is an extremely efficient mechanism that facilitates rapid simulation. The mechanism for delaying message delivery to simulate load merely diverts messages until the clock advances, and it imposes no significant overhead. In many cases, the specific architecture of a collection of aircraft required for a simulation will be standard. For example, some number of aircraft are required to move through the ATC system in a terminal area of interest, and each aircraft has the same communications structure. To simplify the creation of such simulations, FLAPS has an external utility that generates the necessary topology and connections file from just the number of airplanes required. Airspace While RAPTOR forms the core of the system, the Airspace component is what allows the realistic portrayal of flight by the simulator. Airspace provides a mechanism for specifying a flight area that can be represented accurately by the simulator. Airspace has three major components: airport, airroutes, and airplane types. These three combine together to allow users of the FLAPS software to model flight for any airspace they wish to study. 1. Airport: The airport component takes input from an airport data file that specifies the entry points to the airspace, runways if any are present, and the four corners marking the boundary of this airspace. In addition, it allows for the specification of runway names and locations, and for the aircraft loads that each of the runways experience as a percentage of the total for the airport. These parameters combine to provide a complete description of an airport. This file is also used by the display to generate maps of the airspace dynamically [6]. 2. Air-routes: While the airport file sets up the entry points and runway points, the air-routes file provides a way to define specific routes from entry to runway. If a user is not simulating terminal area then air-routes just define the routes an airplane needs to follow as it flies through the airspace. Figure 2 provides an illustration of the Dallas-Fort Worth (DFW) routes to runway 36L for airplanes flying under instrument flight rules (IFR) from all entrypoints to the terminal area. 3. Airplane Types: As the name suggests this component defines different airplane types and their characteristics such as speed limitations, vortex separation requirements, and such. This data is used by the model control to generate different airplane types as per specified traffic trends and by the airplane functions to model airplane flight realistically taking into account different airplane capabilities. 3

4 Figure 2: Routing from Entry Point to Runway (DFW 36L IFR) Model control Model Control provides a mechanism whereby the user manages the flow of airplanes through the airspace in FLAPS. To simulate realistic air traffic, it is necessary to control the threads representing the airplanes, i.e. there needs to be a mechanism for specifying when an airplane enters the airspace. There also needs to be a mechanism to specify the overall traffic in the airspace, the distribution of types of airplanes present, the direction of the flow of aircraft and the runways available for use. The model control component carries out these functions. It sends messages to the different airplane threads that activates them at different times during the simulation and supplies them with information such as where the airplane enters the airspace, which runway it is flying to, and what the airplane type is. The model control takes its input from a simulation parameters file that defines the distribution of aircraft, the traffic loads required, and the total simulation time. The simulation parameters provide the basic framework the selection of the airplane type, entry point and runway for each airplane is done randomly by this component based on probabilities provided in the parameters file. Virtual Airspace While the Airspace component allows the user to specify the structure of the airspace, the internal representation of the airspace structure is stored in the Virtual Airspace component. A grid is generated for the specified airspace on which the entry points merge points, runways, and air-routes are marked. As airplanes enter and leave the airspace, Virtual Airspace keeps track of their positions by marking them on the grid. Airplanes can retrieve information of leading and trailing aircraft, as well as violations in separation distance by querying this component. A partial history of the positions of all airplanes in the airspace is stored in Virtual Airspace as this data might be required by various automation algorithms. The Virtual Airspace component provides a way to hide the details of airplane motion because each aircraft is provided with a new position when it presents its velocity and time of flight. This allows for easy refinement of the motion engine in the future. Virtual Airspace provides a central place from which airplanes as part of the simulation can request traffic information and figure out the status of the surrounding environment along with providing a mechanism to abstract airplane motion. Processes Processes refer to the individual threads that are created by RAPTOR based on the topology file. There are two main types of thread currently present in FLAPS: the airplane function and the ground control function. The airplane function models the workings of an airplane while the ground control function models the working of controllers. Airplane Function: Each airplane defined in the topology file is associated with an airplane function. The main characteristics of the airplane function include: (1) waiting on an activation message from ground before entering the airspace; (2) carrying out the necessary communication between surrounding airplanes and with the ground; and (3) the actual implementation of different automation algorithms such as self-spacing. Thus, this function is responsible for generating the speed advisories that are passed to virtual airspace to move the airplane. Finally, this function also 4

5 handles generating data as required for any external output. Ground Control Function This function provides all the functionality of the control tower or ATC center controlling the particular airspace. For the purposes of self-spacing, for example, ground control is responsible for providing sequence numbers to the airplanes as they enter the airspace. Vulnerabilities & Symptoms One of the key features that FLAPS provides is the ability to test the survivability of individual algorithms as well as the system as a whole. To permit experimentation with survivability, FLAPS includes two important facilities. The first is the ability to associate specific vulnerabilities with specific objects in the system. A vulnerability is a potential problem that might occur in a component. For example, a ground-based communications unit that did not have back-up power would be vulnerable to a failure of commercial power. Similarly, an aircraft with a failed TCAS unit would be vulnerable to a collision. Note that a vulnerability does not mean that the associated problem will happen. It merely means that if the necessary circumstances arose, a situation referred to as a threat, a failure would almost certainly occur. Were a component not vulnerable, the occurrence of a threat would not lead to a failure. Objects in a FLAPS model can be made vulnerable to any threats that the user chooses. There are no predefined vulnerabilities. Vulnerabilities of interest are defined in an input file along with the objects that the user wishes to have those vulnerabilities. Objects can be identified specifically or stochastically. The second important facility that allows experimentation with survivability is the ability to generate symptoms during simulation. Note that the term used is symptoms and not faults. The idea is to allow the user to introduce the important symptoms that result from a fault. Thus, for example, a symptom might be loss of commercial power to a radar site where the fault is the loss of a generator. If the radar site had previously been identified as vulnerable to this circumstance, then the effects of the loss of power would be manifested. What those effects are is determined by the user-supplied software for the affected component. Output: For the simulator to be useful, it is necessary that a user be able to capture and visualize the data being generated. For modeling of self spacing, for example, the data of interest might include airplane motion information, leading and trailing airplanes, number of conflicts, path deviations, and time to runway. FLAPS provides a default display facility that operates on a computer that is separate from the one being used for simulation [6]. Data is supplied to the display using a socket connection thereby allowing the hosts for simulation and display to be different. We have found that developing displays in Visual Basic is so simple (starting with a standard template) that there is no value in having a comprehensive display capability. The FLAPS display has several features, and if they are not what is needed, a customized display is easy to build and integrate. Data generated during simulation can be stored in an Access database, also on a separate host. This facility permits post-simulation analysis using simple database queries and all of the computation and graphing capability of Access. This approach is much more flexible and simpler than requiring explicit programming by the user. FLAPS & Self-Spacing Since FLAPS was developed as a platform for analysis of Free Flight algorithms, the system was evaluated by developing a prototype of a particular self-spacing algorithm. Self-spacing allows each airplane to maintain spacing between itself and traffic without assistance from ground control. Self-Spacing Algorithm: The current research on self-spacing algorithms that operate onboard individual airplanes and provide speed advisories is limited. The primary algorithm being considered today within the Distributed Air Ground Traffic Management (DAG-TM) concept was developed by Abbott [7]. Abbott s self-spacing algorithm is based on the concept of time-to-go spacing [3]. The idea behind 5

6 time-to-go spacing is for each aircraft to follow traffic with a time separation of a predefined amount. For example if the predefined separation time is, and the present time is t, then any given aircraft should be at the same location at time t as traffic was at time t-. Figure 3 illustrates the timeto-go concept. Speed Ownship Current Ownship Position Range Error Distance-to-go Traffic Nominal Profile Traffic time ago Figure 3: Time-to-go Concept Current Traffic Position The difference in the location of any particular aircraft at time t and its expected location according to time-to-go spacing is known as the range error. Normally airplanes are expected to follow the nominal speed profile of a route as illustrated in Figure 3. However, when a range error is present the airplane needs to deviate from the nominal speed to correct this error. The self-spacing algorithm places a restriction on the amount of deviation that is allowed from the nominal speed; normally restricted to within a 10% of the nominal speed to keep the airplane within a reasonable deviation from the regulation speeds of the airspace. It is possible that these restrictions may cause an airplane to fail to meet the spacing requirements. This approach to self spacing can be stated algebraically as [3]: (3.1) Speed = BaseSpeed + SpeedError (3.2) Speed Error = 0.01 X Gain1 X RangeError Gain2 X DeltaAcceleration (3.3) RangeError = TrafficPosition BasePosition (3.4) DeltaAcceleration = OwnshipAcceleration TrafficAcceleration The actual speed of the airplane to achieve time spacing of is calculated by equation 3.1. The data necessary for computing the speed is provided by the computation of equations 3.2, 3.3, and 3.4. In 3.1, BaseSpeed is either the nominal speed for the given route or the traffic speed if time separation between ownship and traffic is close to. In 3.3, BasePosition is the traffic position at t- or target position based on minimum separation distance. Gain1 and Gain2, empirical constants determined by Abbott, are 2.5 /ft and 2.5 sec respectively [3]. To allow the airplane to remain within the regulated speed bound around the nominal speed a check needs to be implemented in the algorithm. This is applied by encoding equation 3.5: (3.5) if (Speed > Nominal Speed + Speed Deviation) Speed = Nominal Speed + Speed Deviation if (Speed < Nominal Speed Speed Deviation) Speed = Nominal Speed Speed Deviation Along with restricting the total maximum deviation from the nominal speed over the duration of the flight, the algorithm also places restriction on the maximum change in velocity during any given speed command. This is to provide reasonable acceleration/deceleration for maintaining smooth flight. The FLAPS simulator implements this by using equation 3.6: (3.6) if (Speed Error > Speed Limit) Speed Error = Speed Limit if (Speed Error < Speed Limit) Speed Error = Speed Limit These equations combine to provide an implementation of the self-spacing algorithm. Along with analyzing this algorithm for functionality, its implementation was also used for evaluating the FLAPS simulator. Results & Analysis: Abbott s self-spacing algorithm was written for spacing airplanes over a single route with no merges, so FLAPS was configured to use only a single route. The airspace selected was Dallas Fort-Worth (DFW) terminal area as it is used extensively as a case study in the research literature. The specific route choice was the route from entry-point BAMBE to runway 36L 6

7 based on Instrument Flight Rules (IFR) as shown in Figure 2. The algorithm analysis involved implementing the above algorithm in the speed generation section of the airplane function. Upon implementation, the simulation was run with different numbers of airplanes over different lengths of time to see the number of conflicts the airplanes faced. Figure 4 displays a screen shot of the self-spacing algorithm in action. The circles indicate the required separation around each airplane. An airplane is considered to be in conflict when a particular airplane s circle overlaps another airplane, as can be seen in airplanes numbers 3, 4, and 5 in Figure 4. By using the data collection capabilities of FLAPS, the positions over time of all the airplanes in flight were stored, and a closer examination of the separation distance variation between airplanes undertaken. Example data of separation between 8 Spacing between 3 and 4 Figure 4: Self Spacing Example Display airplanes 3 and 4 shown in Figure 4 is provided in Figure 5. Figure 5a shows the variation of separation distance over the entire flight time. A closer view of parts of this graph is shown in Figure 5b and Figure 5c. 8 Spacing between 3 and Time (a) Time (b) Spacing between 3 and Time (c) Figure 5: Spacing between pair of airplanes 7

8 First, note the sudden jumps in the separation distance in Figure 5a. These jumps are due to the fact that, at these positions, the traffic airplane has turned on to the next segment and the distance calculations at these turns cause what seem to be sudden perturbations. Based on looking at the simulation in action these can be ignored. For most of the time there are small perturbations in speed as seen in Figure 5b. Most of the perturbations are right at the border of separation distance which ends up causing loss of separation. Furthermore such continuous changes in speed are not recommended from the human factors point of view. The algorithm could be modified easily to compensate for this behavior. A broader look at performance is provided in Table 1. Conflicts listed in Table 1 are average values based on simulation runs, in the above described environment, for 30 minutes of real time, repeated 20 times. The simulation was carried out for a maximum of 10, 25, and 50 airplanes. As the data suggests the number of conflicts increase with higher traffic levels. Airplanes Conflicts Table 1: Self-Spacing Results One of the important observations about the self-spacing algorithm is that the number of conflicts varies greatly based on traffic distribution in each simulation, which is randomly generated. Another observation made based on viewing the display is that, due to speed limitations, airplanes were unable to slowdown fast enough to avoid conflict once they were sped up to overcome the range error. A modification that induces speed decrease at an earlier point in the algorithm could be used to deal with this. Furthermore, techniques other than speed modification could be used to assist in achieving the correct spacing. For example using horizontal maneuvering that would increase or decrease path length as necessary would help control spacing [7]. Considerable development remains to be done in developing better solutions for automating flight management. This analysis helped provided some preliminary insight into the spacing algorithm that was studied as well as enabling an exploration of the capabilities of FLAPS. The algorithm was implemented easily in FLAPS and the specific flight and traffic profiles defined simply. FLAPS is a useful platform for testing various free-flight algorithms. Conclusion The Flight Automation & Performance Simulator provides a platform for simulation modeling of different flight-management automation algorithms. These models can then be used to test individual algorithms for functionality, feasibility, performance, and survivability. It also provides a simple way to implement and evaluate multiple automation algorithms that interact, such as self spacing and merging, in a realistic environment. The major strengths of FLAPS include the capability to accurately represent different airspaces, to model an arbitrary number of airplanes, to control airplane density over time in the airspace, to represent different airplane types along with their limitations, and to model a wide variety of system failures. FLAPS capability for survivability analysis is a central facility. Once an automation system is introduced into general use, the system needs to be dependable in all circumstances. The nature of software is such that it is easy to miss critical cases during testing, especially the cases involving interactions with other external systems. The ability to deliberately have external and internal components fail and to study the resulting behavior of algorithm provides a unique capability. In order to provide a preliminary evaluation of the system, a model of a self-spacing algorithm was developed. The self-spacing algorithm was written for spacing airplanes flying on a single fixed path within terminal area from an entry point to the runway. At present, it does not handle merging or multiple runways. The preliminary results of the algorithm analysis indicate that the algorithm as simulated probably will need some enhancement because the numbers of conflicts between airplanes on a single route are high. 8

9 Acknowledgements This research was funded in part by the National Aeronautics and Space Administration under grant number under NAG References [1] September 2001, APO Data System, Federal Aviation Administration, [2] September 2001, Free Flight, Federal Aviation Administration, [3] Abbott, Terence, 2001, Advanced Speed Control Law for Airborne, In-Trail Separation, Hampton, VA, Distributed Air/Ground Traffic Management Research Initiative, NASA s Langley Research Center. [4] Knight, John, Kevin Sullivan, 2000, On the Definition of Survivability, University of Virginia, Department of Computer Science, Technical Report CS-TR-33-00, ch.report pdf [5] Jun 2001, Raptor Simulator, Survivability Research Group, University of Virginia, [6] Rowe, Brian, 2002, Design and Implementation of a Display Device for Models of Free Flight Algorithms, Senior Thesis, School of Engineering and Applied Science, University of Virginia. [7] NASA Langley Research Center, 2000, Distributed Air/Ground Traffic Management Concept Element 11 Research Plan, Hampton, VA, Distributed Air/Ground Traffic Management Research Initiative. 9