Modeling and Evaluating ATM Procedures in Human-in-the-Loop Simulations on the Example of the Hamburg Airport Operations

Transcription

1 Modeling and Evaluating ATM Procedures in Human-in-the-Loop Simulations on the Example of the Hamburg Airport Operations Thomas GRÄUPL a,1, Carl-Herbert ROKITANSKY a, Theodor ZEH b, and Amela KARAHASANOVIĆ c a University of Salzburg, Salzburg, Austria b Frequentis, Vienna, Austria c SINTEF ICT, Oslo, Norway Abstract. Improvement of air traffic management procedures might help in coping with the expected growth in air traffic and requests for increased safety, predictability, and efficiency of the European air transportation system. This paper describes a simulation-based approach to the modeling and evaluation of air traffic management procedures. In our evaluation experiments human operators interact with computer simulated air traffic in a realistic control room environment. This environment provides commercially available and experimental, automation supported, air traffic management tools. All parts of this human-in-the-loop simulation environment implement system wide information sharing and information management. As a working example this paper presents the experiments and preliminary results of a study we conducted to develop a better understanding and a computational model of the air traffic management process at Hamburg airport. The results indicate that we have developed a simulation model realistically approximating the performance of human air traffic controllers in the investigated scenario. We plan to continue our work by investigating additional airports and different air traffic scenarios. Keywords. Air traffic management, system-wide information management, computer simulation, SESAR WP-E. Introduction The Single European Sky ATM Research (SESAR) master-plan defines a framework for the sustainable growth of the European air transportation system. It aims to increase capacity, improve safety, and reduce environmental footprint and cost. These objectives are all about increasing the overall productivity of the air transport system. The improvement of air traffic management (ATM) procedures by embracing systemwide information management (SWIM) and automation will be a key enabler to achieve these objectives. 1 Corresponding Author.

2 In aeronautics information sharing and automation has two main goals: One is to minimize the low-level or redundant tasks for pilots and controllers; the other is to support the high-level, rather complex decision making activities demanded from these actors. It is a common feature of all such approaches that they have to be evaluated carefully with humans in the loop; however, it is nevertheless desirable to develop a realistic computational model for a first evaluation. This paper presents the application of human-in-the-loop simulation experiments to the evaluation of data-link and SWIM-supported airport operations at the Hamburg airport 2. The experiments presented in this paper were originally performed in the context of the SESAR WP-E project ZeFMaP [1], but were later extended to produce the results discussed in this paper. The objective of the extended simulation experiments was to increase knowledge on how air traffic performance can be modeled computationally. To achieve this feat, we conducted a set of real-time simulation exercises, where air traffic controllers were subjected to realistic work scenarios executed in real-time. The outcome of these experiments was then compared to a computational model of the same scenarios. We conducted these experiments with five controllers using real (past time) air traffic data from Hamburg s tower control room. The experiment was conducted using the distributed human-in-the-loop simulation environment of the University of Salzburg, its experimental air traffic management tools, and a modified version of the electronic flight-strips tool SmartStrips developed by Frequentis AG. The remainder of the paper is organized as follows. The first section gives an overview of the investigated scenario. The airport, control room, and support tools are described. The second section explains the system-wide information management used in our simulation environment. It is a simplified implementation of the SWIM approach envisaged within SESAR. The third section discusses preliminary results evaluating our computational ATM model against the performance of human controllers. The last section provides concluding remarks and an outlook to further work. 1. The Hamburg Airport Simulation Scenario The simulation experiments described in this paper were carried out at the Aviation Competence Center Salzburg and provided the human controllers with a realistic environment to ascertain the validity of the results. This is accomplished by the detailed simulation of the Hamburg airport situation, the interactive simulation of realistic air traffic and the integration of commercially available air traffic control tools into an authentic control room environment and work flow. The simulation did not involve simulated or participating pilots, and hence the controllers did not have to handle communication with them. Instead the simulation was held as if there would be a controller-pilot data-link communication (CPDLC) connection to the aircraft. Controllers manage aircraft by sending text-based data-link messages directly from the electronic flight strip tool and the interactive air traffic simulation responds in the same manner. The messages used in the experiments were based on the standardized FANS-1/A message catalogue and its proposed additions. In addition to CPDLC system-wide-information-management (SWIM) was also used in the experiment. All aircraft, runway, and airport state was collected in a 2 Hamburg airport was not involved in these purely hypothetical experiments.

