The Big Sky Theory

My Story of ATC for Decades


(Mouseover any identifier to decode)

NAS, Enroute Stage A, Functional Package A. What a mouthful that is—governmentese, no doubt. In a paper dated 1966, it was described, in part, thusly:

The improved National Airspace System (NAS), when implemented, will make automation available in air traffic control services from takeoff to landing wherever such automation is warranted. This aim is to be achieved in stages and this paper will concern itself primarily with the first stage implementation, called NAS En Route Stage A. This first stage is designed to provide a significant amount of automation for the Air Route Traffic Control Centers, with an objective of assisting the air traffic controller in his job and providing an increased level of efficiency and safety in the Air Traffic Control System. The modular nature of the Central Computer Complex which is to be implemented and the design principles used in specifying its characteristics are discussed in addition to the computer programing being developed to perform the required tasks.
The FAA has rightly taken a lot of flak over the years for its expensive, overdue, and in some cases, cancelled modernization projects. In fact, NAS (as we erroneously termed the automation component of the National Airspace Systyem) itself, was two of three. However, I have to concede that it evolved quite successfully, after some early hiccups, into a career extending tool for many controllers.

Four years later, a report was filed which described progress so:

The purpose of this project is to measure, by collecting factual data, the effect of introducing NAS Enroute Stage A equipment in the ARTCC at Jacksonville, Florida. The intent is to obtain measurements on the enroute air traffic controller activities before the introduction of any new equipments, and then to make subsequent measurements after the introduction of new equipments to determine what changes resulted on the part of the controller activities. This report is a summary of the measurements made before the installation of any new automation equipment in the Jacksonville ARTCC, essentially a manual environment. Subsequent reports will be issued after measurements are made on Functional Package A and Functional Package B implementation.
For simplification, FPA was the flight data portion (strip generation) and FPB was the automated radar tracking portion of the planned automation. FPA has been alluded to in my earlier chapters—it was the system being tested when I came downstairs from Flight Data School.

By the time I became an FPL (full performance level controller, or journeyman, as we sometimes called it) in 1970, FPA was up, running, and a fact of ATC life at ZJX. And we were the only ones that had it. Everyone else in the country was still hand writing strips, although ZDC had a crude, inhouse, one-off UNIVAC dinosaur which they similarly employed. I learned in recent years that ZJX had been selected for the prototype of both FPA and FPB, upgrades of which would eventually be deployed nationwide, because of the unique and broad range of demands on and complexities of ATC in our area. In the using, it became clear that there were a lot of advantages (and some disadvantages) of FPA. A principal advantage was to any controller who had to use a strip written by me, although exposure to that hazard was virtually nil by 1970. Legibility was no longer a dream when reading strips. A disadvantage was the excess of strips generated as a result of the parameters that had been built into the system.

All in all, though, FPA turned out to be a winner, and when FPB got ginned up, we could see the future (we thought) of ATC. FPB basically was “automatic shrimp boats.” Oops, let’s step back a moment. Most people’s notion of surveillance radar displays is what you find in a dank cave of an approach control. There, each display is called a PPI (plan position indicator) and is basically an oscilloscope with very low persistence (how long the data lasts on the screen), the duration of which is extended by dark surroundings. PPI is no good in brighter surroundings commonly seen in ARTCCs, so equipment called BRITE (or Bright Radar Indicator Terminal Equipment, as I’ve recently been enlightened*) displays were employed. Essentially, they are TV sets displaying an image of a PPI located in the bowels of the facility somewhere. The equipment we used throughout my career was called RBDE-5 (Radar Bright Display Equipment, series 5).

(Click on picture
for full size image)
Here’s a picture of one, behind a guy I don’t know, in a facility I visited once—ZOA. For years now, I’ve tried to remember how big the screen was. I’ve alternated between 16" and 36" and several sizes in between. You’d think that as many hours as I logged in front of one I’d have a better notion, but I don’t. Based on further research I think around 18" is about right. Typing that makes it seem really small, but I think my mental image is muddled by the size of the surrounding chunk of steel and the various keypads installed thereon.

Incidentally, that display is two generations removed in capability from those I pushed shrimp boats around at ZJX, but you’d be hard pressed to tell them apart. My memory of nearly 40 years back doesn’t serve up any details, such as various push-button accoutrements on the periphery. I’m confidant they weren’t there in 1968, and we absolutely had different things when FPB came on line in ’72, or thereabouts. For example, we got a trackball, because among the functions we were going to get, many necessitated slewing a marker to various places on the scope, much like a mouse in a modern computer. By the way, they make trackballs for computers, too, and after 30 years of using one on the job, I can’t function with a mouse and have had a trackball on my computers since well before I retired.

