Methodological Framework for Generation of Static Air Traffic Situations and Automated Complexity Data Extraction

Abstract

Existing simulation methods and tools available for air traffic complexity research have several limitations (such as time-consuming processing and complex data extraction) that hinder the simple and flexible collection of input data acquired from air traffic controllers (ATCOs). These limitations are particularly evident in research when representative and diverse data are needed, such as research on air traffic complexity based on ATCO input. To address this research gap, we present a new methodological framework for research in air traffic complexity, which incorporates ATCO input. The proposed methodological framework consists of three major components: (1) SATSI, a user-friendly interface for creating and visualizing various static air traffic situations (airspace, traffic, and contextual data), (2) a parser that converts SATSI outputs into inputs for the trajectory prediction model, and (3) an algorithm for automated extraction of terminal air traffic complexity indicators. All together, these components present a novel flexible tool for traffic scenario development, and its integration with the existing trajectory model and automatic processing of air traffic complexity data extraction. The proposed integrated framework shortens the overall research process by using simple and flexible air traffic scenario generation, facilitates automated data collection and enables broader and more representative studies of ATCO-perceived complexity.

1. Introduction

Air traffic management (ATM) is challenged by the lack of airspace capacity and the work overload of air traffic controllers (ATCOs). High ATCO workload caused by air traffic complexity [1] can decrease ATCO performance and endanger safety [2,3]. Complexity reduction is a possible solution to capacity and workload problems [4] happening in day-to-day operations. In order to reduce the complexity, it is necessary to use the appropriate method or model to determine or assess the complexity. ATCOs’ input is a highly valuable information when included in complexity model development [5]. There are various complexity models and methods developed with ATCO input [6,7,8,9,10,11,12,13,14,15]. ATCOs are the ones that experience complexity, and all other approaches for the determination of complexity are attempts to approximate its level considering the ATCOs’ subjective input [16]. This is even more emphasized in terminal airspace complexity because of the significantly lower number of conducted research than in en-route airspace. Research in air traffic complexity performed with ATCOs’ input requires an appropriate ATM tool.

To support ATM research, a variety of simulation tools have been developed, enabling the evaluation of new technologies, procedures, and policies under realistic conditions [17]. Fast-time simulations, such as the ones in NEST/R-NEST or CASSIOPEIA, are the trusted methods to examine historical traffic data or analyze new concepts or regulations. Such simulations consist of rules and limitations that traffic follows, and they provide results in a short time. The disadvantage of fast-time simulation is that it does not support human interaction, which is needed for ATCOs’ input. Such support is available in real-time simulations. Simulators such as ESCAPE, BlueSky, or AirTrafficSim enable human-in-the-loop interaction. In recent studies, simulations with ATCOs and pseudo-pilots have been performed to validate novel operational concepts [18]. Simulations require a large amount of time and support from the simulation team, starting with preparation to data analysis. Research is extensive, long-lasting, requires large funding and data gathering. Also, such a method is not appropriate for complexity research as ATCOs find it difficult to distinguish workload from complexity in real-time simulations [1]. This can result in incorrect data from ATCO input, which can further impact the overall complexity of research and produce wrong results. To overcome this problem, authors in [19] have successfully used static images of en-route air traffic for complexity evaluation. Existing design software was used for situation development and en-route air traffic complexity indicators were automatically extracted, which resulted in a highly accurate and validated complexity model. Research showed that the usage of static air traffic situations in the evaluation of complexity is an adequate research solution when ATCOs’ complexity input is needed. It allows ATCOs to focus on complexity without mistaking it for workload, which can happen when real-time human-in-the-loop simulations are used. When creating static air traffic situations, it is possible to use real-time simulators in such a way that the radar screen is paused, and a static air traffic situation is taken as an image. Due to a large number of different static air traffic complexity situations that should be developed, this is considered a rather time-consuming process. It would take a lot of time to develop a large number of traffic scenarios in real time simulator with specifically required altitude or flight level, speed and other aircraft parameters that could cover all air traffic complexity indicators. Also, the extraction of data that is important for complexity would be a problem, as simulators usually save traffic data for the whole duration of the exercise, but not for the exact moment of an air traffic situation. As far as we know, there is no existing open-source interface where it is possible to enter airspace and traffic data for visual representation of the exact moment of an air traffic situation that is to be used for further complexity data processing. Such an interface should enable entry of any airspace data, flight plan and additional information for ATCOs’ complexity evaluation. Complexity data should be extracted easily for further research and analysis of the static air traffic situation.