3 distributed database and made available to the controllers through different user interfaces displaying the relevant perspective on the shared information Hamburg Airport Hamburg airport is a typical medium-sized European airport. It has two crossed runways for take-off and landing, and two apron areas for parking aircraft. The layout of the airport is displayed in Figure 1 (a). To enable a realistic simulation of the air traffic at Hamburg airport, the experiment coupled the Navsim 3 air traffic simulator and several controller user interfaces to a local SWIM implementation distributing the data between the simulation components (c.f. Figure 5). By using this set-up, we were able to control a number of different attributes related to the simulation setting, which provided us with a high degree of experimental control. The variables that were controlled during the experiment included, among others: traffic scenario (the air traffic simulated in the experiment was based on real traffic data from Hamburg Airport, taken from the peak hours on a specified set of dates); weather conditions; controller working positions; air traffic control procedures and roles; and team structure. The team used in the experiments comprised five controllers with different responsibilities described below: TWR, GND, APR1, APR2, and CDC. Adjacent sectors beside the five controller positions were simulated by the Navsim air traffic simulator. The traffic in the Hamburg terminal maneuvering area (TMA) was also controlled by the air traffic simulator. Arriving aircraft were automatically handed off to the Hamburg tower controller; departing aircraft were handed off to TMA-departure while leaving the tower frequency. The human-in-the-loop simulation included: Hand-over from simulated Hamburg approach TMA controller to human Hamburg tower controller (when the aircraft is established on ILS). Hand-over from human Hamburg tower controller to simulated Hamburg TMA departure controller (when the aircraft leaves tower frequency). Human Hamburg tower controller (TWR) who is responsible for the two runways (23/05 and 33/15) and the runway exits. The following active runway configurations were simulated: o RWY 23 for arrivals o RWY 33 for departures Human Hamburg ground controller (GND) who is responsible for ground movements on all taxiways. Human Hamburg apron controller 1 (APR1) who is responsible for apron 1 movements. Human Hamburg apron controller 2 (APR2) who is responsible for apron 2 movements. The clearance delivery controller (CDC) was responsible for the start-up clearances of all departing flights. No different meteorological environments were simulated. Instrument meteorological conditions were used during all simulation runs. The wind component was 10kts from 270. Due to this, the simulation operated with IFR traffic only. The 3 The Air Traffic Simulation Tool "Navsim" has been developed by "Mobile Communications R&D GmbH, Salzburg" in co-operation with University of Salzburg.

4 assignment of controller responsibilities to the airport layout and the control room is displayed in Figure 1. TWR APR1 APR2 GND (a) Figure 1. (a) Hamburg airport ( Deutsche Flugsicherung); (b) Control room at Aviation Competence Center Salzburg Controller Workstations The controller working positions comprised a radar screen, a flight strip tool, and an auxiliary screen. The radar screen is a modified version of the Navsim air traffic simulator stripped down to the graphical user interface for the display of the remotely simulated flights. The electronic flight strips tool SmartStrips was supplied by Frequentis AG and used for the CPDLC interaction with the simulated aircraft. Command messages generated by the flight strips tool were sent over the simulation SWIM network to the air traffic simulator to request the appropriate aircraft behavior. The implementation of SWIM in the simulation is described in section 2. The auxiliary screen was a generic implementation of an arrival/departure management tool giving the controller increased time awareness. A controller working position is displayed in Figure 2 (d). The radar screen is on the top left, the flight strips tool on the bottom left, and the auxiliary screen on the right. The airport controllers are supported in their task by a non-intrusive level of automation. The controller user interfaces were modified to display state information, using additional text and color codes, e.g. aircraft requesting clearances are highlighted while aircraft at parking positions are de-emphasized. A detailed view of the radar screen is shown in Figure 2 (a). It displays the runways, taxiways, and parking positions of the airport. Aircraft are displayed with a position vector and a label indicating their callsign (and a unique simulation internal identifier for post-processing). Altitude, and heading can be displayed optionally. In our experiments additional information was displayed in the label to assists the controller with the CPDLC data-link communication. Aircraft with unanswered requests were highlighted in color and the last CPDLC request was displayed. Note that the radar screen draws this information from the simulation s SWIM implementation of the simulation. Flight state and communication state originate from different sources, but are made available and consolidated through the system wide information management. (b)

