# BlueSky: an open air traffic simulator for research and teaching

> BlueSky models aircraft performance, a flight management system, an autopilot, conflict detection and separation assurance over open navaid, airport and performance data, and the project is explicit that it is a perpetual beta aimed at people who want to run experiments rather than operate a system.

**TUDelft-CNS-ATM/bluesky** — The open source air traffic simulator

- Repository: https://github.com/TUDelft-CNS-ATM/bluesky
- Stars: 574 · Forks: 322
- Language: Python
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/tudelft-cns-atm-bluesky

## A research tool, and the licence makes that explicit

BlueSky is meant as a tool to perform research on Air Traffic Management and Air Traffic Flows, and it is distributed under the MIT licence.

The stated goal is worth quoting in substance because it explains the project's priorities. It is to provide everybody who wants to visualise, analyse or simulate air traffic with a tool to do so without restrictions, licences or limitations, and it can be copied, modified or cited without limitation.

That is an unusually open position for a simulator in this field, and it follows from the provenance. The project comes out of the Delft University of Technology's CNS and ATM groups, and the citation the readme asks for is a 2016 paper by J. M. Hoekstra and J. Ellerbroek on the BlueSky ATC Simulator Project, presented at the seventh International Conference for Research on Air Transport. The framing is a research programme with a published method, not a product with a user base.

The consequence for an adopter is that the value is in what you can study and what you can change. The simulator is written in Python with the source available, the data is open, and the plugin mechanism means a new aircraft behaviour or a new conflict resolution rule can be added without forking the core.

The repository is hosted under the TUDelft-CNS-ATM organisation, the primary language is Python, the default branch is master, and the last push was on 2026-10-12.

## What is actually simulated

The feature list describes a fairly complete aircraft simulation stack rather than a simple kinematic mover.

The simulations include aircraft performance, a flight management system with LNAV and VNAV under construction, an autopilot, conflict detection and resolution, and airborne separation assurance systems. That combination is the point of the project, because conflict detection and resolution algorithms need realistic aircraft behaviour to be tested against, and a point mass on a straight line is not enough to produce meaningful conflicts.

The renderer choice is separate from the simulation core. The visualisation uses numpy with either pygame or Qt plus OpenGL, and the source is included, so the visual layer can be replaced. The packaging reflects that split with separate extras, one for pygame, one for the Qt6 stack with pyopengl, PyQt6, PyQt6-WebEngine and bluesky-guidata, one for the console interface through textual, a full extra combining all of them, and a headless extra with no additional dependencies for a server-only environment.

The top level of the repository shows the same structure in code. There is a BlueSky.py and a BlueSky_pygame.py entry point, a check.py, and directories for the bluesky package itself, extra modules, packaging, scenarios, utilities and documentation. There are also Windows batch launchers for running a scenario from the command line, running the client, and running headless, plus a setup-python.bat, which tells you that a good part of the user base is on Windows.

A TODO.md sits at the root, which is worth reading before you plan around a feature you assume is finished.

## Open data: navaids, airports, aircraft performance and BADA

The data story is what makes the simulator usable for research, and it comes in two layers.

The first layer is bundled. The project contains open source data on navaids, performance data of aircraft and geography, with global coverage of navaid and airport data. That coverage is what allows a scenario to be placed anywhere rather than in one invented airspace.

The second layer is interchange with the standards the field already uses. The simulator is compatible with BADA 3.x data for aircraft performance, and compatible with the NLR Traffic Manager TMX as used by NLR and NASA LaRC. The BADA compatibility matters because BADA is a recognised performance modelling standard, so a study can use it instead of the bundled data without rewriting the scenario.

The packaging makes the data dependency visible too. The runtime dependencies include scipy, matplotlib and pandas for the numerical and plotting work, msgpack for the compact serialisation the scenario and traffic formats use, zmq for the messaging layer that a distributed simulation needs, bluesky-navdata for the navigation database, and openap, which is an open implementation of the Aircraft Performance Model used in trajectory prediction.

