A Hybrid Gate-to-Gate Simulation Environment for the Air Traffic System

Abstract

This paper presents a concept of a fast-time gate-to-gate simulation environment. The implementation is divided into an air traffic part that uses BADA performance parameters and a simulation of ground processes. The main objective of the flow-based hybrid simulation environment is to cover commercial European air traffic, in order to investigate network-related effects when exposed to disturbances. Based on historic traffic scenarios, the hybrid simulation platform enables the investigation of the local and global effects of a variety of disruptions. With respect to current flow-based models, it is intended to gain better insights into the underlying interdependencies by modelling higher levels of detail for selected parts, whilst covering the whole European air traffic network. After a validation and first calibration of the approach, Monte Carlo simulations, based on flight plans, are performed as proof of concept. This aims to illustrate the local effects of network-wide disturbances and is applied by means of stochastic influences of ground processes, gained from real operational data.

1. Introduction

Within the air traffic domain, different simulation approaches are prevalent, addressing diverse subjects, like Air Traffic Management (ATM) or airport and airline operations. Flow-based macroscopic simulation environments like FACET (NASA) [1], SAAM (EUROCONTROL) [2], TAAM [3], Bluesky [4], and TOMATO [5], which primarily focus on network effects, are widely used, though they can lack higher levels of detail concerning ground operations. On the other hand, highly detailed simulations, such as the discrete event-based SIMMOD [6] or the Surface Operations Simulator and Scheduler (NASA) [7], which are applied for capacity assessments at airports or gate allocation problems, do not cover network effects. In contrast to flow-based methods, they focus on a specific airport with its surrounding airspace. Other commercial gate-to-gate simulations, such as the industry-leading AirTOP [8], provide high-fidelity representation of the air traffic in en-route and terminal airspace as well as in ground processes. It is widely used for the optimisation of airport capacities all over the world. However, due to its highly complex environment, it requires a resource-intensive configuration and does not meet the requirements of an open research environment to investigate specific questions.

Over the last years, the importance of agent-based simulation models has risen. The versatile agent-based modelling approach finds application, for example, in reflecting Airline Operation Centers (AOCs), such as in [9]. Such modelling often depends on realistic arrival times and utilisation rates, which require historic airline data that are not freely available. Recently, fast-time gate-to-gate agent-based modelling (ABM) environments grew more comprehensive such as AgentFly [10]. Recent work in this area such as ELSA [11] and Mercury [12,13] provide a simulations environment, which allows us to investigate different operational mechanisms, based on probabilistic implementations of trajectories or ground operation. This is performed by extending the temporal horizon through including strategic and pre-tactical levels and incorporating a variety of relevant stakeholders, such as AOCs or Air Traffic Flow Management (ATFM). Since this approach reflects trajectories or ground processes probabilistically, it does not meet current challenges, such as the introduction of new types of aircraft propulsion and the respective network-wide implications.

The goal of the proposed fast-time hybrid simulation environment is to provide modular components of different levels of detail, for en-route, terminal airspace, and ground operations, in order to investigate new aircraft types and to enable simulation-based optimisation approaches. The coupled fast-time gate-to-gate simulation encompasses the whole European airspace and is divided into air- and landside simulation parts. It tries to improve the existing gaps of the different approaches described above. The presented concept attempts to implement customisable levels of detail at selected parts of the model, whilst maintaining the complexity of the European air traffic network as a whole. The authors of the paper aim to better interlace air- and landside operations, to enable increased insight into the interdependencies of the European network. This applies especially to the investigation of the effects of introducing new propulsion concepts.

Recently, alternative propulsion concepts for commercial aircraft have been investigated in a broad manner. The focus here lies on the feasibility of such concepts to provide the necessary air transportation capacities in order to replace current fossil fuel propulsion. The Cluster of Excellence Sustainable and Energy-Efficient Aviation (SE²A) investigates technologies for a sustainable and eco-friendly air transport system, by following an interdisciplinary approach. Scientists from diverse fields are collaborating on efforts to reduce emissions and noise, as well as recycling and life-cycle concepts for airframes and enhancements in ATM. Future paradigm changes with respect to airplane energy sources, aircraft design, or propulsion concepts will influence ATM operations. As an example, a study of an all-electric aircraft was produced within the SE²A consortium [14]. The adoption of such novel electric or hydrogen-based aircraft types will lead to significant changes in transportation flows and operational procedures within the Air Traffic System (ATS). The presented advanced ATS simulation environment (AdAS) is designed to facilitate investigation into the implications of such propulsion concepts when introduced into the Air Traffic System. For example, the trajectory calculation will incorporate new performance parameters or ground processes will be adapted, such as in the case of loading cycles of batteries, which have to be integrated into the turnaround process.

The particular simulations of the environment follow an object-oriented approach on the one hand and a discrete event modelling approach on the other hand. The object-oriented airside simulation makes use of the Base of Aircraft Data (BADA) [15] performance envelopes. In this case, the particular characteristics of a multitude of aircraft in the European airspace are modelled with a temporal resolution of one second. Furthermore, it incorporates heuristics to regulate the traffic within the Terminal Manoeuvring Area (TMA) and sector, respectively, as well as runway assignment and conflict detection. On the ground, stochasticity can be considered for processes.

This paper is structured as follows. In Section 2, the air- and landside simulation, as well as the coupling mechanics, are presented. In Section 3, the proposed concept is validated by means of deterministic throughput computations at selected airports for a day of European traffic. Section 4 provides a scenario as a precursor to a simple sensitivity study. This encloses different levels of detail at selected parts of the model and ground-related disruptions, which were gained from anonymised real operational data of an Airline Operation Center. In Section 5, Monte Carlo simulations are applied and a couple of Key Performance Indicators are calculated. The last section discusses further aspects of the concept relating to better calibration of the model and upcoming research questions.

2. The Simulation Environment

In this section, the coupled air- and landside simulation environment of AdAS will be introduced. The first part provides a schematic overview of the concept with the according data foundations. Those will be explained afterwards in more detail. Subsequently, the functionalities of the airside and airport simulation will be described in separate subsections.

2.1. Overview

Figure 1 illustrates the concepts of the hybrid simulation environment, which consists of the airside and airport parts and the according data foundation. The airside part comprises en-route and selected TMA regions. The airport part, on the other hand, comprises turnaround processes and selected taxiing procedures. Both parts rely on different data sets, which are depicted in yellow. The hybrid simulation covers several hundred European airports. With respect to the airside and for the purpose of the validation of the presented approach, a small selection of TMA regions were chosen to be modelled in high detail in terms of operations (aircraft sequencing, etc.). A lesser level of detail is applied to other TMA regions, where standard terminal arrival and standard instrument departures routes are implemented, whereas aircraft sequencing is neglected. For the rest of the airports, the flights depart and arrive in the respective Airport Reference Points (ARPs), according to the flight plans. This represents the simplest type of airport modelling.

