Air Traffic Control in the Browser

The National Airspace System is a complex system designed to ensure safe and efficient air travel for the general public. It has to accommodate commercial traffic, private traffic, recreationalists, emergency vehicles, military traffic, and more. A core component of this system is the air traffic controllers responsible for ensuring separation and flow of traffic across the NAS. Many explanations for the air traffic control system exist, so I’ll focus here on the tools controllers use and the data that makes these displays possible.

STARS and ERAM

This website is a portal into the world of Air Traffic Controllers, a window into the tools they have access to for their jobs. In the terminal environment, the tool is the Standard Terminal Automation Replacement System (STARS) developed by RTX. En Route Automation Modernization (ERAM) is the en route environment system to manage air traffic developed by Lockheed Martin. Though proprietary, the aviation enthusiast community has been able to extract much of the form and function of these tools over time. Today, we’ll see a very cool example of a browser-based application that recreates an ERAM-style display, backed by a server receiving live aviation data. (It also has STARS and many other features, though they aren’t completely built out and explaining them would take some time so I’ll stick to ERAM for this, but feel free to explore!)

Airspace & Controllers

To understand what we’re looking at on the scope, it helps to know how the aircraft get onto the screen in the first place. The FAA uses a network of surveillance sensors. Airport Surveillance Radar (ASR) covers terminal areas, while Air Route Surveillance Radar (ARSR) provides longer-range coverage. Primary radar detects radio waves reflected off aircraft, while secondary radar interrogates onboard transponders for information such as a transponder code and pressure altitude. Another source is ADS-B, through which aircraft automatically broadcast information including their satellite-derived position. The FAA has a surveillance overview if you’d like to dig into how these systems work.

Communications links carry these observations to the automation systems used at air traffic control facilities. Terminal Radar Approach Control facilities (TRACONs) handle arriving and departing traffic, while Air Route Traffic Control Centers (ARTCCs) handle the en route environment. These systems process reports from multiple surveillance sources and associate aircraft tracks with flight-plan information. Sensor fusion combines observations of the same aircraft into a single track, giving controllers a coherent picture of traffic. The FAA describes these sensors and their role in automation in its surveillance assessment.

Here is an ASR-11 airport surveillance radar antenna, photographed during maintenance. Its rotating antenna is one of the physical pieces of infrastructure behind the tracks on a scope.

Photo from DVIDS, released into the public domain.

This is where the tools mentioned above come in. The resulting display helps controllers understand where an aircraft is, its altitude and direction of travel, and its intended route. They use this information to maintain separation, sequence traffic, and coordinate transfers of responsibility between sectors and facilities. ERAM brings surveillance and flight data together with tools for controllers to work with that information and with each other. Those are the kinds of details we’ll be exploring in the browser scope.

Image source: FAA ERAM overview.

Real controllers also have the En Route Decision Support Tool (EDST), an integrated part of ERAM. Its conflict probe combines flight-plan and track information with forecast winds and aircraft performance to predict potential conflicts between aircraft, or with designated airspace. Controllers can also use it to check proposed changes before issuing a clearance. This helps them plan ahead, though I won’t go into those tools here. The FAA’s EDST description has more detail.

There is also some structure to the airspace behind those lines on the screen. Each center is responsible for a large region, divided into smaller pieces called sectors. These are three-dimensional volumes, with altitude limits as well as geographic boundaries. Two aircraft over the same place may be in different sectors because they are flying at different heights. The FAA’s Instrument Procedures Handbook illustrates this division into low, high, and ultra-high sectors. As a flight moves between sectors, controllers coordinate its handoff and the pilot changes to the next sector’s radio frequency, as described in the FAA’s en route procedures. When we select Oakland Center (ZOA) below, we’re choosing a region and then the sectors whose traffic we want to follow.

SWIM

So how does information from these systems become available beyond the controller’s display? The FAA’s System Wide Information Management (SWIM) program lets aviation systems share information through a common infrastructure. One of its services, the SWIM Flight Data Publication Service (SFDPS), distributes en route flight information generated by ERAM, including flight plans, amendments, and position updates. SWIM distributes information after the sensors collect observations and ATC automation systems process them for controllers. Services such as SFDPS then make selected information available to other systems and consumers.