So the data flow is: open navaid and airport data plus an aircraft performance model, fed into the flight management system and autopilot, producing trajectories that the conflict detection and resolution components evaluate. Each stage is replaceable, which is the property that makes it a research platform rather than a demonstration.

## Driving traffic from a console or from scenario files

How traffic enters the simulation is the part that decides what kind of experiment you can run.

Traffic is controlled through user inputs in a console window, or by playing scenario files with the .SCN extension that contain the same commands with a time stamp before each command, in a format written as HH:MM:SS.hh followed by the command. That means a scenario is a recorded sequence of inputs with precise timing, which is exactly what you need to reproduce a run.

The readme also notes that mouse clicks in the traffic window are used in the console for latitude, longitude, heading and position inputs, so an operator can pick a point on the moving map and have the coordinates typed into the console rather than typed by hand.

Two things follow from this design. The first is that a scripted run and an interactive run are the same mechanism, since a scenario file is a transcript of what a person would type. The second is that the console is a first class interface rather than an afterthought, which is why there is a textual extra in the packaging and why the headless mode exists at all.

For a research workflow, that means an experiment can be defined in a file, replayed identically, and its inputs inspected. It also means the project is a simulator with an operator interface, not a batch program, and the two deployment modes reflect that.

## Installing, the extras, and the container

BlueSky is available as a pip package with periodic releases, and the readme gives the installation command.

```bash
    pip install bluesky-simulator[full]
```

The full extra pulls in every visualisation and interface option, which is the right choice for a first install on a workstation. If you use ZSH, the readme notes that you need to add quotes around the package name, which is a shell parsing detail rather than a packaging one.

The packaging metadata shows the whole shape of the distribution, including the headless option for a server-only environment.

```toml
[project.optional-dependencies]
pygame = ["pygame"]
qt6 = [
    "pyopengl",
    "PyQt6",
    "PyQt6-WebEngine",
    "bluesky-guidata"
]
console = ["textual"]
```

And there is a container image, whose Dockerfile is short enough to read as a deployment description.

```dockerfile
FROM python:3.13-slim

# Update system packages to reduce vulnerabilities
RUN apt-get update && apt-get upgrade -y && apt-get clean && rm -rf /var/lib/apt/lists/*

# setup user and workdir
RUN addgroup runner && adduser --system --disabled-password --home /app --ingroup runner runner

# Expose output directory as a volume
RUN mkdir -p /data
VOLUME /data
```

The image runs as a non-root system user, exposes a data directory as a volume, and the entrypoint launches the simulator in detached mode with that workdir. The full Dockerfile also installs the package with pip, sets the working directory to the volume and points the entrypoint at the bluesky command with the detached and workdir arguments.

The project is also on PyPI under the name bluesky-simulator, and the console entry point is registered as bluesky. The wiki holds the installation and user guides, which the readme points to rather than duplicating.

## Where BlueSky is the wrong tool

Four limits, and the first is the one the project states about itself.

The contributions section says BlueSky can be considered a perpetual beta. That is a promise and a warning at once. It means the project intends to keep changing, and it means there is no stable release to pin a long study to, with the version tracked dynamically in the packaging metadata rather than declared.

The second is the scope of the physics. The readme notes that VNAV is under construction, and the project asks contributors to send proposals preferably after debugging and optimising for run-time performance, which is an honest admission that fidelity and speed are still being traded off. A study whose conclusions depend on precise vertical guidance is working with a component that is not finished.

The third is that this is a research environment, not an operational tool. It has a console and a traffic window, which is what an experiment needs, but the readme says nothing about an interface for supervising live traffic, and the project positions itself for visualisation, analysis and simulation rather than for operating anything.

The fourth is the platform split. The Docker image and the headless extra are the good news for deployment, and the Windows batch launchers are the good news for a Windows research group, but a simulation that depends on a desktop window and a particular rendering stack is harder to run in a batch cluster than a program with a clean command line.