The airside simulation part is described in Section 2.3 in more detail. Different levels of detail were also applied on the airport simulation part. Here, Hanover was chosen to model the taxiing process. Other airports used taxi times derived from historic data. The turnaround process was implemented as a standard model with process duration derived from the manufacturer. Furthermore, the distributions of sub-processes are considered. The airport simulation is discussed in Section 2.5.

Each simulation part performs its particular calculations for a given time step. Synchronisation is applied by the use of data exchange via a MySQL table. MySQL is an open-source relational database management system that organises data into tables. More information about the data exchange can be found in Section 2.4. In addition to the coupling of air- and landside, an extension to incorporate further simulators at a later stage is provided by means of the MQTT protocol, as depicted by the dashed line. MQTT is a publish–subscribe, machine-to-machine network protocol for message and queuing services. Such simulators encompass the A320 human-in-the-loop simulator of the Institute of Flight Guidance, which was also used to verify the BADA implementation of the proposed airside simulation.

This verification was performed in the context of the calculation of cost functions by means of regression analysis for fuel consumption (see [16]). Here, a short-range flight was conducted via the simulator, which uses the Prepar3D V3 Engine. The according flight scenario represents all relevant flight phases. The BADA model, which was implemented in the airside part, detects the distinct phases of flight and applies the respective thrust configurations accordingly. Further information concerning the BADA data set can be found in Section 2.2. For more details of the implementation as well as the verification of the BADA implementation, the authors of the paper kindly refer to this preparatory work.

Additionally, the functionalities of pseudo pilots, such as changes in course, altitude, or velocity of an aircraft during the simulation, can be provided by means of a graphic user interface of the airside simulation. This applies also to measures of ground operations, such as ground holding, flight cancelling, or changes to specific turnaround sub-processes. Airborne and ground interventions are applied in real time. Fast-time simulation is aimed for sensitivity studies when performing Monte Carlo simulations. In Section 2.6, the performance figures for a European scenario are presented.

2.2. Data Foundation

Both airside and ground operations are modelled based on different data sets. This, for example, applies to the creation of scenarios. Due to computational costs, we restricted the available flight plans, trying to cover all relevant influences on the European air traffic network. The data set which was used to generate the flight plan for the hybrid simulation environment is the so-called so6. These data comprise the waypoints of planned trajectories as well as scheduled times for departure and arrival and are labelled so6-M1; see also [17]. They represent the basis of the trajectory calculation. In order to define the system boundaries, we focus on the regions E and L, as classified by the International Civil Aviation Organization (ICAO) [18]. Those regions cover approximately 73% of all flights. We consider all in- and outbound traffic from E and L, as well the traffic within E and L.

Figure 2 aims to illustrate the traffic flow between the different ICAO regions for different days. Differences between the summer and winter schedule become clearly visible, as in, for example, the variations between July and January concerning traffic flow between the regions KC and L. This possibly indicates vacation trips to southern Europe. Since so6 data became unavailable for public access and could not be secured comprehensively, the depicted traffic flows had to be computed by means of data from different years. For the sake of better readability, Figure 3 illustrates the international regions of traffic flows in Figure 2. In addition, restricted regions, airfields that do not facilitate commercial traffic, were removed from the model.

To enable a more realistic representation of TMA operations, Standard Instrument Departure Routes (SIDs) and Standard Terminal Arrival Routes (STARs) were added. Figure 4 depicts a selection of the airports which consider SIDs and STARs in a cutout of region E. Since a TMA is not always clearly defined, we approximated it by using the points of largest expansion, resulting in a rectangle. One can observe the overlapping of TMAs as well as the large number of SIDs and STARs in some regions, leading to higher complexity when modelling TMA operations. SIDs and STARs can be denoted as navigation data. In addition to the waypoints, the flight plan comprises scheduled times for landing, off-block, and take-off. These estimated times are derived from the last filed plan in so6.

After addressing the flight plan with the according estimation times, waypoints, and additions within the TMA, the data foundation for the trajectory calculation shall be explained briefly. Based on the set of BADA and flight plan data, highly detailed 4D trajectories can be computed for a wide selection of different types of aircraft. The applied BADA data set covers more than 100 different conventional types of aircraft. The BADA itself is founded on a point mass model and includes a range of coefficients for performance as well as operational procedures (see also [15]). The coefficients and parameters derived in the BADA data sets proved their applicability in a multitude of simulations (such as SAAM, AgentFly, or TOMATO) that are widely used in the domain of ATM. The emphasis here lies on the simulation of trajectories and algorithms for forecasting.

In the presented hybrid simulation environment, BADA-based calculated trajectories, by means of waypoints of the flight plan, are used to reflect the network more realistically. The calculation will be described in Section 2.3. Weather influences as well as charges such as navigation fees are not used in this concept paper. Further information concerning the input data for the airside simulation part can be found in

Table 1. List of input data used in the air traffic simulation environment.

Input Data	Description	Reference
Flight plan	The so6 Model 1 is used to obtain the set of 4D flight segments consisting of waypoints, information on aircraft type, origin–destination, callsigns, and flight identifiers. It is the last saved flight plan after all the modifications with Integrated Initial Flight Plan Processing System (IFPS) messages.	All this information is managed by EUROCONTROL and was accessed via the Demand Data Repository (DDR) [17].
Navigation	Standard Instrument Departure Routes and Standard Terminal Arrival Routes, holding pattern parameters.	Jeppesen [19].
BADA	The Base of Aircraft Data REVISION 3.9 is a collection of aircraft operation performance parameters and airline procedure parameters, which is used for the simulation of flight trajectories.	All files are maintained within a configuration management system at EUROCONTROL [15].
Weather	GRIB2 is a World Meteorological Organization standard format for the transmission of gridded meteorological data and is used to obtain information on wind and temperature.	Global Forecast System [20].
Charges	Cost estimation functions for CO2 emissions for different aircraft types, load factors, air navigation fees, and maintenance.	[16].

and Table 2.

After an aircraft is handed over from the airside simulation part to the landside via MySQL, the calculation of ground processes is carried out. Ground processes are hereby modelled by means of a Discrete Event Simulation environment. After the landing of an aircraft, the taxi-in process is reflected using topological information. Those data include runways, taxiways, and gates. After arriving at the gate or stand, the type of aircraft determines the deterministic sub-process durations of the turnaround, which were procured from the manufacturer.

