heronyang / airport-simulation

Airport Surface Simulator and Evaluation Tool 2

ASSET2 - Airport Surface Simulator and Evaluation Tool 2

About

ASSET2 is a generic airport simulation tool for research purpose. It is designed to support multiple airports, to test and to evaluate customized schedulers. Please check out our paper for more information.

This tool is built for Carnegie Mellon University MSIT Practicum Project and Master Independent Study sponsored by the NASA Ames Research Center.

How to Run

Please note that the code runs in Python 3.

Please avoid Python>=3.7.0 because it breaks the legacy Cython, which one of the dependencies line-profiler depends on. The issue has not been fixed at the moment. Try to install a lower version instead.

Prepare Airport Data

Place airport related data under data folder like data/sfo-terminal-2/build/ (use IATA airport code).

First-Time Installation

If you're on Ubuntu:

$ sudo apt-get update
$ sudo apt-get install -y python3-pip
$ mkdir -p ~/.config/matplotlib/
$ echo "backend : Agg" >> ~/.config/matplotlib/matplotlibrc

Set-up Virtual Environment (highly recommended):

• If you are using IntelliJ or any other JetBrain IDE, see this link (recommended).

• If you are using commend line:

  $ {path/to/python3} -m venv venv # create a new virtual environment
  $ source venv/bin/activate # activate the virtual environment
  $ pip install -r requirements.txt # install dependencies locally
  $ python simulator.py -f plans/base.yaml # execute the simulation

Install dependencies:

$ pip install -r requirements.txt

Run

$ python simulator.py -f plans/base.yaml
$ python simulator.py -f batch_plans/simple-uc.yaml # Batch Run

Visualization

$ python visualization/server.py

Tests

$ python -m unittest discover tests    # all tests
$ python -m unittest tests/test_scheduler.py   # single test

Check Style

$ pycodestyle --show-pep8 --show-source --exclude=venv .
$ ls -1 *py scheduler/*py | xargs pylint # optional but recommended

Documentation

$ pydoc <python-file-name-without-.py>

Developer Guidelines

Sequential Diagram

Experiment Flow

The following steps are suggested for lauching an successful experiment systematically.

1. Compose and launch a single plan to find out (a) the upper bound of the value of the experimental variable and (b) the execution time for a single run.

   $ time ./simulator.py -f plans/<upper-bound-to-try>.yaml
   

2. Use the visualization tool on the single plans you launched in step one to see if things are working as expected. For example, you should check if the aircrafts are busy enough in order to retrieve a meaningful plot.

    $ ./visualiztion/server.py
   

3. By using the execution time and upper bound information we collected from the previous steps we can then lanuch a batch run with try_until_success: False. The execution time of this batch run should be able to estimated.

4. By using the execution time and failure rate information from the previous steps, we can then launch a batch run with try_until_success: True to obtain meaningful final results.

Style

Please ALWAYS follow PEP 8 -- Style Guide for Python Code for readability and consistency.

Logging

Default logging level is set in simulation.py, and please initialize logging for each class in __init__ like this way:

self.logger = logging.getLogger(__name__)

Debug

Put breakpoint in this way:

import pdb; pdb.set_trace()

Also, please refer to our Google Map for debugging the details.

Units

For consistency, following units are used everywhere in the code:

Time: second
Length: ft

Cache

Routing table calculated by the routing expert will be cached at cache/ so please make sure all the objects in routing table can be dumped into binary file using pickle. Ex. logger can't be dumped.

Note that cache may cause errors or bugs in many cases because stale data is used.

Clock

Simulation time (sim_time) indicates the time should be passed in each tick() and it can be accessed globally in any place by using following syntax:

from clock import Clock
self.logger.debug("sim time is %s", Clock.sim_time)

Profile

To speedup the simulation, we can apply some profiling technique to locate the slow code. Add @profile decorator at the beginning of the function you want to profile, then do following commands to obtain a report of the execution time of each line within the function.

$ kernprof -l ./simulator -f <your_plan>.yaml
$ python3 -m line_profiler simulator.py.lprof

airport-simulation's Issues

Actions not Working

Arrival flights not visible.

"GET /data/streaming?plan=sfo-terminal-2&steps=1&id=-1 HTTP/1.1" 400

Speed up the execution time

Problem

Currently, a single simulation on 9 hours scenario data, for sfo-terminal-2, and rescheduling on each tick takes around 2 to 3 minutes. It's too slow for us to run lots of batch tests.

Solution

1. Use the profiling technique described in the README to find out the slow parts of the code, and optimize it.
2. Use multiple thread technique for the batch runs since there's no shared data between two simulation runs. (The surface/scenario data may be shared, but it's not hard to avoid that).
3. Replace the slow code with c++ or c code. Or, pypy.

Note

pypy doesn't support numpy/pandas plots at this point. We will need to figure a way to avoid this if we're optimizing the code with pypy.

Adds pilot delay

Problem

Currently, conflicts created by the uncertainty module in the simulation is not preventable if the scheduler doesn't reschedule every tick. Instead, these kinds of conflicts lead to an early termination to reflect the real world: "if there's a crash in the airport, there's no way the airport will continue to function properly."

Solution

Therefore, we need a pilot behavior design in our simulation logic. The pilots should add a delay on its own aircraft is it found out the target node is occupied by another aircraft.

Code

We should add:

1. Checks if another aircraft "is_close_to" the next target at aircraft.tick().
2. If yes, inject a delay on this aircraft
3. Adds another list in the itinerary for "pilot_delay" which should be similar to scheduler_delay and uncertainty_delay.
4. Updates the state_logger, analyst and reporter objects for logging the results.

Note

The hardest part of this feature should be finding out a good way to move multiple aircrafts at the same time. Note that the simulation is actually sequential so the moves may or may not affect other aircrafts.

Adds more complex airport surface data

Problem

Currently, we have two airports that work: simple and sfo-terminal-2. simple data contains 3 gates and 1 runways and sfo-terminal-2 contains the gates in terminal 2 and 1 runways. These objects may not be enough for providing a hard enough problem for the scheduler.

Solution

Create a new airport data under data following the same structure as sfo-terminal-2. However, we pull out more data (for example, more terminals) from data/sfo and to make it work with the simulation.

How to work with real flight data ?