5 The auxiliary screen showing the arrival/departure manager is displayed in Figure 2 (b). This tool provides the controller with a time line for each active runway. In our experiments runway 23 was used for arrivals and runway 33 was used for departures, hence two time-lines were displayed. Flight labels on the time-line provided the controller with time awareness for the planned arrival (left side) and departure (right side) times of the past ten minutes and the future fifteen minutes (i.e. one slot duration). The labels use identical color-coding as on the radar screen and display the last datalink messages. The consolidated information on the runway configuration, flight plans, current flight and communication state are provided by the simulation s SWIM implementation. The data-link commands for air traffic control are entered into the electronic flight strips tool shown in Figure 2 (c). Each flight is represented by a flight strip autogenerated from the SWIM data, and flight strips can be shared by different controllers or stored in bays only accessible to a single user. Commands entered through the user interface are injected into the system-wide information management where they can be accessed by the other simulation components (e.g. the air traffic simulator responding to the commands). (a) (b) (c) (d) Figure 2. (a) Radar display. (b) Arrival/departure manager. (c) Electronic flight strips; image courtsey of Frequentis AG. (d) Controller working position. In addition to the individual controller working positions a virtual tower view was provided to all of them. The virtual tower view comprised a 3D visualization of the Hamburg airport projected onto a 180 screen as shown in Figure 3 (a) and (b). The 3D view was generated by a adapted version of the commercially available X-Plane 10 software integrated into the simulation s SWIM network. Color-coded labels attached to each flight enhanced the rendering.

6 (a) Figure 3. (a) Virtual tower view of Hamburg airport. (b) Virtual tower room. (b) 2. A Simple SWIM Implementation for Human-in-the-Loop Simulations The system-wide information management network (SWIM) envisaged by the SESAR master plan is a large-scale system designed for operational use. It is too complex to be used in a research laboratory; therefore we use a simpler implementation with analogous information sharing capabilities. It does not provide the same scalability, security and safety mechanisms as the SESAR SWIM network, but provides a SWIMlike environment simplified and adapted to the current needs of the supported applications. The goal is a step-wise enhancement of the simulation s SWIM architecture in accordance with SESAR developments to support other manufacturers and vendors with a SWIM compatible evaluation environment. Just like many operational air traffic control solutions many existing simulation tools were not designed to be integrated with each other. For air traffic management the SWIM network developed in the context of SESAR bridges this interoperability gap. However, the SESAR SWIM network is complex, requires expert knowledge to operate, and may also require extensive modifications of existing simulation software. Clearly this is not feasible with justifiable effort for a research project. What is really needed is an efficient and vendor-neutral way to integrate existing tools in a simple and efficient analogon of the SESAR SWIM network. The approach discussed in this paper integrates existing simulation and support tools in a SWIM-like network using a simple software adapter to distribute shared simulation state in an internet-protocol-based multicast cloud using XML as presentation layer. It is a completely decentralized approach based on the distributed simulation concepts presented in [2], [3], [4], and [5]. Assuming real-time simulation, as is usually the case with human-in-the-loop simulations, it does not require the configuration of a central instance for coordination. Shared simulation state is injected into a multicast cloud for distribution; each simulation tool can then extract the required information from the common information pool. Using IP multicast for this purpose has the advantage that it is natively supported without configuration in Ethernet LANs as they are commonly deployed today. Within the IP-multicast cloud a simple XML format is used to represent the simulation state. Using XML as presentation layer has the advantage that almost all computer-programming languages natively support it, ensuring the availability of high-quality parser implementations at no additional cost.