The main contributions of this work are the development of the methodological framework, which consists of an interface to generate static air traffic situations (SATSI), an algorithm for parsing trajectory prediction model input data and an algorithm for automated extraction of air traffic complexity indicators. Additionally, this approach and usage of the framework shorten the overall complexity of the research process when ATCO input is used, which is achieved through fast and easy input of airspace and traffic data, automation of data processing and indicator extraction. Complexity indicators used in this work are the terminal air traffic complexity indicators based on ATCO tasks from Ref. [5]. Thus, the interface that generates static air traffic situations enables input of the terminal airspace specifications required for complexity evaluation.

The manuscript is organized into five sections. Each part of the framework is described in a separate section. An interface for static air traffic situations is introduced and explained in Section 2. In Section 3, the algorithm for forming data input for trajectory prediction model is given. Section 4 describes how the algorithm for complexity indicator extraction functions, and in the final Section 5 conclusion and future work are given.

2. Static Air Traffic Situation Interface SATSI

The flowchart of the methodological framework is presented in Figure 1. Each of the three main parts of the framework is coloured differently for distinction. The first of the three modules is SATSI, a new interface that enables the development of static air traffic situations using airspace and traffic data. SATSI data is parsed in a new algorithm that enables input in trajectories calculation model. The algorithm for the extraction of complexity indicators uses aircraft trajectories and, together with the calculation of previously developed terminal complexity indicators, enables fast and efficient generation of data necessary for further air traffic complexity research.

The first step in the framework design is developing an interface to create static air traffic situations. Prior to the development of SATSI, it was necessary to determine the most important specifications that an interface should have. The main focus is on fast and easy input of airspace and traffic data, which can be saved and extracted for further processing. Another important requirement is that the terminal airspace and all the required data that describe the traffic situation can be presented in a clearly visible and readable format. Terminal airspace, in contrast to en-route sectors, requires presentation of control zones, runways, Departure tables and minimum radar vectoring altitudes. All this data is important for ATCOs’ input in complexity evaluation. Fast-time and real-time tools were considered for these requirements. Although they have benefits such as required time for airspace data preparation for fast-time tools or presentation of air traffic situation that enables ATCO input in real-time tools, none of them offers a complete solution required for the research in complexity with ATCO input. Qualitative comparison based on relevant features of SATSI, fast-time and real-time tools presented in

Table 1. Qualitative comparison of SATSI, fast-time and real-time tools.

	Relevant Features	Fast-Time Tools	Real-Time Tools	SATSI
1	Required time for airspace data preparation	short	time-consuming (significant or less significant amount of time)	short
2	Required time for generation of air traffic situations	short	time-consuming (significant amount of time due to required high number of different air traffic situations)	short
3	ATCO input for complexity evaluation	unable	able	able
4	Processing data of the exact moment of ATCO input	unable	able with adequate post-processing of the entire scenario	able
5	Automated extraction of complexity indicators	unable	unable	able within this methodological framework
6	Operational fidelity	unable	able	able
7	Workload assessment	unable	able	unable
8	Communication ATCO-pseudo pilot	unable	able	unable
9	Fast historic data examination	able	unable	unable
10	Complete validation of new ATCO tools	unable	able	unable

additionally emphasize the need for SATSI development.

Table 1 comprises the benefits and limitations of SATSI, fast-time and real-time tools for every specific feature. Although real-time tools show overall advantages compared to SATSI and fast-time tools, only the first five features are key and important features for the research of air traffic complexity with ATCO input. SATSI has several advantages compared to the real-time simulations regarding features 1, 2 and 4 (short time for airspace data preparation, air traffic situations generation and processing situation data on ATCO input), but the most important advantage is automated extraction of air traffic complexity indicators (feature 5). The benefits of SATSI compared to fast-time tools are obvious regarding features 3–5.

2.1. Development and Specifications of the Interface