From SWIM to the browser

The software behind the site is SwimReader, by GitHub user yanjz124. Looking through its code gives us the next part of the story. The ERAM web application lives in tools/SwimServer, with a C# server receiving the data and JavaScript building the scope in the browser. The following describes the public source; the deployed site may run a different revision.

On the server, a Solace messaging client connects to the configured FAA feed and listens to an SFDPS message queue. As messages arrive, the program parses their XML and uses each flight’s Globally Unique Flight Identifier (GUFI) to update its stored flight record. This lets separate messages about a flight accumulate into a useful picture of its position, flight plan, and control information. You can follow the connection and message processing in Program.cs.

Here is the part that starts receiving messages from the queue. Each arriving message is passed to ProcessMessage. The excerpts below have been reformatted for readability.

var solQueue = ContextFactory.Instance.CreateQueue(queue);
using var flow = session.CreateFlow(
    new FlowProperties { AckMode = MessageAckMode.AutoAck }, solQueue, null,
    (_, msgArgs) => { using var m = msgArgs.Message; ProcessMessage(m); },
    (_, flowArgs) => Console.WriteLine($"[Flow] {flowArgs.Event} - {flowArgs.Info}"));

flow.Start();

After parsing the flight identifier, the server finds or creates that flight’s record. This is what allows a stream of individual messages to build up a continuing flight history.

var state = flights.GetOrAdd(gufi, _ => new FlightState { Gufi = gufi });
state.LastSeen = DateTime.UtcNow;
state.LastMsgSource = source;
if (!string.IsNullOrEmpty(flightType)) state.FlightType = flightType;

The browser connects to that server through a WebSocket, a connection that stays open so updates can arrive without reloading the page. It first receives a snapshot of the available flights, then batches of changed flight records. The server sends these batches every second; that is the delivery interval to the browser, rather than a promise of a new sensor observation every second. The WebSocket endpoint handles the connection, while eram.js updates the aircraft symbols, data blocks, and track histories using a Leaflet map and canvas overlays.

The server’s timer sends accumulated changes once a second.

var batchTimer = new Timer(
    _ => FlushDirtyBatch(_dirty), null,
    TimeSpan.FromSeconds(1), TimeSpan.FromSeconds(1));

On the browser side, the batch branch of the message handler passes each flight summary to the display’s update function.

// Excerpt from the WebSocket message handler.
if (msg.type === 'batch') {
    for (const f of msg.data) {
        processFlightUpdate(f);
    }
}

Airspace information has its own path through the program too. AirspaceBridge.cs reads AIXM airspace messages carrying sector-assignment information. Alongside the aircraft updates, this helps explain why the site can offer both a scope and a view of how sectors are assigned. There is quite a bit of work behind those moving symbols!

The diagram below follows information from the centers through SFDPS and the messaging services that deliver it to FAA and external consumers. SwimReader’s server is a consumer of published data; its browser display comes after that distribution step.

Exploring the site

The home page groups its tools by data service. ERAM Scope sits under En Route (SFDPS), alongside the flight table and sector view. This is where we’ll start.

Opening ERAM Scope brings up the center selector. For these screenshots, we’re looking at ZOA, the identifier for Oakland Air Route Traffic Control Center (ARTCC), known on the radio as Oakland Center. An ARTCC manages en route traffic across a region, with responsibility divided among its sectors. The FAA’s Oakland Center page describes its domestic and oceanic operations; here we’re exploring its domestic sectors.

We’ll start with sector 14, which handles SFO-bound traffic approaching through the coastal airspace and outbound traffic heading south along the ocean. Later, the close-up switches to sectors 33 and 34, which work the DYAMD arrival flow into SFO. These give us two different views of how Oakland Center organizes traffic around the Bay Area.

The sector split map gives some geographic context. Here it is set to the Ultra High layer, with sector numbers and frequencies displayed. The altitude selection matters because this is one layer of the airspace, rather than a division that applies at every height.