The stochastic influences of distinct sub-processes are available in the literature, such as good Weibull fittings for cleaning, de-boarding, catering, and boarding or Gamma fitting for fueling, as seen in [21]. Furthermore, [21] presents stochastic representations, which relate arrival delay to the beginning of particular sub-processes. It has to be stressed that the distributions are derived from the data of mid- to short-range flights, with a flight time of less than 120 min and turnaround duration less than 75 min at the Frankfurt and Munich airports. Therefore, it might not be applicable for all airports in the presented coupled simulation, since it also consolidates different aircraft types, thereby neglecting variations in the durations of their particular sub-processes.

This concept paper presents a combined air- and landside simulation, which enables the integration of different levels of details. The validation will be performed by means of a deterministic scenario; see also Section 3. Stochastic influences will be considered as a first example in a subsequent sensitivity study at the end of this article; see Section 4. Here, delay data from the Central Office for Delay Analysis (CODA) and probabilities for the occurrence of Air Transport Association (IATA) delay codes, which were procured from historic airline data, are used to qualitatively show the effects on the Key Performance Indicators (KPIs) of selected airports; see Section 5.

Table 2. List of input data used in the airport simulation environment.

Input Data	Description	Reference
Infrastructure	Information on airport and infrastructure, such as runways, taxiways, and gates.	OurAirports [22], OpenStreetMap [23].
Process times	Aircraft turnaround times including cleaning, catering, re-fuelling, and cargo and baggage handling, plus getting passengers onto and off of the airplane.	Deterministic turnaround sub-process durations were derived from Gantt charts provided by the aircraft manufacturer; see, for example, [24].
Stochastics	To represent stochastic influences in the simulation, a couple of ground operations are selected as well as data to model a general distinction between delayed and early flights. The data contain information about particular delay codes and respective delays. The delay codes embodied in the airline data are based on IATA delay codes. The distributions of the durations of sub-processes and the respective starting times are related to arrival delays.	The data were procured from the real operational data of an anonymous airline and the report from CODA [25]. The stochastic durations of sub-processes are available in [21].

Table 2. List of input data used in the airport simulation environment.

Input Data	Description	Reference
Infrastructure	Information on airport and infrastructure, such as runways, taxiways, and gates.	OurAirports [22], OpenStreetMap [23].
Process times	Aircraft turnaround times including cleaning, catering, re-fuelling, and cargo and baggage handling, plus getting passengers onto and off of the airplane.	Deterministic turnaround sub-process durations were derived from Gantt charts provided by the aircraft manufacturer; see, for example, [24].
Stochastics	To represent stochastic influences in the simulation, a couple of ground operations are selected as well as data to model a general distinction between delayed and early flights. The data contain information about particular delay codes and respective delays. The delay codes embodied in the airline data are based on IATA delay codes. The distributions of the durations of sub-processes and the respective starting times are related to arrival delays.	The data were procured from the real operational data of an anonymous airline and the report from CODA [25]. The stochastic durations of sub-processes are available in [21].

2.3. Airside Simulation

Within the airside part, the aircraft trajectories calculated for different pairs of origins and destinations of the selected set of European airports are derived from BADA performance characteristics. Those particular BADA coefficients and parameters are used in order to calculate aircraft-specific performance characteristics, such as thrust, fuel consumption, or drag. During the calculation of a trajectory, the according waypoints from the so6 flight plan are followed by the particular aircraft. This comprises all vertical and lateral manoeuvres, including turnings. The calculation process also incorporates fuel consumption, which relates to the change in the mass of the aircraft. For the aircraft weight, the reference mass provided by the BADA model was used, as well as default speeds from the BADA airline procedure model. Cost index and wind were neglected in this paper.

The trajectories are calculated with a temporal resolution of one second. Further application examples of the BADA trajectory calculation module can be found in [26,27]. The flight plans, as mentioned above, are used to provide origin and destination pairs, type of aircraft, and the coordinates of the waypoints. To enable the representation of realistic departure and arrival routes, SIDs and STARs are integrated for a variety of European airports as well. At selected airports, automated TMA procedures such as holding stacks are implemented. Combined with a heuristic-based automated runway assignment, it enables a fully autonomous simulation of air traffic. In this context, adapted flight plans can be integrated in a flexible manner, in order to reflect future traffic volumes.

In addition, the airside simulation provides an algorithm for Conflict Detection and Resolution (CDR). The algorithm is divided into en-route flights and traffic within the TMA. The complete TMA model with holdings stacks and aircraft sequencing, as described in more detail below, is only implemented at selected airports (type A), while the SIDs and STARs are implemented for a wider range of airports, neglecting aircraft sequencing (type B). At other airports, aircraft arrive at the reference points, according to the so6 flight plan, neglecting SIDs and STARs as well as aircraft sequencing (type C). En-route CDR is applied for types B and C, whereas TMA CDR is applied only for type A.

In the en-route phase of flight, the spatial distances between aircraft are inspected during the simulation process. That is, each aircraft is equipped with three-dimensional boundaries surrounding the aircraft and depicting the obligated separation minima according to [28] with an additional buffer. The boundaries are than checked for possible collisions with nearby aircraft. To evade unnecessary collision checking and save computation time, uniform grid spatial partitioning is applied. Once a conflict is accurately identified, the algorithm chooses an appropriate method to resolve the risky situation. For instance, if the two aircraft’s paths cross at some point and then diverge, a change in altitude or flight level is ordered. After the conflict has been resolved, the respective aircraft will target the next waypoint in the flight plan and thus climb back to its cruising level. Depending on the aircraft class, converging conflicts can be resolved via speed control or vectoring by establishing separation. However, vectoring usually extends the distance flown and can cause small delays. This drawback can be mitigated by providing shortcuts after the resolution.

The second part of the collision algorithm is implemented for selected TMA regions and differs from the procedure during the crossing of sectors. In order to avoid safety risks, caused by potentially hazardous turbulence in the wake of an aircraft in flight, Air Traffic Controllers (ATCs) have to establish the sequence of arriving (and departing) aircraft. Whenever an aircraft cannot be integrated into the approach sequence, the ATCs are able to delay the aircraft by applying the holding procedure. A holding procedure is a flight manoeuvre that keeps the aircraft within a specified airspace while awaiting further clearance from ATCs. It is constituted of a geographical reference location (holding fix) entering the holding pattern and two half-turns joined by a straight flight leg.

In the following, the algorithm for establishing the sequence of arriving aircraft, taking the wake turbulence separation minima into account, will be described in detail. When an aircraft enters the Terminal Manoeuvring Area, a suitable runway, based on the landing distance, will be assigned and the flight route will be connected with the corresponding STAR. A STAR is an air traffic service route, identified in an approach procedure, by which aircraft should proceed from the en-route network to an initial approach fix. Each runway has a number of different STARs consisting of waypoints, some of them declared as a holding fix. Furthermore, the positions of specific waypoints, used to merge different arrival routes (merge points), are important for the aircraft sequencing algorithm (see Figure 5).