SATSI is developed in Python 3.12.0 using PyQt framework, version 6.6.1 [20]. The interface consists of two main parts: Airspace visualization and Additional data. The first part, Airspace visualization, which is placed on the left, is a larger blank space used to visualize the airspace and traffic data. It enables visualization of airspace boundary, entry and exit points, lines and values of Air Traffic Services surveillance minimum altitude, points inside the airspace, final approach fix (FAF), control zone boundary and runway. All those data elements have their corresponding visual characterization, such as line thickness, point size and font size. Predefined toggle keys are used to enable or disable input of different situational elements through the interface. SATSI also has a drag-and-drop option inside the Airspace visualization to circumvent potential overlaps of different visual elements. Once the airspace data is set and saved, it can be reused in multiple air traffic situations. For faster and easier data input, certain data, such as entry and exit points for particular airspaces, are predefined. An example of a generic airspace made in SATSI is presented in Figure 2. The generic airspace design was inspired by existing terminal airspaces that have a single runway and use Area navigation (RNAV). The entry points in Figure 2 have names with entry flight levels in blue colour and exit flight levels in orange. The control zone is shown as a rectangle with the runway as a line and the FAF as an X. MRVAs are shown in the areas separated with grey lines. RNAV points are indicated with a rhombus. Upon development of a new airspace in the interface, it should be taken into account that 10 pixels represent one geographic second, where the coordinate system starts at the bottom left screen corner. Airspace visualization supports 157 nautical miles in the y-axis and 219 in the x-axis due to the screen resolution used during interface development.