7 2.1. A Layered Information Sharing Protocol The SWIM implementation used in our simulation experiments utilized a simple, layered, and distributed architecture based on the OSI reference model. The OSI model was defined by the International Standards Organization, ISO, to formally define the interconnection of computer applications. The model, called the Open Systems Interconnection, OSI, architecture is illustrated on the left side of Figure 4. It defines seven layers, where one or more protocols implement the functionality assigned to a given layer i.e. the OSI model is not a protocol stack itself, but a reference model for any protocol stack. Starting from the bottom and working up the functionalities assigned to the different layers are as follows. The physical layer handles the transmission of bits over a communication link. The data link layer uses the physical layer to transmit logical aggregates of data between directly connected nodes. The network layer handles the routing of packets to make communication between indirectly connected nodes possible. The transport layer establishes end-to-end communication between processes. The session layer takes care of the logical sessions between communicating processes while the presentation layer defines the format of the data to be exchanged. Finally the application layer comprises the communication protocols of the application itself. Navsim, aux, SmartStrips, virt. tower OSI reference model Application Layer Presentation Layer Session Layer Transport Layer Dist. SWIM database XML Presentation Soft-State Session UDP SWIM Stack Network Layer IP Multicast Data Link Layer Physical Layer Ethernet LAN Figure 4. Layered information sharing architecture. The simulation architecture used in the experiments goes from the application layer down to the network layer (right side in Figure 4). In this context the application layer is equivalent to the interface between the simulation application and the SWIM stack. This interface may be realized in different ways depending on the type of the application (Navsim, SmartStrips, auxiliary screen, virtual tower). The presentation layer covers the encoding of simulation events in a machine-readable, platformindependent XML representation. The session layer of the integration stack establishes logical sessions that are robust against communication interruptions or restarted simulation processes. The transport layer encapsulates the XML information of the upper layers for end-to-end transmission between the connected processes. Finally the network layer and the layers below take care of the actual multicast transmission over the LAN.

8 The application layer interface is specific to the application, but provides access to the same distributed information. Within the SWIM stack simulation events are distributed over the network as empty XML elements of the form: <event_or_command attribute1= attribtute2= />. Restricting the presentation syntax to empty elements enables the distribution framework to trace the event driven air traffic simulation with minimal effort. Each XML element corresponds naturally to one simulation event or simulation command. The properties of the event or command are reported in the attributes of the XML element. The XML representation of the simulation events is analogue to the life-cycle of the simulated objects. Objects are created, used, and finally de-allocated. This is best illustrated with an example: The creation of a new simulated flight is presented by a <create_flight /> XML element. This element has various attributes like the position of the flight, its departure airport, its arrival airport, and many more. While the aircraft is cruising, the current position and some other attributes of the flight are updated via <set_flight /> XML elements. Note that only changed attributes are updated. Unchanged attributes are not retransmitted in the <set_flight /> element. When the aircraft finally arrives at its destination airport the flight object is removed from the simulation (after taxiing, etc.) with the <delete_flight /> XML element. Controller-pilot data-link commands are represented by single XML elements in an analogue way. For example an air traffic controller s command to an aircraft is mapped to a <cpdlc_message /> XML element. Human Controller(s) Controller HMI (Navsim ATC) Flight & Airport Objects Flight Objects Controller HMI (SmartStrips) SWIM Commands Controller HMI (Auxiliary Screen) Flight & Airport Objects Flight & Airport Objects Tower visualization (XPL10 ) Virtual Tower Flight & Airport Objects Commands Air Traffic Generator (Navsim TG) Simulated Air Traffic Log-File Data Analysis Figure 5. Logical information flow in the simulation s SWIM network. In order to allow re-started applications to recover lost simulation state the session layer of the information sharing stack uses a soft-state pattern i.e. the essential parts of the simulation information needed for recovery are re-distributed in regular intervals. The network layer of the integration stack uses IP multicast over Ethernet LAN to provide configuration-less deployment. Note that the XML representation of the simulation events and commands is not only distributed over the network, but also stored in log files for the experiment analysis. The information flow of the simulation components is illustrated in Figure 5.