Figure 5 is used to illustrate the approach routes used by the model for the Frankfurt airport. This includes highlighting merge points as well as the positions of holding fixes. For the sake of clarity, the STARs with their respective labels are only shown for one operating direction of the runway configuration used in the simulation scenario. The labels for the runways used in this configuration (RW 25R, RW 25L) are located in the center of the image. Additionally, the trombone-shaped airways are visible.

Once an aircraft reaches the first holding fix of its assigned STAR, the appearance time at the merge point is estimated by calculating the flight trajectory between these two points. The algorithm checks if proper spacing according to wake turbulence and separation standards (see

Table A1. Wake turbulence categories of aircraft, own representation based on [34].

Aircraft Mix Class	Aircraft Wake Turbulence Class	Number of Engines	MTOW [lb]
A	Light	Single	12,500 or less
B	Light	Multiple	12,500 or less
C	Medium	Multiple	12,500–300,000
D	Heavy	Multiple	300,000 or more

Note: MTOW = Maximum Take-off Weight.

and

Table A2. Time-based wake turbulence separation minima for arriving aircraft [28].

Succeeding Aircraft	Preceding Aircraft	Arriving Separation Minima
Light	Medium	3 min
Medium	Heavy	2 min
Light	Heavy	3 min
Medium	A380	3 min
Light	A380	4 min

in Appendix A and Appendix B) can be achieved by comparing this estimated time with the predicted appearance times of other airplanes that have already left the holding fix and are flying towards the merge point. If this is not the case, the aircraft will be put on hold and the time comparison will be repeated at the next simulation time step chosen. Otherwise, clearance is given and the aircraft leaves its specified holding area. After the merge point, which is typically located in the approach transition, is crossed, the airplane can safely continue its landing. From this point, further conflicts cannot occur due to the use of speed restrictions.

Only one aircraft can use the holding pattern at a given altitude. If several airplanes have to be put on hold, the algorithm creates holding stacks. A holding stack is an overlay of holding patterns using the same holding fix but flown at different flight levels with a vertical separation of 1000 ft. The algorithm puts the aircraft in the holding stack by order of arrival and uses the same order for removing them (First In—First Out (FIFO)). Arriving aircraft are stacked at the holding fix, using the lowest altitude available above the preceding aircraft inside the stack. Every time an aircraft leaves, the holding stack has to be reorganised. In this respect, the algorithm will descend each aircraft one by one down to the next free level, clearing the higher levels for incoming aircraft.

In real live operations, at certain airports, such as Frankfurt, the so-called tromboning arrival procedure is applied. The final set of parallel legs composed of multiple waypoints of the STARs has the shape of a trombone, which the arrival procedure got its name from. The according STARs are implemented in the airside simulation environment and can be observed in Figure 6. In order to prevent conflicts within the TMA, aircraft sequencing has to begin before aircraft enter the intermediate approach phase, which is usually the beginning of the trombone-shaped airways. Depending on traffic volume, shortcuts through route changing, known as tromboning, are applied in the simulation model to reduce the remaining descent length.

However, path stretching as another tromboning method is only used to create gaps for departing aircraft (as in the Munich airport with mixed-mode runways). In the Frankfurt airport, path stretching or filling the gaps in the sequence have not yet been implemented. Normally, such Air Navigation (RNAV) procedures can be applied only fully in cases of low-to-medium traffic loads [29,30]. During peak periods, Air Traffic Controllers tend to revert to classic methods of sequencing the traffic flows to the runways. Furthermore, the authors consider tromboning as an optimisation method that can also be used to change the order of arriving aircraft to minimise separation and increase throughput per time.

Figure 6 shows a screenshot of the air traffic 3D simulation view, depicting the traffic flow within the TMA at the Frankfurt airport (EDDF) with flight tracks and multiple holding stacks. In order to translate controller instructions into the simulation environment, the airside simulation provides a pseudo pilot function, which allows us to access a specific aircraft and to manipulate heading, speed, and altitude in real time.

The airside traffic simulation was developed by means of the object-oriented language Java and the integrated development environment Eclipse. The simulation constitutes a modular character. To reduce computational costs, the simulation enables multi-threading.

A three-dimensional visualisation of the particular trajectories and aircraft was implemented using OpenGL. The visualisation incorporates Google Maps satellite images. Figure 7 illustrates the capabilities of the visualisation.

Despite the great amount of functionalities, the airside simulation software also enables Monte Carlo investigations. An overview of the Java project comprising the folders, packages, and classes of the object-oriented airside simulation part can be found in

Table A4. Java project comprising folders, packages, and classes of the object-oriented airside simulation part (current state of development).

Folder	Package	Classes
src	animator	Main, Renderer, TextBox, Indicator, Logo
	sim	Core, FlightplanPreProcessor, FlightplanProcessor
	settings	General, Display
	ganp	KPI, Logger
	mysql	MySQL
	mqtt	MQTT
	util	MouseSelectionDetector, FrustumVisibility, ShaderUtils, TextureUtils
Aircraft	aircraft	Aircraft, TrajectoryCalculator, BADA, WakeTurbulence
	engine	Engine, Turbofan, Turboprop, Piston
	type	Shape, Conventional, Novel, Trail, VertexBufferObject
Airport	airport	Airport, JOSMLoader, VertexBufferObject
	runway	Runway, RunwayLoader, Operation
Mapping	navigation	Geodesy, Mercator, WorldMap, GO2, Topography, VertexBufferObject
GUI	gui	ToolbarSlindingPanel, SlidingJPanel, OverlayPanel, PopupMenu, Slider, AdvancedButton, VerticalButton, VerticalLabelUI
	media	MediaPlayer, CameraControler, AWTSequenceEncoder, AWTUtil
Atmosphere	atmosphere	ISA, GRIB2Loader, Wind, Temperature
ATC	enroute	CDR
	tma	CIFPLoader, SID, STAR, ArrivalProcedure, Classic, Trombone, DepartureManager
	holding	Holding, Loader

Note: GANP = Global Air Navigation Plan; JOSM = Java Open Street Map; ISA = International Standard Atmosphere; ATC = Air Traffic Contol; CDR = Conflict Detection and Resolution; CIFP = Coded Instrument Flight Procedures.

in Appendix C.

2.4. MySQL Data Exchange

This section addresses the coupling of both simulation parts. The synchronisation between the two simulation parts is executed via a MySQL table. When a calculation is completed, a Boolean entry in a MySQL table is made via the respective simulation part. At the same time instant, this part proceeds to the next time step. The other simulation part is on hold until the Boolean entry becomes available and starts the computations of the following time step immediately. The current sampling frequency is 100 Hz, though it has to be mentioned that this is constrained by the performance of the MySQL server and the respective network. The MySQL server as well as each simulation part runs on different computers within the network of the Institute of Flight Guidance. Information concerning the performance of the coupled framework can be found in Section 2.6. Both simulation parts can perform in real and in fast time.

