Stand Alone ATC Control Development

From FlightGear wiki
Jump to: navigation, search
IMPORTANT: Some, and possibly most, of the features/ideas discussed here are likely to be affected, and possibly even deprecated, by the ongoing work on providing a property tree-based 2D drawing API accessible from Nasal using the new Canvas system available since FlightGear 2.80 (08/2012). Please see: Canvas Maps for further information

You are advised not to start working on anything directly related to this without first discussing/coordinating your ideas with other FlightGear contributors using the FlightGear developers mailing list or the Canvas forum. Anything related to Canvas Core Development should be discussed first of all with TheTom and Zakalawe. Nasal-space frameworks are being maintained by Philosopher and Hooray currently. talk page..

Update (12/2012)

See OpenRadar.

Old discussion from 2010

Last updated: Dec. 2010

Status: Discussion

This wiki is created upon the fired up debate and forum talks to create a centralized idea-bank, so the development proposals/goals can clearly be identified. All users are welcomed to contribute to this entry with their real or virtual world experience and simulator environment requirements for a stand alone virtual ATC GUI client for FlightGear Multiplayer Network (TRACON and ARTCC).

To learn more about a virtual ATC radar client, please see:


Today there are 3 types of ATC-applications known, to which we may try to position the new development:

Todays Real Life ATC

This is the paragon of all ATC-simulation:

  • operated by highly educated and paid professionals
  • ATC must be able to handle 100 targets an hour
  • customers are Pilots with valid Pilot-licenses, approved by government authorities
  • is highly specialized for unique jobs, like Center, APR, TWR, GND, Planning
  • unique positions at big airports may be executed in parallel by multiple ATC,s (i.e. one Airport, several TWR- and several APR- and several GND-ATCs)
  • strictly Radio communication – NO MPchat type of typing!! (some use of light-signals for emergency operation)


  • comes real close to the “Life ATC”
  • world-wide, very organized structure
  • uses own, well trained, and certified hobby-ATC's
    • specialized on providing ATC-Services and Pilot-Training to any user of any Flight-Simulator
    • does not have an own Flight-simulator
  • uses only black-radar screens (but suggests to use additional Map-overview screens)
  • uses different Radar-images per ATC-function (CTR, APR, TWR, GND)
  • communication is based on a very useful, complex Radio-operation via a complex switchboard
  • can also use predefined text-messages per number-code-selection (difficult to memorize)
  • uses own central Servers to control who may do what
    • supports only such pilots, that are “flying controlled according to VATSIM-rules ”
    • requires Flight-Plan from each user - has an extra "Clearance Delivery"
  • performs regular quality-checks on its ATC's
  • requires from ATC national language support (according to country)
  • the ATC must be certified for each unique airport and function he wants to work at

Todays FGFS-ATC-models

  • used for APR, TWR, GND (i.e. not for Center and Clearance delivery and flight-planning)
  • several ATC-models used by anybody, independent of age, skill, for fun or serious, etc. - thus no committed "quality of service"
    • may raise the amount of ATC's starting to learn
    • but also may discourage potential customers!
  • there is no possibility to enforce any code of conduct and/or skills, neither for pilots nor for ATC
  • is mostly used by casual "just passing by pilots" or preplanned MP-events (e.g. TGA or Virtual-Airlines)
  • does not require nor can handle flight-plans
  • Acceptability/Usage by pilots still very poor (based on amount of all MP-users)
  • needs "low skill borders" to achieve increased acceptability

Proposed Positioning for FGFS-ATC

  • make FGFS-ATC to a very popular ATC-tool also for beginners
  • do not try to compete with VATSIM, we do not have and will never have enough trained ATCs nor enough trained and/or willing pilots
  • keep FGFS and FGFS-ATC open for all: From "Kids-Stuff" over "Flying just for fun" up to "highly professional training"
    • fitting the different capabilities/skills of our potential customers and models
    • offer them opportunities to develop "controlled flying skills" in stages:
      • learn to watch/control altitude, heading, speed, etc. by advise and supervising
      • learn to plan flights (e.g. not to arrive at 20.000 ft over the destination-airport)
      • communication with ATC (in English!)
  • enable use of VATSIM for "totally planed and controlled flights"

Minimum set of required features

  • multiplayer support
  • display a radar-like screen
  • display data tags (altitude, callsign, course, sqwk code etc)

Features to be provided by the future Full-Screen FGFS-ATC

The following "wanted features" may become prioritized together with the designers, based on available resources:

The Radar

  • must show the target and navigation data in an easy and quick to read fashion (e.g.: colored labels on Black)
  • must show the terrain (water, land, hills, mountains) in color (like e.g. MPmap or ATLAS). The terrain does not need to be very detailed but should indicate when ground-altitude raises above pattern altitude

It may be difficult to find a “perfect match” of above 2 items, so we need a button to switch between different backgrounds: “Simple Black” or “scenery ” and the targets and navigation-labels must be on an extra layer – thus they remain the same on both backgrounds.

  • Target-Labels MUST NOT just use black boxes underlying the text (as e.g. in MPmap) - that gets very unreadable when many labels (target and/or navigation) overlay each other.
  • The Radar range must be (at least) 100 mi (like MPmap and FGCOM) and easily zoomed
  • even on a Full-Screen application there must be a centered compass-scale in the background


  • on Radar must be shown
    • Call-sign, altitude, speed, model
    • Selecting a target out of the scope should be possible – but first priority would be the next item:
  • on an additional GUI-list must be listed all targets, including: (compare now ATC-ML)
    • call-sign of target
    • distance from airport
    • altitude of target
    • speed (may be selectable between TAS and IAS – otherwise pilots get blamed if ATC advises a speed that is shown different to pilot and ATC)
    • heading of target
    • Model
    • planned destination: An empty field for ATC to insert either: direction (N,E,S,W), SID/STAR, Pattern, ICAO, or similar)
    • flying-modus: May be a pull-down to select: IFR, VFR, SID/STAR, Uncontrolled
the last two items acting as a very minimized flight/handling-plan for ATC purposes
  • that list must display all targets inside todays MPchat/FGCOM reach: 100 mi – independent of RADAR zoom settings!
  • the listing should be sortable by distance (e.g. nearest has highest priority during APR) and call-sign (e.g. for easy finding)
  • that GUI-list should be able to be moved outside the Scope – better even onto anther screen or even PC
  • ATC must be able to mark the lines according to who controls: CTR, APR, TWR, GND, not yet assigned, control rejected (either by pilot or ATC), especial needed if several ATC's work together (e.g. APT and TWR)
    • do not delete unwanted targets from list – otherwise ATC might search and search for targets that call in and are visible for others – but are not on ATC-Radar
    • on the reverse provide a possibility to address a plane not shown in the ATC-MPserver (e.g. todays problem with overloaded MPserver02)
  • All that added data should be buffered to be recalled in case the Target jumps in/out of Radar-List (may be pilot uses “p” (pause), MP-delays, restart because of crash (ATC or target), etc)

Navigation aids

on radar must be shown the type, ID, frequency (similar to MPmap – but again not with labels inside black boxes)

  • if all of them are displayed all the time – we might not be able to see any more what we want to see → that is one reason why VATSIM uses different images for their radar! Try VATSAM-radar on image “Tower” and zoom out (e.g. "Central") – and try to pick any Fixpoint!
  • So ATC needs to define which ones he/she needs for the planned job and only place those onto the scope. That could be done in 2 ways:
    1. either by manually typing in the NAV-IDs one by one that ATC wants/needs (similar like in todays MPmap)
    2. or show all available ID's (on scope or GUI) and let ATC select the ones to be removed
#2 being faster and easer to use by ATC and thus preferred
  • The Nav-points must not be selected at each startup again and again - but may be saved by ATC for different jobs and or different locations under different conditions (e.g. approaches for wind from west or east, etc.)
    • Airways do not need to be shown because they are usually not controlled by FGFS-ATC – they should remain the pilots-responsibility.
  • All settings should be saved in a file to be called up on request. It can be a real pain if the ATC-PC crashes and after reboot the ATC has to remember and reconfigure certain settings under stress. Those settings are also very nice for e.g. ATC "jumping to different airports" in between. e.g. during MP events – he then could just very fast load different “settings”! We should try to reduce the amount of ATC's needed and rather have more pilots participating and thus giving the ATC something to do!


  • 2 FGCOM frequencies are needed:
    • 1 fully active according to ATC-function
    • 1 just for monitoring another frequency (maybe TWR listening also to GND, etc.) - but without activated Microphone (to avoid mishaps under stress!)
