by Paul Dye
On the ground in Houston, down near the front of the MOCR, located close to the trajectory folks, you could always find a pair of flight controllers who worked very closely with each other and with the folks who were figuring out where the Shuttle needed to go. These two controllers were in the middle of things because they were in charge of the systems that did the onboard navigating, plus the jets and rocket engines that made it go. The first of the two, the Guidance, Navigation, and Control (GNC) Officer, looked after the inertial measurement units that tracked where the vehicle was in space, as well as the sensors that fed the Inertial Measurement Units (IMUs) with information on the outside world—things like star trackers, accelerometers, air data probes, and the like. The GNC Officers lived in a world of precision measurement, and their software was as complex as their hardware.
The Shuttle knew where it was because we started out by telling it exactly where it was when it started. It kept track of its location by measuring acceleration in three dimensions, and then adding each bit of motion to its last known location to come up with its new position. It’s really no more complex than knowing that you started at your front door, moved 20 feet north and 5 feet west, then climbed 5 feet up a ladder that was leaning against your old oak tree. You know exactly where you are relative to the front door of your house—and you better keep your balance because that ladder looks a bit rickety. Tracking a vehicle in space is, of course, more complex than that because the equations of motion are affected by gravity. But, essentially, you are doing the same thing.
The Shuttle measured accelerations using finely tuned accelerometers that were strapped to the IMU stable platform. It was stabilized by spinning gyroscopes (in the early days), and in later years by solid-state devices—similar to what you have in your cell phone today. Picking a reference frame that is stationary among the stars is surprisingly straightforward. Earth may be rotating underneath you, and it may be going around the sun, but you can compute those motions, knowing Newton’s laws. You can also compute your own motion because you are measuring it relative to those same stars. For the Shuttle, this was done using the IMU and accelerometers mounted on its stable platform. Just like measuring your motion in the front yard, we were able to tell exactly where the Shuttle was, so long as we knew where it had been.
So how did you know that the IMU platforms were properly aligned to the stars? Well, you took a look at the stars every once in a while using automated star trackers—you can think of them as specialized cameras that were bolted to the same solid piece of metal to which the IMUs were mounted. The Shuttle had two star trackers, and each of them could track stars by measuring where they were in the field of view and how bright they were. If you started out assuming that you knew how the platform was pointed, you could tell the vehicle to put a particular star, say, Polaris (the North Star) in one star tracker and Sirius (the brightest star in the sky) in another. The Orbiter would maneuver to the necessary attitude and, hopefully, the two stars would be located approximately where they were supposed to be. Now nothing is perfect, and errors can drift into your knowledge of how you are pointed. So what the trackers did was measure the error between where the stars were supposed to be in their fields of view and where they actually appeared. They did this with great precision. With two stars in the tracker, the computers could compute the platform’s alignment, and the crew could order the computer to take that error into account, realigning the platform and once again giving you the necessary information to track your progress through the sky.
What happened if you lost the platform alignment completely? What if the IMUs tumbled, or the computers really messed up and lost their knowledge of how you were pointed? Well, then it was time to get out the star charts and a special gunsight-like device known as the Crew Optical Alignment Sight (COAS). Pilot astronauts trained to identify stars, then maneuver to put the stars in the site, and tell the computer which star they were pointing at. The computers would mark that position. Then they’d maneuver to another star and mark that position. Since the computer knew the positions of the stars, and you had now told it where the platform was relative to those stars, it could once again figure out its attitude relative to the stellar reference frame and once again track its motion.
So attitude was important—but so was knowing the components of your velocity (which were derived from accelerations) so that you could add up the motion in each of the three dimensions. We did this by starting with a special set of numbers known as a state vector. The state vector, in simple terms, was your position and velocity in space, in three dimensions, at a specific time. If you know the six components of position and velocity, and the time you were there, you can add up all the sensed motions since that time and figure out exactly where you were at any given later time. It is an elegant solution, and not that different from navigating on the surface of the planet, keeping track of where you have been. The scheme just does it in three dimensions. Of course, no man-made sensor is perfectly accurate. The longer it has been since the time of your state vector, the more error there was bound to be in your position. Fortunately, the ground kept track of the exact position using tracking stations and satellites, and every so often we’d send a new state vector up to the computers on the Shuttle, starting the whole propagation process over.
Early in the Shuttle program, state vector updates came a couple of times a day. But sensor accuracy improved over the years, along with the equations of motion. In later years, you could go much longer between state vector updates or alignments—this was a good thing, because once you were docked to a space station it was much harder to maneuver to find stars and check the alignment.
Now, of course none of this was possible if you couldn’t maneuver, and doing that was achieved with the jets and rockets that were looked after by the Propulsion Systems Officer (PROP). PROP was responsible for all the thrusters, the fuel and oxidizer tanks, and the complex of pipes and valves that connected them all together. These thrusters came in three basic sizes: small, medium, and extra-large. The extra-large thrusters were the two OMS engines used to significantly change orbits. Generating about 6,000 pounds of thrust each, they could raise and lower the orbit significantly when burned together or singly. Each one was mounted pointing aft from their two respective pods on either side of the vertical tail. They had their own dedicated propellant tanks, but these tanks could be interconnected to burn the left engine from the right side, or vice versa. This was for redundancy as well as to give us the ability to balance the Orbiter laterally.
The medium thrusters were the Primary Reaction Control System jets (Primary RCS), usually referred to as the primaries. There were thirty-eight primary jets that produced about 800 pounds of thrust each. Distributed across the three pods—the two aft OMS pods and the forward RCS—each pod had its own tankage, and the jets were arranged on specific manifolds, numbered 1 through 4. Manifold number 5 was for the small vernier jets. There were just six vernier jets of about 24 pounds each. While the primaries were the big movers, they used a lot of gas, and trying to do fine pointing with them was bound to use lots more—so the verniers were used any time you wanted to move just a small fraction of a degree and not shake things up.
All the thrusters used what is referred to as hypergolic propellants—that is, the oxidizer (nitrogen tetroxide, a nasty orange liquid/gas) and monomethyl hydrazine (an even nastier poison)—which ignited as soon as they came into contact with each other. Ignition produced thrust in the rocket chamber. You didn’t need any sort of electrical igniter—just open the valves, and whoosh—you had thrust. Of course, you wanted to make darn sure that they didn’t come into contact with each other when it wasn’t intended, so the plumbing systems were separate, and for our use, redundant. This made for a veritable plumber’s nightmare of tubing, valves, and regulators, all of which were controllable from the cockpit switches, or through the main computers. If a jet started leaking, you generally had to close its manifold. Unfortunately, that manifold contain
ed other jets as well—which meant that a leaker didn’t cost you one jet, it cost you several.
PROP Officers spent a lot of time making sure that they knew where their fuel was, what jets were active and available, what jets had problems, and how to get the thrust needed in any direction should it be required. The PROP system, with lots of hardware and countless ways in which it could be configured, was a target-rich environment for the simulation instructors, and they took advantage of it. We often finished a simulated docking with barely enough jets to make it safely work out—and rarely any more than that.
When things got hairy in the trajectory, propulsion, and navigation worlds, it was common to see these officers huddled together, trying to figure out how to tell the Flight Director the bad news—that we could no longer accomplish the mission, and that we might not even be able to have a good way to come home. Likewise, when we knew that there were failures in the propulsion and navigation systems, and the trajectory was off nominal (not as planned), the Flight Director was able to lob the whole problem in their direction. I have to admit it was fun to watch the feeding frenzy as they worked toward a solution.
So now you have a vehicle that you can navigate and control, and hopefully have some idea where it is and where it is going. However, none of this can happen if you don’t have a computer system to operate everything. Enter the Data Processing Systems (DPS) Officer and their magic boxes. It is common today for aircraft to be built using what we call fly-by-wire systems—that is, there are no direct mechanical connections between the pilot’s stick or yoke and the aircraft’s control surfaces. Even engines are fly-by-wire in most machines. In this type of system, the pilot moves a control that effectively tells the computer, “I want to go over there.” The computer decides the right combination of control surface movements to make that happen and carries out the pilot’s wishes. It does all this with software, running in computers, and transmitted through specialized computers. It’s a system that translates digital code into analog commands, or analog data into digital parameters for the computer to digest. As I said, this is pretty normal here in the twenty-first century.
But in the 1970s, when the Shuttle system was designed, fly-by-wire was in its infancy. At that time it was a monumental task to design a safe, reliable system that could operate with failed components and ensure that the appropriate functional capability would still be provided. The DPS Officer was responsible for looking over all of these computers, as well as their software, and managing the system through failure cases so as to provide the most capability and the safest redundancy.
The heart of the DPS were five identical General Purpose Computers (GPCs) that ran the software to operate and monitor the vehicle. We used three major functions: the Guidance, Navigation, and Control (GNC) software (previously mentioned), the Systems Management (SM) software that allowed us to control and monitor systems throughout the Orbiter, and the Backup Flight Software (BFS) that was used to provide a redundant software package for the critical phases of ascent and entry. No one was ever quite certain that there couldn’t be a generic fault in the Primary Avionics Software (PASS) that consisted of the GNC and SM software, so early in the program it was decided that a separate entity would write the code for the BFS to make sure that a common software fault couldn’t bring down all the computers. If the PASS had such a common software fault, then you could always engage the BFS, which was running all by itself in one computer. Generally speaking, the PASS GNC software ran simultaneously on four computers for ascent and entry, and the built-in SM function of the BFS was used to look at systems when required.
The GPCs of course talked in digital code, and all the temperatures, pressure, speeds, and other data generated by sensors throughout the vehicle were analog measurements. So black boxes known as MDMs (Multiplexer/Demultiplexers) were used to gather data and convert it to digital code for the GPCs to digest. When the GPCs had commands to send out, they sent the data to the MDMs and those boxes converted the data to what was needed to move a control surface or fire a jet.
The entire DPS (and the GNC system as well) was organized into four Flight Control System (FCS) channels, each with its own string of hardware that commanded redundant strings of controllers. For instance, an elevon had a four-channel hydraulic actuator, and each channel was commanded by a single channel. During ascent and entry, when the control surface was needed, each of four PCs was in control of an FCS string, and each would send its commands to the control surface actuator. So long as all four of the GPCs came up with the same commands, all was fine. If, however, one came up with a different answer, then three outvoted one, and the one channel was ignored. Flight controllers and the crew looked closely at all the channels, watching for faults—in which case they could disable the faulty channels.
Any GPC could be assigned any string—and a GPC could control multiple strings. The DPS Officer was the conductor of this “string orchestra,” making sure that the crew and vehicle always had as many working channels and computers as possible. Sometimes, it was hard to figure out where a fault lay. In such cases they’d try a stringing configuration (say, put two strings on one GPC, and two others on another), and see what resulted. Sometimes the stringing could get quite entertaining—so long as you weren’t the one in the hot seat. String theory is not just the latest thing in high-end physics—for decades Mission Operations hosted meetings on how to string for every foreseeable failure case. The theories changed as we learned more—just like the strings hypothesized by physicists. DPS controllers had to be sharp and keep a large matrix of options open to them during dynamic flight phases.
Once an Orbiter was in space, things got a little more relaxed. To save power, numerous GPCs were put to sleep, with generally only one GNC machine and one SM machine up and running. If we were doing something flight critical, like a rendezvous, we of course would bring more machines back up. But generally, we ran as few machines as possible, with others “freeze dried” such that they could be brought up at a moment’s notice if failures occurred. Interestingly enough, there was no way to actually power down a GPC short of taking out a set of wire cutters and snipping the power lines. Even when it was switched off it was still running. And this made sense because without the computers, you had no Shuttle. It was, after all, fly-by-wire, and without the wires (the computers), it wasn’t going to fly.
Closely related to the DPS was the other digital electronic discipline, with their own set of black boxes—the Instrumentation and Communications Officers (INCOs). A discipline that moved intact from Apollo, the INCOs could be thought of as the radio operators for the Shuttle flight control team. Shuttle communications were all digital, and the INCOs were responsible for voice communications (both ways, up and down), for telemetry data that came down from the Shuttle to the ground, for commands that went up to the vehicle, for television signals that came down, and for recording data on board the vehicle. There were numerous radio systems, from the plain and simple UHF aircraft radios that were used as a backup in case all the sophisticated digital gear failed, to the primary comm system that sent digital data both ways using the S-band frequencies, and up to the high data rate Ku band (another set of radio frequencies) that carried mostly scientific data and high-density television signals.
The S-band system was the primary link used to carry voice both ways. It also carried commands going up and telemetry going down. Unfortunately, the data rates available on S-band meant that not all telemetry parameters could come down at the same time, so different formats (known as Telemetry Format Loads, or TFLs) had to be chosen depending on what was going on. That meant that at certain times, some flight controllers didn’t see some of their data, and selecting which format—each format contained a specific set of data parameters—became an interesting game that the Flight Director had to referee. This, for some reason, became easier as the program went on—mostly because the formats and procedure matured, and more folks became comfortable not seeing specific things at certain t
imes. In the early days, however, there was always a lot of switching going on, with a lot of horse trading behind the scenes.
INCO’s S-band antennas were fixed on the skin of the Orbiter (actually they were mounted underneath the tiles, which were transparent to radio waves). These antennas were located on the belly and on top. Each of them was fairly directional and pointed up or down, forward or aft, left or right. It was the INCO’s job to make sure that we always used the antenna that was best pointed at a ground station or satellite to communicate with the Orbiter. This was computed automatically by the GNC software when everything was working. When either the GNC lost its attitude knowledge or the ability to talk with the antenna-pointing hardware, the INCO became a busy person trying to visualize the Orbiter’s attitude and the relative position of the station to which we were trying to communicate. The result was that just when we needed to talk to the crew the most (to solve a problem), our ability to talk with them became the most suspect. It made for an entertaining time watching the INCO try and predict antennas when he had no knowledge of where the vehicle was actually pointing because the pointing software was being lied to by the failing software! At some point, just before losing contact, we’d just throw up our hands and tell the crew to select the “best antenna.” They had a signal strength meter on board and a rotary switch that they could use to hunt for the antenna that gave them the best performance. The crewmembers were motivated to do so because until we could talk with them, they were on their own. And, of course, there were times when they liked it that way. Sometimes you just needed peace and quiet to solve a problem.