Table 3. MySQL table with exemplary entries in the landside part.

Id	Registration	ALDT	ETOT	Airport	ac_Type	Runway
1	0		2018-08-25 03:57:00	EDDB	A319
⋮	⋮	⋮	⋮	⋮	⋮	⋮
1795	411	2018-08-25 10:16:44	2018-08-25 11:47:00	EDDF	A320	25L
1796	867	2018-08-25 10:16:50		EDDM	B735	26L
⋮	⋮	⋮	⋮	⋮	⋮	⋮

illustrates an example of the data exchange between air- and landside, taken from the simulation scenario, described further in Section 4. As inputs, the landside receives information about airport, aircraft type, runway, Estimated Take-Off Time (ETOT), Actual Landing Time (ALDT), or the registration of the aircraft. The registration allows us to access all information concerning flight legs during a day. The id represents an unambiguous identification within the landside part. A typical traffic scenario of a day includes aircraft which stayed overnight and wait for the next day. This is shown in the example of id = 1. In this example, no available landing time and missing runway translate to the aircraft on the ground, which are waiting to begin the remaining turnaround processes, to be prepared for the next flight leg. An aircraft which goes through the standard turnaround process is exemplarily shown in id = 1795. It has to be mentioned that the time interval between landing and Estimated Take-Off Time may exceed the sum of turnaround and taxi-in and -out durations for a particular aircraft at a particular airport.

We introduced a parameter ${{\Delta }_{TA}}_{start}$, which defines the time interval before the turnaround process begins, depending on the ETOT and taxi-out time. This is performed in order to avoid premature conclusions of the turnaround processes. It is also used for a first calibration of the combined simulation environment, which is illustrated further in Section 3. In the case of gaps between ALDT and Estimated Landing Time (ELDT), the Actual Take-Off Time (ATOT) deviates from the flight plan. This has to be considered. In this case, the turnaround process is split into two processes. This applies as well for large time intervals between ELDT and ETOT. This, for example, allows for timely passenger dis-embarkation on the one hand and time-adjusted boarding on the other hand. Id = 1796 shows an example of an incoming flight. As described above, the turnaround procedure only covers the according sub-processes, which are applied on arriving aircraft. This will be discussed in more detail in Section 2.5.

In the Munich airport, runways are operated in mix mode and used for both take-offs and landings. To minimise the risk of runway incursion, runway operations need to be carefully managed. In the following, the management of runways in mixed mode in the simulation model will be described in more detail. When the turnaround process is finished, a taxi clearance to an assigned runway is issued to an aircraft. After reaching the runway threshold, the corresponding MySQL table is filled with information on aircraft registration and runway designator by the landside, as exemplarily shown in

Table 4. MySQL table with an exemplary exit from the landside part.

Id	Registration	Threshold	Runway
⋮	⋮	⋮	⋮
2255	373	2018-08-25 16:11:00	26L
⋮	⋮	⋮	⋮

. A further take-off clearance is now expected from the airside simulation environment in a separate MySQL table. When the clearance is received by the landside part, the aircraft entity is transferred over to the airside. A separation minimum of 2 min is applied between arriving and departing aircraft [28]. Depending on traffic, ATCs may create gaps in the arriving sequence via path stretching or holdings to enable departures and avoid excessive delays. Departing aircraft in the queue on the ground are sequenced according to

Table A3. Time-based wake turbulence separation minima for departing aircraft [28].

Succeeding Aircraft	Preceding Aircraft	Departing Separation Minima
Light	Medium	2 min
Medium	Heavy	2 min
Light	Heavy	2 min
Medium	A380	3 min
Light	A380	3 min

in Appendix B.

After introducing the airside simulation and describing the data exchange to and from the landside, the following subsection discusses elements of the landside simulation part in more detail.

2.5. Airport Simulation

The part of the landside simulation is primarily intended to reflect the particular turnaround process of an aircraft at an airport. This encompasses respective sub-processes such as boarding or re-fueling and is applied for all European airports within the model. For selected airports, a simplified taxiing simulation is employed.

Many domains of the ATS such as the turnaround are represented by schedules, capacities, and resources. Typically, a variety of processes are structured in a sequential or parallel manner and decisions of stakeholders often guide the proceedings of the particular systems. This logistic-related character can be attributed to many processes and their respective sub-processes within the Air Traffic System. Therefore, a translation into a discrete event system was deemed reasonable by the authors. In a discrete event model, a new state of the system is computed if an event is occurring. Discrete event modelling, or Discrete Event Simulation (DES), comprises elements like resources, routing, buffers, sequencing, or entities which proceed through a network.

In order to overcome the drawback of lower levels of detail in flow-based-related simulations, the turnaround and the taxiing processes were implemented using a modular simulation environment which is based on the DES package SimEvents [31]. The used environment is added using tailored legacy functions for particular applications. SimEvents itself is a transaction-based modelling method, where entities flow as commodities through the system or network from node to node. Events evoke the advancing of an entity in the network, such as the beginning or the end of a process. Typical modelling blocks of this DES environment, which can also be found in other Discrete Event Simulation environments, comprise generators for entities or random numbers, sinks, servers, gates, or queues. Entities can be assigned with attributes, which can then be manipulated during the course of the entity passing through the network, thus affecting its proceeding. With regard to the turnaround, an aircraft is represented by an entity which is assigned with particular attributes such as aircraft weight class and proceeds through the different sub-processes.

The applied hierarchical approach allows us to easily translate real-life workflows into the model. Typical workflows in ground operations are often represented by the synchronisation, choice, sequence, and concurrency of processes. The hierarchical character of the environment also enables the integration of different levels of detail for selected parts of the model. DES is also widely used in the domain of crisis management, such as in hospitals, where similar abstractions can be assumed, like representing a patient as an entity with distinct attributes which passes through different stations after admission. In [32], an example of an application of the presented DES environment is presented. In this case, a ferry evacuation scenario, which shows familiar logistic-related characteristics, was modelled. Sensitivity studies of the model were performed to detect bottlenecks and to provide insights into error propagation, resources allocation, or other improved mitigation measures.

In order to mitigate the implications of disruptions in a complex socio-technical system such as the Air Traffic System, one has to achieve an understanding of the interdependencies between the different and numerous components. The landside simulation foresees an interaction with human operators, such as an agent in an Airline Operation Center. Therefore, mitigation actions such as flight cancellations or shortened turnaround processes can be depicted. The actions of human operators can be implemented using legacy building blocks.