## Licence, releases and the state of the project

The licence is MIT, declared in the packaging metadata with the licence file referenced, and it is the licence the project markets explicitly. That is a permissive grant with no copyleft obligation on derived work, and the readme invites copying, modification and citation. This is not legal advice, and a company shipping a derived product should still run its own review, particularly since the simulation includes bundled data whose own terms are separate.

The release history is steady and the version numbers tell you where the project is. Version 1.0.7 was published on 2025-06-17 as a bugfix release, 1.1.0 on 2025-09-19, and 1.1.1 on 2026-01-27. The classifiers mark the development status as Beta, and the intended audience as Science and Research, which is a machine readable statement of the same thing the perpetual beta note says in prose.

The dependency set is where a lot of the operational cost sits. numpy is pinned below 2.4.0, and the rest are pinned or floating: scipy, matplotlib, pandas, msgpack at 1.0.0 or later, zmq, the bluesky-navdata package, and openap. Those pins exist because the simulation depends on the numerical behaviour of those libraries, so an upgrade of numpy or scipy can change results, and a study that has to be reproduced needs those versions recorded.

For an adopter, the practical summary is that BlueSky is a well documented, permissively licensed research platform with an active maintainer, a containerised deployment and open data, and the two things to check before you rely on it are the unfinished state of the vertical navigation and the version pinning your results depend on.

## Conclusion

BlueSky is the right tool for a researcher, a lecturer or a student who needs to reproduce an air traffic scenario, study conflict detection behaviour, or experiment with a traffic flow management idea against open data, and it is the right tool for a simulation exercise that has to be inspectable rather than a black box. It is the wrong tool for operational traffic management, for a study that needs a certified aircraft performance model, and for a project that expects a finished product with a support commitment. Before adopting, read the wiki, since the readme points there for installation and user guides, check that the visualisation stack you want is in the extras you install, and plan for the fact that the project calls itself a perpetual beta.

## FAQ

### What is BlueSky?

It is an open source air traffic simulator for research on Air Traffic Management and Air Traffic Flows, written in Python and distributed under the MIT licence. It simulates aircraft performance, a flight management system with LNAV and VNAV under construction, an autopilot, conflict detection and resolution, and airborne separation assurance systems.

### How do I install BlueSky?

The pip package is installed with pip install bluesky-simulator[full], and using ZSH you need to quote the package name. The packaging also defines separate extras for pygame, the Qt6 stack, a textual console, a headless server-only environment with no extra dependencies, and a full install, with more instructions in the project wiki.

### What data does BlueSky ship with?

The project contains open source data on navaids, aircraft performance data and geography, with global coverage of navaid and airport data. It is also compatible with BADA 3.x performance data and with the NLR Traffic Manager TMX as used by NLR and NASA LaRC.

### How do you control traffic in a BlueSky scenario?

Through user inputs in a console window, or by playing scenario files with the .SCN extension that hold the same commands with a timestamp before each command in a HH:MM:SS.hh format. Mouse clicks in the traffic window are also used in the console for latitude, longitude, heading and position inputs.

### Is BlueSky production ready?

The project describes itself as a perpetual beta, the development status classifier is Beta, and the VNAV component is described as under construction. The release history is regular, with 1.0.7 in June 2025, 1.1.0 in September 2025 and 1.1.1 in January 2026, and the last push was on 2026-10-12.

## Sources

- [Issues](https://github.com/TUDelft-CNS-ATM/bluesky/issues)
- [License: MIT](https://github.com/TUDelft-CNS-ATM/bluesky/blob/master/LICENSE)
- [README](https://github.com/TUDelft-CNS-ATM/bluesky/blob/master/README.md)
- [Releases](https://github.com/TUDelft-CNS-ATM/bluesky/releases)
- [TUDelft-CNS-ATM/bluesky on GitHub](https://github.com/TUDelft-CNS-ATM/bluesky)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tudelft-cns-atm-bluesky