For a closer look at the geography, the white-background map below comes from the VATSIM Oakland ARTCC community’s Airspace Visualizer. Here I’ve highlighted Oakland Center sector 14, extending along the California coast and offshore. It shows the sector’s footprint; its vertical limits are another part of the picture.

For help with the controls, the ERAM selection page has a COMMAND REF button. It links to a CRC ERAM reference covering targets, data blocks, toolbars, and commands. This is documentation for the CRC simulation; the site’s command reference indicates its own implementation status.

Reading the scope

Once the scope opens, there is a lot to take in. Aircraft symbols sit among the sector boundaries, with lines connecting them to compact labels called data blocks. Those labels bring together the surveillance and flight-plan information we’ve been discussing.

For this closer view, I’ve switched to Oakland Center sectors 33 and 34, which control the DYAMD arrival flow into SFO. An arrival flow brings aircraft toward the airport along a common route, with controllers organizing their spacing and descent before the transfer to approach control. There is other traffic in the picture too. Near the upper left, ASA581 gives us a relatively clear example of a full data block, with KLAX as its destination.

Reading from the top, ASA581 is the flight identification, or callsign. Below it, 350C tells us the aircraft is maintaining its assigned flight level, FL350. The C indicates that its reported altitude matches the assigned altitude. The next line contains 317, the flight’s three-character computer ID (CID), followed by its ground speed of 482 knots. Finally, KLAX identifies its destination as Los Angeles International.

Altitude values are shown in hundreds of feet; FL350 corresponds to a pressure altitude of 35,000 feet using the standard pressure setting. For an aircraft changing altitude, the block can show both its assigned and reported altitude, with an arrow indicating the climb or descent. Other fields change with the aircraft’s status, and the last line can display information such as aircraft type instead of destination. The data-block section of the ERAM reference is useful for decoding those variations.

You can also see smaller labels containing just a callsign and altitude. These are limited data blocks, which keep surrounding traffic visible without displaying every detail. The short trails behind aircraft show their recent positions. Taken together, the symbols, trails, and data blocks help a controller follow both where traffic is and how it is moving.

Displaying a route

Back in the sector 14 view below, I used the QU command to display ASA270’s route. The yellow line extends from the aircraft along its route, and the feedback area confirms ACCEPT, ROUTE DISPLAY, and ASA270/741—the callsign and computer ID of the selected flight.

To try this with a flight on your own scope, enter QU 741 in the command area and press Enter, replacing 741 with the flight’s computer ID (CID). You can specify a look-ahead time with QU 20 741 to display approximately 20 minutes of the route, or use QU /M 741 for the maximum available route. Entering QU by itself clears the route displays. The site’s QU implementation uses the available route waypoints and a speed estimate to draw this line.

The history trail we saw earlier shows where an aircraft has been; this overlay shows the route ahead based on the available flight data. Following that line, we can see where the route crosses sector boundaries and turns, and how it relates to surrounding traffic. Actual instructions and subsequent route changes can alter the path the aircraft eventually flies.

Listening along with LiveATC

To connect what you’re seeing with what controllers and pilots are saying, try listening along on LiveATC. The main task is finding a feed for the sector and frequency you’re watching. For Oakland Center, the VATSIM community’s ZOA position reference lets you look up a sector’s position callsign, radio name, and frequency. For example, it lists sector 14 as OAK_14_CTR, with the radio name Oakland Center and frequency 134.550 MHz, matching the label in the sector split map above.

Find your selected sector in that table, then look for an Oakland Center feed on LiveATC whose listed frequencies include the matching frequency. Where a matching feed is available, listen for the flight numbers shown on your scope and follow an altitude assignment, a turn, or a transfer to the next frequency. That gives the moving symbols and data blocks a little more context.

One other interesting, related tool is Vice, an open-source ATC simulator with STARS and ERAM interfaces. It is more suited to readers who already have some familiarity with ATC procedures. Its documentation and GitHub repository are worth a look if you’re curious.

Explore the tools

SWIM Viewer home · SWIM ERAM Scope · Airspace Visualizer · LiveATC · ZOA position reference · Vice · Vice documentation