We also got a keyboard. A godawful one, too—much like the keypads on today’s cellphones wherein each key has four or more functions. It was the radar man’s interface with the computer (the D-side had a standard QWERTY keyboard), and if you were going to start a track on an airplane, for example, every alpha character required a minimum of two keystrokes and as many as five! That was the principal shortcoming, however, as having an actual data block automagically follow the airplane along was tres cool. We also gained the capability of making and taking handoffs at the click of a button instead of punching a line and having a chat.

And the number one advantage of FPB was altitude readout. Prior to that, we had to engage the pilot in conversation to get altitude reports that confirmed separation. We got to be pretty good at gauging rate of climb or descent with a couple of well timed calls, but with altitude readout, we no longer needed to make a single call—it was displayed right there on the data block. That whizbang alone was worth the price of admission into ATC automation—much better than eliminating Flight Data.

I don’t know how many hundred radar controllers worked in ZJX from, say 1970 to around 1976, but I think I have a good idea of how many have websites that talk about it, and you’re here. Despite that large number, I feel like a very tiny minority who experienced FPB. It feels kind of good to reminisce. FPB was pretty good. In fact, its replacement wasn’t so—or at least there were some tradeoffs that I might have preferred not to make. I’ll explain more of that later.

We knew our system was a prototype and although we assumed the replacement would be built largely on our experiences, we really didn’t get much feedback or insight into what was coming. I believe most were surprised since we expected it would be pretty much what we had at that point with FPA and FPB. My first hint was a few months before I left for ORD when I was selected to be an instructor for FPA’s replacement. It got a little shorter name: NAS Enroute Stage A, Model 3. If we were Model 1, I have no idea where Model 2 went, and if we were Model 2, where was Model 1? It gets even more amusing if you consider that automation (IT) people almost universally start counting at 0 (zero), so that Model 3 was actually the fourth in a series…theoretically.

text (Click on picture for larger image)

I have a list of things that make no sense to me. #1 (and retired the trophy, never to be supplanted) was the keyboard in the ARTS environment (Automated Radar Terminal System—automation for approach controls). The keyboard, looking like a regular computer keyboard, was laid out alphabetically! In one of the most high stress and time critical work environments on the planet, who would design an automation system to improve efficiency with an alphabetical keyboard? Check out the 28 orange-ish keys at the lower left of the keyboard. Click to confirm the alphabeticity of the layout.

It may not sound like much because you’ve likely never heard of such a thing. The concept is actually #3 in possible choices: the standard QWERTY comprising maybe 99% of the English speaking users, the quaint Dvorak layout, supported in most OS software, but rarely implemented—nevertheless, let’s assume most of that remaining 1%, and alphabetical? It doesn’t even register on any measuring device I can imagine, or as I am fond of saying, the instrument has yet to be devised capable of measuring its existence. Nevertheless, some contractor sold some non-controller decider on the idea. If you’re a touch typist, as am I, it’s like being forced to make computer entries with a hammer and chisel on stone. You may not realize, as a touch typist, that you don’t really know where specific keys are on a keyboard—you just mentally send your fingers to the right place. Try that on an alphabetical keyboard…if you can find one.

Okay, I was making a list. The rest of the things on the list needn’t be identified by their position, but I will say that having the FPB keyboard with the commingled alpha/numeric keypad certainly makes it. There were several functions of FPA that got changed when Model 3 came along. Most of them made it harder to interface with the computer.

I’ll try to describe one tidbit that I remember. With FPA, when typing in the route of flight in a flight plan, you inserted a period between each element of the flight plan. For example, if a flight was filed MIA J77 JAX J45 ATL J89 LAF CGT V7 KEDZI ORD you would type in MIA  .  J77  .  JAX  .  J45  .  ATL  .  J89  .  LAF  .  CGT  .  V7  .  KEDZI  .  ORD—which makes perfect sense, both philosophically and computer…, er, …nomically, as the period is easily read by the computer as a separator between elements of the route of flight. With Model 3, howevr, you had to put two periods between like elements. In other words, the above route would look like: MIA  .  J77  .  JAX  .  J45  .  ATL  .  J89  .  LAF  .  .  CGT  .  V7  .  KEDZI  .  .  ORD. Similarly, if someone filed …J77 J53… instead of a single period between the two airways as with FPA, you would type …J77  .  .  J53… Even though I asked when I took the instructor’s course, no one could explain why the double periods were necessary. It didn’t make sense computer…, er, …nomically then, nor did it many years later when I got fairly computer…, er, …nomically literate myself.

I can’t remember other specific examples (after almost 40 years) but I couldn’t fathom why they did them that way. What was frustrating in teaching Model 3 was having every single controller ask precisely the same “why’d they do that?” question that I asked when I was trained on it. I don’t like questions I can’t answer. I was happy for the training experience and I got a nice letter of appreciation out of it, but it kind of soured me on being a guinea pig.

*thanks to my former coworker, adversary, and friend, Steve Meitz

©2016 The WebButcher
All Rights Reserved

Site design by Rod PetersonThe Webbutcher

Last updated: 21 April 2013