Introduction
Airports are critical infrastructure that facilitates 2.9 million passengers per day. This industry is a high-risk high-reward industry. Airlines will gamble on which flights they think will be popular in the future, and locate their hubs strategically. At the airport scale, Air Traffic Control (ATC) operators must ensure traffic flows efficiently, and safely. According to research done in 2022 reported by airlines.org, the cost of delays cost $101 per passenger per minute. In total, delays cost an estimated $28 billion in 2022.
There are many macro factors that contribute to profitability flights. Predicting Two-way demanding of flights is another difficult problem in this industry. For example, there is a lot of demand for flights from China to Australia but not from Australia to China. Also, airlines make disproportionate profits on higher-class seats in any given airport.
This project was to design an airport analysis tool to help model airport processes. The goal of this project would be to provide tools for ATC operators and schedulers to visualize flight schedules and how the sequencing might look in real time. Unity was my choice of engine for this project. I was a novice going into this project, with no experience in game development, game engines, C#, or Unity. Unity has been a popular choice with simulation engines for many large corporations such as Northrop Grumman.
Motion Scripts
The airplanes traverse the simulation scene as state machines. Three main scripts govern all of the plane’s motion: Taxi to Terminal, Taxi to Runway, and Takeoff. Taxi to Terminal is the first script executed in the sequence because it also defines the plane’s landing state. This script lands the plane, turns onto the taxi path and apron, and then navigates to it’s assigned terminal. This is conducted through a series of checkpoint systems, that allow for the plane’s state to be updated when it’s achieved certain checkpoints. This is a common theme across all of the motions scripts.
Flight Sequencing / Process Tracking
Organization of which planes are in what states is required to achieve smooth traffic throughout the airport. A priority queue is leveraged to drive the logic of determining which planes should be taking off and landing. This priority queue serves as the sequencing of the flights in the airport. This is exposed in the GUI at the top of the simulation’s view. Outbound planes receive priority in the queue. A series of process lists keep track of which plane is in what state. This ensures that every plane in the situation will be organized into what state they are in, and what movement needs to be processed according to that state. This is performed by iterating through each element of every process list in reverse, allowing for the easy removal of planes that have flagged they are no longer in the state that corresponds with it’s list and need to be moved to another state. An example of this would be after the plane lands and approaches the terminal and completes the unboarding/boarding process, the main simulation controller switches the state of that plane from ‘Taxi to Terminal’ to ‘Taxi to Runway’.
CSV Importer
This simulation leverages a CSV importer and parser that defines the schedule of the simulation. It parses lines of a csv to this struct:
In this object, TimeIn represents the integer time in which the plane will land. This will be displayed in the format: HH:mm:ss. The simulation time is designed to begin at 08:00:00 by default, so the lower bound of the generated csv values for both TimeIn and TimeOut is 8 * 3600. After the values are parsed to this object and collected, it is passed to the Schedule to manage.
Schedule
The Schedule is the grid view that appears on the left side of the simulation views. In a 1920 x 1080 resolution environment, the simulation will draw 40 rows of flights initially. The main Simulation Controller will send updates to the Schedule that communicates when it needs to remove a row because the plane has been fully processed, and when the Simulation is done processing. It is important to note that if a plane is delayed from landing, it does not cut into the overall delay time initially defined in the difference between the TimeIn/TimeOut values of the imported schedule.
Plane Labels
Labeling the planes in the simulation view uses a clever trick in Unity. Each plane label is associated the plane prefab itself. Every time a plane instantiated, the simulation will create a child GUI game object that contains a reference to the position in which the text should be displayed. Next, draw a label on the 2-dimension HUD that tracks that location above the plane’s cockpit in 3d space. This gives the effect that the labels are following the plane in 3d space, but is actually a 2d object. This technique implements this feature well due to the alternative of drawing the labels in 3d space and having to constantly rotate the labels to be visible to the currently active camera.
Time scales / Simulation Time
The most difficult challenge of this project was implementing Simulation time controls/scales. Two crucial Unity concepts need to be introduced to discuss this topic: time and delta time. Time is a floating point representation of how many seconds have passed in Unity. One common issue in Unity for developers is that single-precision float time in seconds starts to lose millisecond accuracy after about 9 hours. Luckily, this simulation only requires precision up to seconds. Unity delta time is the interval in seconds from the last frame to the current one. Multiplying our speed values by delta time when calculating the new position to draw the plane in the next frame allows for smooth continuous motion, acceleration, or deceleration. Ensuring that the plane’s motions scripts are robust enough to smoothly run on less frames and higher delta time values proved to be a challenge.