Figure 8 shows the typical workflow of the simplified turnaround process depicted in SimEvents for the general incoming and outgoing traffic used in the model. As an example, the boarding process is selected to illustrate the principle of entity flow or attribute assignment of process duration, which depends on the aircraft type. The particular deterministic durations were derived from the Gantt charts of the respective manufacturer; see, for example, [24]. Probabilities of the occurrence of a disturbance or the respective distributions can be implemented using random generator blocks. The according data foundation will be addressed in Section 4. Furthermore, sub-process distributions or dependencies on arrival delays, as available in [21], can be easily applied.

Hierarchical modelling enables the domain expert to model and alter different processes at different levels of detail, thereby introducing microscopic effects at selected parts of the simulation. For example, the boarding process could be modelled for new types of aircraft shapes, as performed in [33]. By means of the environment, an easy integration of questions related to future propulsion concepts is facilitated. That includes aspects such as the loading cycles of fully electrified aircraft, which have to be integrated into a future turnaround process.

The whole turnaround process itself can be adapted as well, for example, to fit the needs of in- or outbound flights. The respective turnaround models are illustrated in Figure 9. Analogue to the turnaround process, the taxiing process can be represented by servers, which define the duration which an entity (here the aircraft) spends at a particular taxi leg. Generally, the aim of a more detailed modelling of the taxiing process is to better reflect Actual In-Block Times (AIBTs), which themselves affect turnaround procedures. Combined with more realistic Actual Off-Block Times (AOBTs), which are provided via more realistic models of the turnaround process, Actual Taxi-Out Times (AXOTs) enable more realistic departing traffic.

One selected airport, Hanover, consists of a more detailed taxiing simulation that considers the taxi topology. The topology itself is represented by a graph, which can be procured from free available data; see [23]. The according graph is translated into a distance matrix, which serves to derive the taxi duration for the particular leg. Based on the comprehensive graph, a simplified model of the taxiways is deducted by means of DES elements. Here, servers represent taxiway elements and the aircraft as entity proceeds along a given route, depending on the arrival runway and a free available gate. Outgoing taxi traffic proceeds to the departure runway. Conflict resolution on the ground follows the FIFO principle of the occupied servers. The capacity of a server that represents a taxiway element is defined by its length and the distance between following aircraft. Subsequently, the level of detail of the model can be increased gradually.

Figure 10 shows the visualisation of the taxiing model with the according graph. In this example, arriving traffic uses the runway 27R and outgoing traffic the runway 27L. Since a temporal solution of one minute seems sufficient for most turnaround processes, the taxiing process in this example is modelled using the same resolution. That, on the other hand, leads to deviations, considering the different taxi legs as presented in the underlying graph and the according distance matrix. For that particular model, a taxiing speed of 15 kts is assumed. The respective differences of the example above, resulting from summarising particular taxi legs (the distances between two nodes), follow for the node sequence [92 119 9 10 12] for 12.8%, [12 18 20 23] for 4.7%, and [23 26 36 41 42 51 59] for 18% deviation. This particular node sequence leads to Terminal A. Due to the scalability of the environment, a higher temporal granularity of one second can be applied, allowing for a more refined representation of ground traffic.

Besides one low-level modelled airport, all other airports assume simplified taxi times. The according data were derived from the different runway configurations of airports, as seen in [34], and linked to the taxi-in and taxi-out durations of three classes of airports of different sizes, as collated by EUROCONTROL [35]. The three airport classes were assigned under the following assumptions for the particular runway configurations: In the case of small airports, we selected runway configuration A. In the case of large airports, we selected runway configurations D, E, L, M, or N. The remaining configurations were assumed as medium-sized airports. A graphical interpretation of the different runway configurations can be found in

Table A5. Estimates of hourly and annual capacities, own representation based on [34].

Runway Configuration		Mix Index [%]	Hourly Capacity		Annual Service Volume
			VFR	IFR
A		0–20	98	59	230,000
		21–50	74	57	195,000
		51–80	63	56	205,000
		81–120	55	53	210,000
		121–180	51	50	240,000
B		0–20	197	59	355,000
		21–50	145	57	275,000
		51–80	121	56	260,000
		81–120	105	59	285,000
		121–180	94	60	340,000
C		0–20	197	119	370,000
		21–50	149	114	320,000
		51–80	126	111	305,000
		81–120	111	105	315,000
		121–180	103	99	370,000
D		0–20	295	62	385,000
		21–50	219	63	310,000
		51–80	184	65	290,000
		81–120	161	70	315,000
		121–180	146	75	385,000
E		0–20	394	119	715,000
		21–50	290	114	550,000
		51–80	242	111	515,000
		81–120	210	117	565,000
		121–180	189	120	675,000
F		0–20	98	59	230,000
		21–50	77	57	200,000
		51–80	77	56	215,000
		81–120	76	59	225,000
		121–180	72	60	265,000
G		0–20	150	59	270,000
		21–50	108	57	225,000
		51–80	85	56	220,000
		81–120	77	59	225,000
		121–180	73	60	265,000
H		0–20	132	59	260,000
		21–50	99	57	220,000
		51–80	82	56	215,000
		81–120	77	59	225,000
		121–180	73	60	265,000
I		0–20	150	59	270,000
		21–50	108	57	225,000
		51–80	85	56	220,000
		81–120	77	59	225,000
		121–180	73	60	265,000
J		0–20	132	59	260,000
		21–50	99	57	220,000
		51–80	82	56	215,000
		81–120	77	59	225,000
		121–180	73	60	265,000
K		0–20	197	59	355,000
		21–50	145	57	275,000
		51–80	121	56	260,000
		81–120	105	59	285,000
		121–180	94	60	340,000
L		0–20	197	119	370,000
		21–50	149	114	320,000
		51–80	126	111	305,000
		81–120	111	105	315,000
		121–180	103	99	370,000
M		0–20	295	59	385,000
		21–50	210	57	305,000
		51–80	164	56	275,000
		81–120	146	59	300,000
		121–180	129	60	355,000
N		0–20	295	59	385,000
		21-50	210	57	305,000
		51-80	164	56	275,000
		81-120	146	59	300,000
		121-180	129	60	355,000
O		0–20	197	59	355,000
		21–50	147	57	275,000
		51–80	145	56	270,000
		81–120	138	59	295,000
		121–180	125	60	350,000

Note: VFR = Visual Flight Rules; IFR = Instrument Flight Rules.

.

Figure 10. (Upper) Screenshot of the visualisation of the taxiing process [36]. (Lower) According graph with nodes and edges derived from data based on OpenStreetMap [23].

Figure 10. (Upper) Screenshot of the visualisation of the taxiing process [36]. (Lower) According graph with nodes and edges derived from data based on OpenStreetMap [23].