9 Navsim ATC (i.e. the radar user interface), SmartStrips, and the auxiliary screen are actually present five times in the experiment setup. The virtual tower is present three times, once for each projector A System-Wide Distributed Database of Objects The simulation and interface applications do not access the XML representation of the SWIM objects directly. Instead they access a database caching the state of the distributed objects. This database is constantly updated on the input of the lower layers of the SWIM stack. The actual information is condensed into suitable objects, e.g. flight-objects, airport-objects, and presented to the applications through a simple API. 3. Preliminary Results of Modeling ATM Procedures in Hamburg The objective of the experiments described in this paper was to increase knowledge on how air traffic performance can be understood and modeled. The methodology applied was first to conduct a series of simulations of the Hamburg airport operations with five human controllers. In the second step the same scenarios were simulated with a rulebased artificial intelligence (AI) replacing the human controllers. The resulting performance figures were compared to estimate the accuracy of the approximation of human controller performance by the AI. The first step of the experiment involved a sample of five participants. The task of the controllers was to control the air traffic as they would normally do while working in the Hamburg tower. The air traffic samples were at the limits of the airport s theoretical maximum capacity; approximately sixty flights per hour. In the second step of the experiment the human controllers were replaced by a rule based artificial intelligence. The rules were derived from controller training material taking specific aspects of Hamburg airport into account. Note that the only necessary change to the simulation set-up was to replace the CPDLC user interface by the AI. Due to the SWIM based information exchange no changes to the other parts of the simulation were required. Table 1. Controller performance for EDDH, 60 A/C per hour, 1h duration. Human controllers AI Controllers avg. sdev. avg. sdev. Delay (departures) s Taxi time (arrivals) s Taxi time (departures) s Taxi distance (arrivals) m Taxi time (departures) m The comparison of the key performance indicators of the air traffic management performance indicates a good agreement of the AI model with the human controller performance. Selected key performance indicators for one investigated scenario are displayed in Table 1. It is noteworthy that the AI accrued significantly higher departure delays than the human controllers. The controllers would typically plan ahead and let aircraft depart shortly before their planned departure times. This was not reflected in

10 the AI rules as the task was to meet the calculated takeoff times (CTOT) as accurately as possible. 4. Conclusion The envisaged sustainable modernization of the European air transportation system requires capabilities to evaluate new ATM procedures under realistic conditions. The SWIM based human-in-the-loop simulation approach presented in this paper provides several of these capabilities. The first major advancement of the state-of-the-art provided by this human-in-the-loop simulation environment was the coupling of a powerful air-traffic simulator with commercial-of-the-shelf air traffic control and visualization software in a simulation-wide SWIM network. The second major advancement was the development and preliminary evaluation of a rule-based air traffic management model. The results indicate that the model, and thus the complete simulation environment, is in good agreement with the performance of human air traffic controllers in the investigated scenarios. We plan to continue our work by evaluating advanced taxi-routing optimization algorithms applied to additional airports of high complexity and different air traffic scenarios. References [1] Jan Alexander Langlo, Aslak Wegner Eide, Amela Karahasanović, Lisbeth Hansson, Hans Erik Swengaard, Theodor Zeh, Stephan Kind, Carl-Herbert Rokitansky, and Thomas Gräupl, Usefulness of FMECA for improvement productivity of TWR process, in Proc. SESAR Innovation Days 2012, [2] C.H. Rokitansky, M. Ehammer, and T. Gräupl, Newsky Novel Simulation Concepts for Future Air Traffic, in Proc. 1st CEAS European Air and Space Conference, 2007, pp [3] C.H. Rokitansky, M. Ehammer, and Th. Gräupl, NEWSKY Building a Simulation Environment for an Integrated Aeronautical Network Architecture, in Proc. 26th DASC, 2007, pp. 4.B B [4] M. Ehammer, T. Gräupl, and C.H. Rokitansky, Applying SOA Concepts to the Simulation of Aeronautical Wireless Communication, in Proc. CNS 08, 2008, pp [5] T. Gräupl, B. Jandl, and C.-H. Rokitansky, Simple and Efficient Integration of Aeronautical Support Tools for Human-In-the-Loop Evaluations, in Proc. ICNS 12, 2012, pp. F4-1-F4-9.