those two must be exchangeable by one mouse-click (e.g. to tell the other something or just help out on another Twr, etc.)
  • Off course MPchat is needed – it should be an extra GUI located somewhere
  • Have command-selection for non FGCOM users similar to ATC-ML
    • but not numbers to select (as e.g. in VATSIM) but Mouse-click onto understandable abbreviations (as in ATC-ML)
    • those should be organized into several columns according to ATC-functions on an outside GUI (we need more then now used in ATC-ML)
    • these commands should be in an extra Text-File for easy change and translation
    • It should be selectable which languages to display the message in – but alwas force at least also the English one for training those sentences for all. It seems that displaying up to 3 languages is possible without endangering the whole operation. (Right now we display English always first.


  • we also need a direct FGFS-view to Targets.
    • for analyzing/teaching/control
    • pile-ups on "Ground" (e.g. is runway clear)
    • "short finals evaluation" (how steady is descent)
    • "landings" (centerline, bounces, etc)
  • If switching from Radar to FGFS-Picture (as in todays FGFS-ATC-models) is not possible, provide a link to control a parallel FGFS-session with the RADAR data (e.g. auto-zoom onto landing aircraft) . (Similar as exists today fur FGFS Dual-PC's and/or Sceens)

Other features and ideas

Standard features commonly provided by VATSIM and IVAO clients

End user feature requests

Customizing Atlas for use as an ATC client

In the scope of the ongoing ATC discussion, we have also talked about extending Atlas (a moving map utility) to use it as the foundation for a standalone ATC client, concentrating on a maximum degree of code reuse, where we would only need to customize atlas for ATC use. This is a fairly old idea, which has already been suggested 5 years ago: [].

It seems, that most of the existing atlas features could be used for ATC purposes, too. While only very few new features would be needed that would require changes to the C++ source code. This would make it possible to generalize the atlas code some more, so that using Atlas for ATC purposes would merely be a different "mode" of running atlas.

For the time being, the most important new feature for atlas would be multiplayer support, which would require support for decoding FlightGear's Multiplayer messages, which are XDR encoded packets. The corresponding C++ code is readily available in the fgms source code and could be reused.

Dealing with XDR encoded packets is something that has proved difficult for a number of similar efforts, so the possibility to directly reuse the fgms code seems promising.

Most of the other changes required in atlas would be about making certain atlas features either more configurable (i.e. moving hard coded defaults out of the C++ source code into configuration files, plain text or XML based), or about providing an option to completely disable other features.

Required enhancements (new features)

  • multiplayer support (i.e. processing XDR encoded FG MP messages)
  • possibility to customize appearance for typical ATC use
    • different default color palette
    • radar screen (range rings)

GUI related changes


  • P1 - essential feature
  • P2 - very useful feature
  • P3 - optional feature
  • P4 - experimental feature

Open questions

  • should atlas connect to fgms as a server (relay?) or a client (observer), or should it just poll fgms for updates?
  • how about using texture packs to make atlas symbols more customizable?
  • can atlas also render detailed airport overviews (taxiways), the corresponding code is available in taxidraw and fgsd if needed, and also the fgfs ground radar instrument
  • how about reusing data that is already sent to FlightGear (that would require a running FlightGear instance)
  • Drag and drop label (data strip)

Atlas features that should eventually become more configurable

  • symbols used for navaids, airports and runways?


Milestone 0

  • enhanced support for tags/labels, to display information such as altitude, course, squawk code, callsign etc

Milestone 1

  • radar-like appearance

Milestone 2

  • multiplayer support (processing XDR messages from fgms)

Milestone 3

  • FGCom integration

Atlas features not required for ATC purposes

  • the terrain view should be probably be made optional?
  • Obstructions/tall antennae etc would be nice to appear on radar

Standalone (non GUI) automated ATC

Beginning of an idea Auto-ATC

A project has been started some years ago, named AutoATC. Indeed it is in a really alpha version, not usable at all.

Here are the great lines: the idea was/is to create an lightweight application which fakes its position on Multiplayer Network. This would allow the application to receive/send messages to others connected players, as well knowing their position/bearing/speed/xpdr.

The automated ATC would manage all airports in its area, should have defaults configuration for quite all airports, and can be configured for some specifics airports using XML.

The imagined protocol is this one:

  1. the player send a specific formated message over the multiplayer network (nasal or xml should format the message): it contains multiplayer's callsign and her/his intentions.
  2. the automated ATC grab the message, create an internal instance for this player and gives her/him a transponder code to use
  3. both communicate in a formatted protocol.

The appli was initially written in Perl. Each instance of a multiplayer was a hash table entry (using callsign/transponder couple for authentification), each runway of all managed airports should be hash instances containing the sorted list of users queriing on it. AutoATC could determine a way to enter the final approach of a runway, take care of other players queriing approach or departure, asking them for enter in a waiting-circuit, manage emergencies, etc.

In the case of multiplayer do not follow instructions for any reason for, say, 10 consecutives times, or just asks to leave the system, her/his instance and all her/his queries are wiped.

Why the project has stopped? Because I was unable to send a correctly formatted UDP packet: the position message is different from C++... this was until I discover swig (which is used on FGMap). Swig can be the solution to allow a revival of autoATC, which is next on my TODO list.

The ideal ATC client

An ideal ATC client should provide:

Graphics: radar-like appearance, so that distraction due to visual elements is kept minimal. With respect to that, it should be customisable what types of elements should be shown and hidden, or even show/hid subsets of those (by name, by altitude,...). This is due to personal preferences or position types (ground doesn't need fixes, or approach doesn't need taxiways). Amongst those elements (some are really optional):

  • Navaids
  • Fixes
  • Runways
  • Taxiways
  • Extended runway centerlines
  • Higher and lower air routes
  • Geographic elements: water, coastlines
  • Range rings
  • Aiplanes
    • Label
    • Speed vector
    • Recent path
    • Flight plan route
  • FIR/UIR boundaries; CTR/ATZ boundaries; etc.
  • Departure/Arrival standard procedures.

All this in a non-distracting way for the controller.

All those elements should be read from the FlightGear Scenery (except range rings), so that pilots and controllers share the same data. That will pose the need to add some elements to the FG scenery.

Voice: FGCom as external application is OK.

Chat messages to/from other pilots and controllers.

Flight plans will be the trickiest part. Not only should the ATC client have the ability to understand things like the route (to draw it on screen if needed; though this is quite optional at the beginning), but it will pose on Flightgear itself the need to support flight plans, with a standard form to be filled in by pilots prior to the flight; additionally, the MP protocol will have to implement it so that "flight plan packets" can be sent (by pilots) and received (by controllers). Additionally, as seen in other environments (optional at the beginning also), the controller should have the authority of correcting that FP, which would be sent back to the pilot with the modifications. This can apply either to aircraft under the control of the particular ATC, or to all the aircraft in scope.

I don't think the radar client should connect as a fake pilot. In my opinion, the MP protocol should be extended so that controllers could login as such.

Labels should keep the minimal information needed. That means that traffic under the ATC's control should display more info that traffic out of his control.


IvAc is the ATC client of the IVAO network. It has all those elements and many many more. This piece of software was developed mainly by Kenny Moens and Filip Jonckers, two guys from the IVAO Software Development department (of which I was member some time ago). Filip is a real-life Air Traffic Controller. I've emailed them asking if they would be willing to give a hand. No reply yet.

Atlas as a starting point?

The way I see it, the only thing that Atlas can offer is the code that reads the scenery files. Personally I don't see an ATC client coming from an Atlas fork, or a highly customisable Atlas. In the beginning it can make things easier, but in the long run, I personally think that the structure of one project is different from the other, with different objectives. However, pieces of source code might be reused from Atlas, of course.

There is another application in IVAO, called IvAe, which consists of a "Google Earthish" interface that shows all the pilots and controllers connected to the network, and you can retrieve much of their info (flight plans for pilots, ATIS for controllers, etc.). In this case, Atlas would be a good starting point for that.

Think big vs. think small

If an ATC client is developed with the idea that "Flightgear is not going to have heavy traffic any time soon...", a small client will be developed, probably not very extensible. If later on Flightgear becomes exponentially successful, then the client will need to be redeveloped from scratch, with a bigger structure. The other side of the coin is: if a big ATC client is developed and FG never reaches a big audience, perhaps all that work will have been in vain.

However, it's not necessary to build a huge client. It can be small, but with a structure that lets it grow in case that it's needed. In other words, make it extensible as a priority.

All that is needed for a virtual aviation network is: a pilot client, a radar client, MP server(s) with the proper MP protocol, a network infrastructure and a proper website. If that client is appealing enough, then anyone could create its own aviation network, as all the software needed is free software... The rules and regulations, the philosophy of the network, and so on, depend on the network creators, and not on the software used. One network can be "let's crash the planes"; another "more professional than professionals", etc. But if the radar client developed is for "kids only", then you leave those possible network creators with small choice.

A free software ATC client is the last piece of the puzzle so that new networks of the style of IVAO or VATSIM can be created using exclusively free software. Other kinds of accessory applications could be developed, like the IvAe or ServInfo-like programs.

So, I would say: think big. Just in case...



  • provides a stand-alone GUI application, not 3rd party dependencies (except for the JRE obviously)
  • written in Java
  • has abstraction to plug different frontends for being used with different/future data feeds and -formats


Web based simulators

Software:Open source

(list taken from atlas/fgms sourceforge trackers)