~/work/air-traffic-controller-training-system.md
Case study

Air traffic controller training system

A centralized system that connects trainee air traffic controllers, instructors, and feeders in a real-time simulated exercise — one frontend codebase packaged for iPad and Windows 10, with an admin scenario editor instructors use to prepare and reuse games without developer help.

role
Lead engineer · client + designer + frontend coordination
client
Croatia Control · national air-navigation services provider
sector
Aviation · controller training · real-time simulation
stack
Django · DRF · EventSource · Docker · Cordova (iOS) · Electron (Windows 10) · MariaDB
surface
Admin scenario editor · trainee & instructor apps on iPad and Windows 10 · browser-based config
status
● in production
01 / Problem

Training the role, not the airspace

Air traffic controller trainees can't learn their job by commanding real aircraft. They learn by rehearsal — instructors stage live-looking traffic situations, trainees respond in real time, and the exercise replays the stress of the job without leaving the training room. The system had to run on hardware the institution already owned, keep multiple trainees and instructors inside the same running exercise, and let instructors prepare and reuse scenarios without calling a developer for every change.

02 / Architecture

One server, one frontend, three packagings

diagram · cross-platform deliveryserver · shared frontend · iOS · Windows · browser
server Django · MariaDB Docker shared frontend one codebase HTML · ES6 · Sass iOS · Cordova iPad trainee & instructor Windows 10 · Electron desktop trainee browser instructor config REST EventSource
single Django server and a single frontend codebase · packaged for iPad (Cordova) and Windows 10 (Electron), plus a plain browser for instructor configuration · REST for request/response, EventSource for the server → client push half

The server is a single Django app holding games, roles, sectors, and playthroughs. The frontend is one codebase shared across three packagings: iOS via Cordova for iPads in the classroom, Windows 10 via Electron for student workstations, and a plain browser for instructor configuration. REST handles request/response; EventSource handles the push half, so trainee UIs update the moment an instructor fires the next event.

One frontend codebase, three packagings. Shipping to a new platform is a packaging change, not a rewrite.
03 / Admin

Instructors compose games; developers don't

Games aren't hard-coded. The Django admin is the scenario editor — instructors compose a game from roles, sector positions, message tabs, and content files (PDF maps and lists). Once composed, a game can be replayed as a fresh playthrough, so the same scenario runs across many training sessions with clean state each time. Filter chips on pick-list popups auto-scope options to the current role and sector, so the editor stays usable as the catalog grows.

04 / In exercise

Same UX, iPad and Windows 10

Trainees pick a game, join a role, and the exercise begins. The in-exercise UI is identical across packagings: compact action buttons for pre-formatted radio messages (TEXT, HDG, SPEED, FL/ALT, DCT), a receiving panel that updates as events arrive, a log of everything said, and a map-annotation canvas for free-hand drawing over pre-uploaded PDFs. Instructors and trainees annotate over the same visual material in real time, which is most of the point.

Recording of an exercise in progress — instructor firing events, trainee responding on the iPad
05 / Tech stack

Tools

  • Django
  • django-rest-framework (REST API)
  • EventSource (server → client push)
  • Docker (deployment; Raspberry Pi demo server)
  • Cordova (iOS packaging)
  • ElectronJS (Windows 10 packaging)
  • HTML · ES6 · Sass (shared frontend)
  • MariaDB
~/work
01 / 01 navigate · Esc close