In the Airspace visualization, except for the airspace data, it is necessary to enter aircraft flight labels by filling aircraft data in data input dialogue box (aircraft call sign, aircraft type, wake turbulence category, actual, selected and exit altitude/flight level, arrow for descent or climb, ground speed, destination information, next point, route, assigned heading and current vector heading (Figure 3).

Destination information only allows the entry of letters A, D, or O, which are used to mark the aircraft status (arrival, departure, overflight) and determine the colour of the aircraft (letter A in blue colour, letter D in orange and letter O in green). Visualization of aircraft symbols and labels in colours is chosen so that the ATCOs can get an insight into air traffic situations faster and easier. Additional information about flight time until the final approach fix (FAF) point is calculated for arriving flights and presented on the label after the next point. It is calculated based on the inserted aircraft speed and direct distance from the current position to FAF, the value being presented in minutes. In order to get the correct calculation of time, it is important to consider the resolution in which the interface is displayed with respect to the size of the airspace. Information about the aircraft route is given in the label as aircraft follow RNAV routes or have direct routes and only information about the next point and/or exit is enough. An aircraft route is saved and used later for the calculation of the aircraft trajectory. Except for the points, aircraft altitude and speed on that points are shown, if available. Vector heading information determines the vector of the aircraft and its length is determined based on the aircraft ground speed. The aircraft is positioned by double-clicking the wanted position, after which the input dialog box opens. The minimum required set of information for an aircraft to be successfully positioned is: the entered ground speed, information about arrival, departure or overflight, and current vector heading. Interface accepts all combinations of speeds, levels and headings. An error of speed or heading entry is clearly visible upon aircraft entry as the minute vector is too long/short or deviates from the route. An example of an air traffic situation with aircraft labels in a generic airspace is presented in Figure 4. This air traffic situation is used as a case study to present the methodological framework.

Another part of the SATSI, Additional data, is presented on the right side of the screen with a grey background (Figure 5). It enables the presentation of information that is required in order to have a complete overview of the air traffic situation. It is possible to enter the Departure table, Text box with additional important information, Wind table and as well as the Text box for the name of the air traffic situation that is activated. The Departure table can list aircraft on the ground that have started up and gives information about their expected time of departure, exit points and exit flight levels. The Text box enables input of additional important information, such as runway closed or activated zone. In the Wind table it is possible to provide information about wind direction and speed at a certain flight level. In the second Text box a name of the air traffic situation can be given. An example of additional information given on the right side of the SATSI is presented in Figure 5. All the information about airspace data and each air traffic situation, including tables, is saved for later data processing.

2.2. Terminal Airspace and Static Traffic Situations in SATSI

SATSI supports the development of different terminal airspaces as well as en-route airspace. Generic airspace, which can be seen in Figure 2, Figure 3 and Figure 4 is modelled on the existing terminal airspaces with one runway. It has seven entry and exit points, sixteen waypoints, six RNAV standard instrument arrival routes, five RNAV standard instrument departure routes and it surrounds one airport with a single runway orientation 09–27 (Figure 6). Arrivals and departures follow one of the RNAV standard instrument routes, while overflights take direct routes from entry to exit point. ATCOs in such airspace handle arrivals, departures and overflights. Once generic airspace is made in SATSI, it is saved and can be reused to develop new air traffic situations. This enables fast input of traffic data.

Static air traffic situations can be developed to have different numbers of aircraft in different stages of flight, to have different routes and various flight levels or altitudes. Air traffic is a combination of arriving flights, departing flights and overflights with different wake turbulence categories, i.e., light, medium, heavy and super heavy. All this contributes to different complexity levels of static air traffic situations. Upon research in air traffic complexity, it is important to provide a large set of different air traffic situations that this interface enables. Analysis of static air traffic situations differs from the analysis of dynamic scenarios. While analysis of dynamic scenarios collects all air traffic data from scenario duration, static analysis is focused on the exact moment of the air traffic situation. It includes the processing of current aircraft data and aircraft interactions, which are visible to ATCO at that specific moment. This enables ATCOs to carefully analyze specific characteristics of every given air traffic situation and to evaluate complexity more accurately.

3. Algorithm for Parsing Trajectory Prediction Model Input Data

One segment of the novel method is using an existing trajectory prediction model that generates aircraft trajectories from SATSI data. Trajectories provide important data for the extraction of the complexity indicators. The trajectory prediction model is explained in Section 3.2. It requires a specific form of data entry to generate trajectories. Thus, the algorithm that parses SATSI data to be adequate for the model input is developed. The algorithms’ input and output data are described in the next sections.

3.1. SATSI Data Storage

Airspace and traffic data from SATSI are saved in several different formats. Point-type airspace data and boundaries are saved as screen pixel coordinates, while the airspace image is saved as a PNG file. Traffic aircraft data is saved as json file, situation as PNG data, and if there is a Departure table, it is saved as a CSV file.

Aircraft data and Departure table contain information that is used for trajectory calculation. Data entry is explained in Section 2.1 except for PointX and PointY. They are the aircraft’s start coordinates on the screen, i.e., pixels. An example of saved aircraft data as json file, for flight DLH965, which can be seen in the traffic situation in Figure 5, is given below:

{

"Callsign": "DLH965",

"AircraftType": "B763",

"WTC": "H",

"AFL": "172",

"Arrow": "\ud83e\udc7b",

"CFL": "160",

"GroundSpeed": "393",

"ADES": "A",

"XFL": "30",

"NextPoint": "ADSOU",

"FAFTime": 13,

"Route": "ADSOU, 160, , TR408, , MAX 302, IAF SOUTH, MAX 60, , TR404, , MAX 257, IAF EASTE, MAX 40, , IF DOJ, MIN 30, , FAF, 30, , RWY,0, ,\n",

"Heading": "",

"VectorDirection": "330",

"PointX": 592,

"PointY": 893

}.

An example of a Departure table saved as a CSV file, from the traffic situation in Figure 5, is given:

CS/TYPE/CAT,DEP TIME,EXIT POINT,XFL

,,,

THY972 A332 H,3 MIN,DENOR,120

CTN655 DH8D M,5 MIN,ADNOR,150

,,,.

3.2. Development of Algorithm for Parsing Trajectory Prediction Model Input Data

The trajectory prediction model forms 4D aircraft trajectories. Trajectories are generated using the Base of Aircraft Data family 3 (BADA 3) performance data and a 6 degrees-of-freedom point mass model as an aircraft movement model. BADA is a performance database developed by EUROCONTROL to support aircraft trajectory simulation and prediction [21]. Since 2005, it has served as a standard resource in air traffic management research, using a kinetic approach to model how different aircraft types behave. The system consists of two parts: a model specifications which is defined by Operations Performance Model, Airline Procedure Models and Global Aircraft Parameters, and a dataset containing coefficients for various aircraft types. Today, BADA is used for everything from developing new flight procedures to assessing aircraft emissions. It provides the essential performance limits that enable modelling fuel burn, speed, and altitude changes accurately.

Trajectory prediction is simulated, as mentioned, by a 6 degrees-of-freedom point mass model based on an approach developed and improved in Refs. [12,22,23,24]. The model is defined by two separate modules, Aircraft Dynamic and the Flight Management System (FMS), working in a constant loop feeding one another with required data. Aircraft Dynamic system that tracks six state variables to map out the plane’s actual path is based on specific inputs of FMS and external disturbances. The FMS model acts as the decision-maker, constantly adjusting these inputs to ensure that the aircraft follows its flight plan while staying within operational limits and responding to factors like weather. By combining BADA’s performance limits with these dynamic and guidance models, we can define aircraft trajectory in a complex environment.

Aircraft flight plans are used as input for the trajectory prediction model. Flight plan data should have a specific format in order to be used by the trajectory prediction model. Format is based on the so6 traffic data from EUROCONTROLs Demand Data Repository portal version 2, which collects historical traffic data from various sources [25,26]. It consists of 20 different types of alphabetical or numerical data for each flight segment of one aircraft (

Table 2. Explanation of entry data for a flight segment [25].

Column Number	Description
1	segment identifier
2	origin of flight
3	destination of flight
4	aircraft type
5	time at the beginning of a segment [DDHHMM]
6	time at the end of a segment [DDHHMM]
7	flight level at the beginning of a segment
8	flight level at the end of a segment
9	status (aircraft flight regime—climb descent, or cruise)
10	callsign
11	date at the beginning of a segment [YYMMDD]
12	date at the end of a segment [YYMMDD]
13	latitude at the beginning of a segment [minutes]
14	longitude at the beginning of a segment [minutes]
15	latitude at the end of a segment [minutes]
16	longitude at the end of a segment [minutes]
17	flight identifier (unique code designated by EUROCONTROL)
18	sequence
19	segment length [NM]
20	segment parity/colour

).

As previously said, SATSI data should be transformed into a format readable to a trajectory prediction model, written in MATLAB. The algorithm is designed to create one so6 file for each air traffic situation, where each line represents a particular flight segment, and the arrangement of data in each flight segment follows the convention from Table 2. A part of the SATSI data keeps original values, while another part is calculated and adjusted to satisfy the expected format as stated in Table 2. For example, the aircraft coordinates are remapped from pixel values to decimal minutes. The geographical coordinate system starts at the bottom left of the airspace, where 10 pixels represent 1 geographic second. Geographic coordinates are assigned to all aircraft starting points and all points on their route.

3.3. Algorithm and Trajectory Prediction Model Output

The parsing algorithm outputs one file for each air traffic situation, where data for one aircraft is presented in a sequence of lines, and different aircraft are separated by a blank line. Below are examples of output for three different aircraft:

start_tr413 ldtr ldsp b738 010001 010002 71 110 0 sas756 230323 230323 79.833 99.0 63.167 106.667 167 1 1 0

tr413_adepe ldtr ldsp b738 010002 010003 110 170 0 sas756 230323 230323 63.167 106.667 40.0 159.167 167 2 1 0

start_adsou ldsp ldza glex 010001 010002 160 120 2 eju521 230323 230323 75.833 133.0 18.667 93.333 500 1 1 0

start_tr403 ldsp ldtr b77w 010001 010002 130 80 1 aua499 230323 230323 134.167 92.5 99.0 109.0 215 1 1 0

tr403_iafnorth ldsp ldtr b77w 010002 010003 80 60 1 aua499 230323 230323 99.0 109.0 99.0 118.333 215 2 1 0

iafnorth_tr401 ldsp ldtr b77w 010003 010004 60 60 1 aua499 230323 230323 99.0 118.333 98.833 122.833 215 3 1 0

tr401_iafeaste ldsp ldtr b77w 010004 010005 60 40 1 aua499 230323 230323 98.833 122.833 94.5 123.0 215 4 1 0

iafeaste_ifdoj ldsp ldtr b77w 010005 010006 40 30 1 aua499 230323 230323 94.5 123.0 94.5 118.667 215 5 1 0

ifdoj_faf ldsp ldtr b77w 010006 010007 30 30 1 aua499 230323 230323 94.5 118.667 94.5 114.833 215 6 1 0

faf_ldtr ldsp ldtr b77w 010007 010008 30 0 1 aua499 230323 230323 94.5 114.833 94.333 107.833 215 7 1 0.

The first two lines represent data for departure flight SAS756, the third line represents data for overflight EJU521, and the rest are for the arrival flight AUA499 from the traffic situation in Figure 4. Output of the parsing algorithm represents data in a format suitable for input into the trajectory prediction model. The trajectory data output from the trajectory prediction model is used as one of multiple data types for the extraction of terminal complexity indicators. The trajectory prediction model provides aircraft trajectory data for each second of the flight. An example of 2D trajectories for a traffic situation from Figure 4 is presented in Figure 7. Each colour represents one flight. Overflight and departing flights end their route upon reaching exit points, while arrivals end their route upon reaching the runway. The use of BADA 4 might give a more precise result for aircraft trajectories, while the model uses currently available BADA 3.

4. Algorithm for Automated Extraction of Terminal Air Traffic Complexity Indicators

At last, the created methodological framework uses an algorithm for the extraction of terminal air traffic complexity indicators. Its automatization replaces manual calculation of the complexity indicators for each air traffic situation, which expedites the procedure. The algorithm combines SATSI, airspace data and trajectory data for its calculations. Each air traffic situation has its own set of complexity indicators that require extraction. General and separational complexity indicators from Ref. [5] are extracted by the algorithm to develop nominal static traffic situations.

4.1. Development of Algorithm for Automated Extraction of Terminal Air Traffic Complexity Indicators

Terminal complexity indicators for nominal traffic situations from Ref. [5] are differentiated as General Indicators (1–5) and Separational Indicators (5–12). They are listed in

Table 3. Complexity indicator list.

Indicator Number	General and Separational Indicators
1	Planning route/coordination
2	Initial call
3	Screening of traffic
4	Transfer of communication for departures and overflights
5	Clear for approach and transfer of communication
6	Separation of aircraft in approach sequence on FAF
7	Separation of arrivals on route
8	Separation of arrivals from departures
9	Separation of arrivals from overflights
10	Separation of departures
11	Separation of departures and overflights
12	Separation of overflights

.

A total of 12 complexity indicators is given. Each indicator is categorized depending on the type of traffic, conflict, wake turbulence category or other important parameters. Parameters of complexity indicators give insight into their main features. Indicators 7–12 additionally have different preconditions to be satisfied in order to activate the complexity indicator.

The algorithm calculates indicator parameters and categorizes them. Due to parameters structure, it is easy to change categorization and its values if needed. For example, if aircraft trajectories are not precise, the minimum distance for conflict detection can be expanded from five to seven nautical miles. Since the algorithm is extensive, only the calculation of the parameter available maneuvering area, which requires a more complex calculation will be explained. Other parametric calculations are considered to be more or less easily understandable, with details of complexity indicators given in Ref. [5]. The pseudo code for the calculation of that parameter is given in Algorithm 1 with the additional explanation of code segments.

Algorithm 1: Calculation of available maneuvering area complexity indicator

Input: List of aircraft in situation A

Output: List of available maneuvering areas M

1:    Initialize M ← ∅

2:    For each aircraft in A do

3:          other_aircraft ← A without aircraft

4:          time_sectors ← calculate_potential_trajectories(aircraft)

5:          trajectories ← load_other_trajectories(other_aircraft)

6:          conflicts ← calculate_potential_conflicts(time_sectors, trajectories)

7:          available_manouvering_area ← calculate_available_manouvering_area(conflicts)

8:    End For

9:    Return available_manouvering_area.

Results of calculations on lines 4, 5, 6, 7 from the attached pseudocode correspond to visually presented subfigures (a), (b), (c), (d) in Figure 8, respectively. Flight EWG532 from the traffic situation in Figure 4 is taken as an example. The value of the available maneuvering area calculated by the algorithm is 61%.

4.2. Algorithm Output

The algorithm automatically outputs parameter values and categories from Ref. [5] for each air traffic situation. Separate values for each aircraft are given for indicators 1, 2, 4 and 5, and values of aircraft pair for indicators and parameters 6–12. A set of complexity indicators with parameters from the traffic situation in Figure 4 is given as an example of algorithm output:

2.1 Initial call for arrivals: WZZ543, SAS776

3 1st option: Screening of traffic: 36

3 2nd option: Screening of traffic: A-A: 10, D-D: 0, O-O: 3, A-O: 15, A-D: 5, D-O: 3

6 Separation of aircraft in approach sequence:

       AUA499-WZZ543: 6-1-b, 6-2-a, 6-3-b, 6-4-a, 6-5-b, 6-5-c

       WZZ543-MGX765: 6-1-a, 6-2-a, 6-3-b, 6-4-a, 6-5-c, 6-5-c

       WZZ543-EWG532: 6-1-a, 6-2-b, 6-3-b, 6-4-c, 6-5-c, 6-5-b

       MGX765-SAS776: 6-1-b, 6-2-b, 6-3-b, 6-4-a, 6-5-c, 6-5-b

       EWG532-SAS776: 6-1-b, 6-2-b, 6-3-b, 6-4-c, 6-5-b, 6-5-b

7 Separation of arrivals on route:

       AUA499-EWG532: 7-1-b, 7-2-a, 7-3-a, 7-4-b, 7-4-b

       AUA499-MGX765: 7-1-b, 7-2-c, 7-3-a, 7-4-b, 7-4-c

       WZZ543-SAS776: 7-1-b, 7-2-c, 7-3-b, 7-4-c, 7-4-b

       EWG532-MGX765: 7-1-b, 7-2-c, 7-3-a, 7-4-b, 7-4-c

9 Separation of arrivals from overflights:

       AUA499-DLH654: 9-1-a, 9-2-a, 9-3-b,9-3-a

       WZZ543-SCW976: 9-1-b, 9-2-b, 9-3-c, 9-3-b

       SAS776-EJU521: 9-1-a, 9-2-b, 9-3-b, 9-3-a.

Complexity indicators for static air traffic situation in Figure 4 indicate that the traffic situation has:

• two arriving aircraft which require an initial call (2.1).
• Total number of aircraft pairs for screening of conflict is 36 (3 1st option), where aircraft that are only arrivals have ten pairs, only overflights three pairs, combination of arrivals and overflights five pairs, combination of arrivals and departures five pairs and departures and overflights three pairs (3 2nd option).
• Tasks of separating five aircraft pairs in approach sequence on FAF where AUA499-WZZ543 is described for each parameter:

  (a)

  difference until time to FAF is 2–5 min (6-1-b),

  (b)

  aircraft are in conflict (6-2-a),

  (c)

  first aircraft to FAF has five or more minutes to reach FAF (6-3-b),

  (d)

  second aircraft to FAF is in the same wake turbulence category (WTC) as the first one (6-4-a),

  (e)

  one aircraft has 30–65% of maximum available maneuvering area (6-5-b) while the other has 65–100% (6-5-c).

• Tasks of separating four arrival pairs on route, where AUA499-EWG532 is described for each parameter:

  (a)

  time until the closest point of conflict is the same or more than five minutes (7-1-b),

  (b)

  second aircraft to conflict point is the same WTC as the first one (7-2-a)

  (c)

  aircraft are in conflict (7-3-a),

  (d)

  both aircraft have 30–65% of maximum available maneuvering area (7-4-b, 7-4-b).

• Task of separating three pairs of arrivals and overflights where AUA499-DLH654 is described for each parameter:

  (a)

  aircraft are in conflict (9-1-a),

  (b)

  time until the closest point of conflict is less than five minutes (9-2-a),

  (c)

  one aircraft has 0–30% of maximum available maneuvering area (9-3-a) while other has 30–65% (9-3-b).

From the given complexity indicators for traffic situation in Figure 4, it is possible to analyze the air traffic situation from a complexity perspective. When observing complexity indicators for each aircraft, only the second indicator for arrivals, i.e., the initial call, is counted, which can also be observed from the situation image. Even though indicator 3’s 1st option indicates screening of 36 aircraft pairs, only 12 of them are counted as conflicts that should be monitored or solved. The other pair should have no influence on the overall complexity. An additional ten air traffic situations with their algorithm results are given in Appendix A.

4.3. Algorithm Validation

The validation is made in order to verify and confirm the correctness of the algorithm. During the algorithm development, each step, where a calculated output and a visual representation were possible, was checked and the results were compared with the entry data from the traffic situation. This ensures that the final results of the indicators are correct. However, since this is not sufficient, other independent validation is needed. The only possible validation outside the framework is manual. Manual validation requires the extraction of complexity indicators by manually calculating complexity parameters using available data from air traffic situations and trajectories. Results from the trajectory generation model are considered to be correct; nevertheless, each of them is visually compared to the aircraft position and route from the air traffic situation.

The algorithm validation is actually a comparison of the algorithm results with manually calculated complexity indicators for the same air traffic situation. Manual calculation of complexity indicators is an extensive process. Complexity indicators can be divided by their scope to ease the process: 1, 2, 4 and 5 observe aircraft separately, complexity indicator 3 counts all aircraft, and 6–12 observe aircraft pairs.

Complexity indictors 1, 2, 4 and 5 require calculation of time, distance, angle and speed, where speed is an information given in the aircraft label. The ruler that corresponds to distance in nautical miles in the air traffic situations is used to calculate time by dividing distance by speed. Only aircraft that correspond to the required complexity parameters are counted.

For the calculation of indicator 3 (1st and 2nd option), numbers of aircraft pairs depending on the type of flight (arrival, departure and overflight) are included in the formulas defined in Ref. [5]. The validation of the third indicator is straightforward, as the manual results from the formula are compared to results from the algorithm.

Complexity indicators 6–12 have more parameters and categories in which aircraft pairs should be divided. First, it is important to determine which aircraft pairs are or could be in conflict. Only such aircraft pairs are observed further. Some categorizations, such as determining conflict or potential conflict (using actual, cleared and exit flight level) and comparison of WTC are made with data from aircraft labels. Other categorizations that require aircraft trajectories use data from the trajectory generation model with the visual marking of an aircraft every 30 s. This enables easier calculation of conflict points, time until conflict and maximum available maneuvering area.

Extensive manual validation is made for 10 different air traffic situations presented in Appendix A. The outputs of the algorithm and the manual calculation are 100% in agreement. This is expected as the algorithm is made carefully, constantly checked and revised during its development.

5. Conclusions and Future Research

In this paper, we present the methodological framework for the generation of static air traffic situations and automated complexity data extraction. It consists of three main parts: SATSI, an algorithm for parsing trajectory prediction model input data and an algorithm for the extraction of terminal air traffic complexity indicators.

SATSI is a newly developed interface developed to create static air traffic situations in terminal airspace. Development of en-route airspace and traffic is also possible. SATSI enables fast and easy creation of air traffic situations that can be used in complexity research as well as in ATCO theoretical training, in airspace analysis, for development of scenarios with different difficulty levels, analysis of aircraft interaction, planning routes and other. Even though its possibilities are presented within this framework, SATSI can be used independently.

The validated algorithm for the extraction of terminal air traffic complexity indicators uses SATSI data, airspace data and trajectories created by an existing trajectory prediction model. Its output is a list of General and Separational complexity indicators for each air traffic situation. The algorithm enables easy change in parameters and category values which can be used in complexity research, development of complexity models and for other experiments related to ATCO tasks. The proposed framework avoids time-consuming procedures for air traffic scenario preparation and enables easy acquisition of complexity indicator data.

This methodological framework can serve as a base for developing a terminal air traffic complexity model and that is the primary aim of our future research. The next step will include an experiment with approaching ATCOs in which each of them will grade static air traffic situations with complexity values on a scale of one to five. These values and values from the algorithm for the extraction of terminal air traffic complexity indicators will be used as target and exploratory variables for model development. Finally, the complexity model will be validated for another terminal airspace to observe how it operates in unseen airspace and traffic situations. Another future direction of research is to expand the performance base to BADA 4 in the trajectory generation model to obtain more accurate aircraft trajectories.