In addition to the modelling of taxiways in Hanover, the particular capacities on the ground were reflected. Three different terminals with a capacity of six, six, and eight gates, respectively, are considered, allowing for turnaround processes at each of the gates, thus posing a restriction on the absolute number of aircraft to be serviced on the ground without delay. Currently, the rest of the model assumes unlimited resources on the ground.

In the presented landside simulation environment, stochastic functionalities, such as varying process durations or probabilities of failure rates, enable the incorporation of historical real-life data. Such data can be procured from particular airports or airlines. Section 4 will discuss the data foundation derived from airline operational statistics, which is used for the simulation in Section 5. In addition to real-time simulation, the landside part enables fast-time simulation with incorporated seed management to facilitate Monte Carlo runs.

2.6. Performance Evaluation

To evaluate the performance of the coupled hybrid simulation environment, 100 simulation runs were conducted for a scenario containing 33,674 flights over 24 h with the given hardware specifications in

Table 5. Computer hardware specifications of both simulation parts and the MySQL server.

Part	CPU			RAM	GPU	OS
	Name	Core/Threads	Freq.
Airside	Intel Core i7-6700	4/8	3.4 GHz	32 GB	NVIDIA Quadro K420	Windows 7
Airport	Intel Core i5-7300HQ	4/4	2.5 GHz	16 GB	Intel HD Graphics 630	Windows 10
MySQL	Intel Xeon Gold 6154	18/36	3.0 GHz	384 GB	NVIDIA GeForce RTX 2080 Ti	Windows 10

. As a result, the average computation time of one simulation run yielded 314 s. Specific tests concerning the performance of the MySQL server were not conducted, though a substantial improvement can be achieved by using solid-state drives. Currently, the MySQL server represents the bottleneck in this simulation framework.

3. Validation

The validation aims to qualitatively reflect the flow of aircraft with respect to the flight plan. Here, a couple of airports were selected which are represented by SIDs and STARs. To ensure tangible results with respect to the flow of aircraft, firstly, qualitative interdependencies in the model have to be assessed by means of deterministic simulations. As a metric, the throughput at airports was chosen. The flight plan is built on [17]. All ground processes are assumed as deterministic, that is, the process durations depend on the particular aircraft type. The taxi durations follow the assumption made in Section 4. Furthermore, the beginning of ground processes depends on the ETOT, which is derived from the flight plan and expressed via the calibration value ${{\Delta }_{TA}}_{start}$. In the case of large deviations between the ELDT and ALDT, which leads to a different ATOT, the beginning of the turnaround process is delayed to a set limit. As expected, it can be observed that this limit substantially affects the throughput.

In Figure 11a, a comparison of arriving flights according to flight plan and simulation, respectively, is made for the reference airport of Hanover. Figure 11b shows the comparison between the departing aircraft. The allowed deviation between ETOT and ATOT is set to 30 min. In Hanover, the flow of simulated aircraft shows a very good correlation with the flight plan. Concerning the observed variation, one has to consider the influence of the calculated trajectories from all connected airports.

Figure 12b depicts the arriving and departing aircraft in Munich. Here, due to a more complex configuration of SIDs and STARs, as well as more occurring traffic, the deviation concerning landing and departing aircraft increases. However, it can be observed that the dynamic of the Munich airport is reflected qualitatively. Lastly, a further increase in complexity leads to more deviation from the flight plan, as shown for Frankfurt.

Figure 13b shows a larger deviation, especially for arriving aircraft. This is due to the increased time aircraft remain in the terminal airspace, for example, aircraft staying in holding patterns. Furthermore, for all airports, the flight plan assumes the landing of an aircraft at the ARP of the particular airport, thereby neglecting any SIDs and STARs. This inherent simplification in the flight plan affects larger airports more. This is due to a larger spatial extension, which leads up to greater variability in the trajectories. Lastly, since the flight plan incorporates actual weather conditions and thereby adapts runway configurations, it is assumed that the flight uses the following configuration: for arrivals, 25C, 25L, and 25R, and for departures, 18 and 25C; see also [37]. In contrast to that, the calculations for Frankfurt are based on arrivals on runways 25L and 25R and departures on runways 18 and 25C, as discussed in Section 4. The default setting for the operational directions of runways is to the west. Since weather is not explicitly considered, runway directions are not changed as well. Thus, as the flight plan, which includes weather, is used as a basis, an error arises. However, due to the largely symmetrically arranged SIDs and STARs, this is neglected in this concept paper.

4. Simulation Scenario

This section describes the data foundation and model assumptions considered for the Monte Carlo simulations in Section 5. Since this paper embodies a conceptual character, Monte Carlo simulations are performed neglecting weather influences. To represent stochastic influences, a couple of disturbances in ground operations are selected as well as data to model a general distinction between delayed and early flights. The latter data are taken from the CODA report [25]. The former are procured from the real operational data of an airline. The anonymised airline data include around 97,500 flights from the years 2017, 2018, and 2019. The data contain information about particular delay codes and respective delays. The delay codes embodied in the airline data are based on IATA delay codes. Figure 14 illustrates the simplified disruption and delay model applied in Section 5.

EUROCONTROL data are presented in grey and data accumulated by the airline in black. Since the disturbances are ground-related, the discrete event environment applies those by means of distribution functions. For each flight at the ground, a probability was applied to be cancelled. Further on, a distinction between early and delayed flights was made based on CODA. For the different classes of early flights, a uniform distribution was assumed. In the case of the first class of early flights, due to a lack of information, the lower boundary was set to minus 30 min. In the category of early flights, the turnaround model was not applied. With respect to delayed flights, the turnaround model presented in Section 2 was used and the likelihood of occurrence for a distinct IATA delay code was applied. The occurring event of a delay code evokes the respective distribution in order to calculate the minutes of delay. Most delays can be represented sufficiently by gamma distributions.

The data foundation encompasses 100 IATA delay codes, though it has to be stressed that for further investigations a more comprehensive data foundation is needed. On the one hand, this applies for the amount of data, since Gamma distributions were derived only given a satisfactory amount of available data; otherwise, Gaussian distributions were applied. On the other hand, the current data do not provide for differentiating between different types of aircraft or airports. For demonstrational purposes of the presented environment, the authors of this paper deemed the inherent simplifications in the data model as acceptable. It has to be stressed that the introduced disturbances, as described above, represent delay or reactionary delay, the latter constituting a result instead of an input. However, in these first simplified assumptions for an exemplary Monte Carlo simulation, they serve as input, thus neglecting the causal relationship.

The flight plan used in Section 5 was prepared for the simulation based on [17] and contains 33,674 flights during a 24 h period.

To reflect the mechanism of TMA operations as presented in Section 2, the Frankfurt airport (EDDF) was chosen with the runway configuration of arrival on runways 25L and 25R and departures on runways 18 and 25C. The Munich airport (EDDM) was implemented with the configuration 26R and 26L for arrival as well as departure. Within the project SE²A, the airport Hanover (EDDV) serves as a reference airport, so the simplified taxiing simulation presented in Section 2 was applied.

5. Exemplary Results

In this section, exemplary results of the presented hybrid simulation environment are discussed. Monte Carlo simulations are carried out on the basis of the scenario presented in Section 4. For a first quantification of the effects, the following Key Performance Indicators, as defined by ICAO [38], were calculated on the basis of 1000 simulation runs. All KPIs were computed for the airports Frankfurt am Main (EDDF) and Munich (EDDM).

5.1. KPI08—Additional Time in Terminal Airspace

Compared to the flight plan, actual flight trajectories are generally longer in distance and time due to path stretching, speed reductions, and holding patterns. The KPI08 is intended to give an indication of the average terminal airspace transit time during the arrival flight compared to an unimpeded time. It can also be used to estimate excess fuel consumption and associated emissions in the vicinity of airports. In this use case, the unimpeded time is calculated at airport level and constitutes the 20th percentile of actual terminal airspace transit times simulated at the analysed airport, sorted from the shortest to the longest. For the shape of the TMA, a generic cylinder with a 40 NM diameter is chosen.

This simple approach abstracts local specifics in terms of TMA design and ensures comparability across different airports. For each arriving flight, the terminal airspace entry time and the ALDT is recorded. The actual terminal airspace transit time is calculated by subtracting the terminal airspace entry time from the ALDT. Finally, actual terminal airspace transit time minus unimpeded terminal airspace transit time equals the additional time in terminal airspace.

In Figure 15, the additional time in terminal airspace is depicted for Frankfurt and Munich. As assumed, a wider variability can be observed in Frankfurt, which reflects the increased deviations between the flight plan and calculated arrivals, as discussed in Section 3. Also, the unimpeded time in Frankfurt is around 60% greater than Munich, reflecting more traffic being held up.

5.2. KPI19—Level-Off during Descent

This KPI is intended to give an indication of the amount of level flight after Top of Descent (TOD). During an optimal descent, due to the higher fuel burn, increased gaseous emissions, and possibly more noise, no level flight is expected. For the calculation of this KPI, level segments in the descent trajectory within the analysis radius of 200 NM are detected and respective time durations are determined.

Figure 16 visualises the level-off during descent. It can be observed that Munich shows substantially less level-off time. This again is related to the complexity of the airport and the traffic volume. In the simulation, Frankfurt accumulates considerably more holding stacks.

5.3. KPI11—Airport Throughput Efficiency

This KPI measures the efficiency of the airport throughput compared to capacity or demand, whichever is lower. It can be computed for arrivals, departures, or both. This KPI gives an indication of how effectively capacity is managed by the Air Navigation Service Provider (ANSP). In this case, the KPI relates the throughput to the unconstrained demand based on flight plans and is computed only for arrivals at the analysed airport EDDF. For each arriving flight, the calculated ALDT and ATOT as well as the ELDT and ETOT from the so6 flight plans are recorded. For each time interval (in this case, one hour), the throughput is measured by counting the number of actual landings based on ALDT. The demand equals the number of estimated landings based on ELDT. Finally, the airport throughput efficiency is calculated by dividing the throughput by the demand.

Figure 17 and Figure 18 illustrate the calculated KPI for airport throughput efficiency. Concerning the box plot, one can already observe large outliers. This might be due to the influence of early flights, which yield up to thirty minutes before Estimated Off-Block Time (EOBT). It has to be noted that the scenario overall incorporates large disturbances with respect to early flights.

6. Summary and Outlook

The presented concept of a hybrid fast-time gate-to-gate simulation platform AdAS consists of an air traffic and airport simulation environment. The environment aims to interweave a network-wide flow simulation with models of increased detail at specific parts of the Air Traffic System, able to perform Monte Carlo simulations.

The object-oriented airside simulation enables the fast calculation of 4D flight trajectories for a wide range of different aircraft types, using flight plans and BADA coefficients. The integrated OpenGL-based 3D rendering engine is used to visualise the simulated trajectories in real or fast time. Furthermore, the airside simulation performs automated detection and resolving of potential conflicts. This is achieved by manipulating the course, altitude, and velocity of an aircraft. In addition to the underlying flight plan, SIDs and STARs from over several hundred European airports are included in the calculation process, aiming to enhance the routing. At selected airports, the traffic flow within TMA is managed by means of arrival and departure procedures, taking wake turbulence separation minima into account.

The discrete event-based airport simulation environment is primarily used to reflect the turnaround process at all European airports. For one airport, a simplified taxiing simulation was applied. The taxiway network and the gate topology was mapped, whereas average taxi times were assumed at the other airports. On the ground, disturbance-related influences were taken into account by means of stochastic functionalities.

Both simulation environments are connected and synchronised by using a MySQL database, which in terms of performance currently represents the bottleneck.

Based on traffic scenarios, the hybrid simulation platform enables the investigation of local and global effects caused by disruptions, such as the introduction of electrically powered aircraft.

In a first exemplary use case, in order to illustrate interdependencies, CODA- and IATA-related disturbances were applied in Monte Carlo simulations. The presented simulation environment AdAS assesses the implications by means of Key Performance Indicators.

A first calibration of the model showed tangible results but has to be continued. This addresses both the procuring of data and refined modelling. The latter comprises the implementation of other arrival procedures, like point merge (as applied in London City) or further elaboration on tromboning. Ground-based sub-processes can be reflected in higher detail, such as boarding or loading being a function of passengers and fueling depending on range and costs. More realistic taxi durations and according distributions for individual airports as well as numbers of available gates ought to be implemented. The same applies for turnaround sub-processes and their dependencies on arrival delay. Lastly, an extension beyond the regions E and L should be considered, in order to better reflect influences on other regions. To account for the induced bias, in addition to the flight plan, calculations could be compared with historic ADS-B data.

As a next step, this hybrid simulation is intended to examine the consequences resulting from introducing electrically powered aircraft into the current Air Traffic System. The environment will consider respective air and landside modelling aspects, furnished to reflect the difference compared to conventional aircraft. This applies to different performance envelopes or charging requirements for batteries. Differences in the performance characteristics encompass climb and descent rates, achievable flight levels, and velocities or curve speeds. The airside simulation will incorporate those aircraft by transforming performance characteristics into BADA coefficients. New battery loading or changing cycles will be addressed via adapted processes within the landside simulation. This will affect available resources. The turnaround process will therefore be added by introducing a resource-based calculation of the durations of selected sub-processes.