Space Center Oral History Project
Edited Oral History Transcript
Interviewed by Jennifer Ross-Nazzal
Houston, Texas – 10 July 2009
Today is July 10, 2009. This interview with Jack Knight is being conducted
for the Johnson Space Center Oral History Project in Houston, Texas.
The interviewer is Jennifer Ross-Nazzal, assisted by Rebecca Wright.
He begins by discussing a chapter he wrote for the publication
Legacy of the Space Shuttle Program: Scientific and Engineering Accomplishments.
The reason I wrote that the way I wrote it was based on the original
story that Helen [W. Lane, editor] gave me as to what they were trying
to do. Now it seems to have shifted some. What I experienced over
many years with Operations was that all these outsiders come in, says,
“Why does it cost so much?” They have some kind of notion
that Operations ought to be real cheap, but it isn’t. Yet it’s
only 6, 7% of the total Shuttle budget, but you always had these outsiders
come in saying, “You guys.” It’s marching armies,
and all this kind of thing. In fact, it wasn’t really so, but
I was trying to somehow communicate the volume of the work.
From time to time over the years, we had a couple of astronauts inserted
in as deputy director or associate director. One of them, Tom [Thomas
D.] Akers came in. After he was there a few months, he said he just
never understood or knew what MOD [Mission Operations Directorate]
did. Now, of course, it evolved over the years. When you started out
in Apollo, there were different divisions. Then there were a lot of
mergers over the many years. So it became somewhat bigger. In fact,
I guess in Apollo a good bit of the flight data file and a lot of
the training was in the Flight Crew Operations and not in FOD. It
was called Flight Operations [Directorate] at that time. There’s
been a lot of evolution over time, but where we started out in Shuttle
is about where we are now, with the exception [that] George [W.S.]
Abbey [added] the NBL [Neutral Buoyancy Lab] and some of that stuff
in Building 9 (mockups) into MOD. It became somewhat bigger in that
we merged with the people that built the control centers. That became
part of MOD. It’s now somewhat bigger than it was in terms of
facilities. The core flight control thing, there was some merger there
over the years. So it became bigger than it was.
Nevertheless, what I was trying to do was communicate the breadth
of what MOD did. If you try to run it through just a single flight,
you may not get that picture, because a good bit of the size of MOD
has to do with the fact you have multiple flights in work simultaneously.
If it takes you two or three years to build a trajectory, and what
flows from that is part of the training trajectory and the training
systems. Then you’ve got a flight a month or a flight every
two months, so now you’ve got two years stack, stack, stack.
You have to go down and see how many simultaneous flights in flow
that you have. That tends to drive the budget. The picture people
have is these guys that hop up on console and that’s it, and
there’s a lot more to MOD. That’s what I was trying to
Whether you can do that or not focused on a single flight, I don’t
know, because I haven’t read what you’re trying to do.
But let’s go answer these questions here, and then I can come
and I will verbalize, and then we’ll see if I want to go back.
You asked for some specific examples. Memory fades.
When I was going through the chapter I had some questions.
The last flight I worked, actually worked on personally as a flight
controller, was STS-4. After that I was in management: technical assistant,
a branch chief, and then eventually deputy division, division [chief],
and then I moved to facilities. I can also give you some other names
if you want to get some more detail. Why don’t we go through
the questions or however you’d like to do this and then see
where it goes.
That’s perfectly fine. I’m just looking for information
to flesh this out.
Let me see. Did you get to read what I wrote?
I did, I did, yes.
Did you have any questions on those?
I’m wondering if you can talk a little bit more about the facility
Let’s see. I numbered. You mean typical changes instituted at
MCC [Mission Control Center], that question?
Yes, the typical changes instituted at the MCC for a new Space Shuttle
Let me give you some more as background. The Mission Control Center
originally, of course, was built for Apollo. Then it was modified
or evolved over time. Some of it was just pure replacement of hardware.
IBM [International Business Machines], “Here’s a new machine;
we got a new operating system.” So we incorporated those kind
of things, and then we laid our apps [applications] on top of that.
As technology evolved, when you could justify it, you’d bring
it in. Apollo evolved to Skylab, and then Skylab evolved to Shuttle.
The Mission Control Center originally for Shuttle, from the outside,
looked pretty much like it did for Apollo and Skylab.
You were using the same consoles for STS-1?
The console shells. Then what was internal to the consoles, there
was evolution behind the scenes. Things that used to be done in separate
hardware to drive event lights, for example, came into the Mission
Operations Computer [and] were driven by software. The communications
panels, for example, were originally all hardwired. If you wanted
to change it you had wiring that went all the way down to the first
floor and then back up to the second and third floor. We replaced
that eventually with a system that was more software-oriented, so
it was easier to change over time.
We started out the Shuttle with the mainframe, the MOC [Mission Operations
Computer] and so on, although it was different hardware than we had
originally. Like I say there was a whole evolution on that, and there’s
a document that discusses that. That’s how we started Shuttle
out. We had the third floor and the second floor. Then as part of
that Shuttle, remember, was sold and approved by the [Richard M.]
Nixon administration to be the only launch system for the country.
So it had Department of Defense [DoD] stuff in it. The third floor
was modified to be secure. They had this thing called TEMPEST [Telecommunications
Electronics Material Protected from Emanating Spurious Transmissions
or Transient Electromagnetic Pulse Emanation Standard Requirements]
for RFI [Radio Frequency Interference] emissions and things like that.
A lot of work was done on the third floor. There were access changes
The two floors became a little different. Until [STS]-51L [the Challenger
accident], we flew the DoD flights off the third floor, and the second
floor was generally other flights, although we could fly both on each.
The modifications that were made were typically software, after that
initial setup was done. [STS]-51L was in 1986. Then we were down for
two and a half years. The country changed its priorities. DoD says,
“We don’t like that Shuttle anyway, we want to go back
and do our Titans,” etc. The country said, “We’re
not going to launch satellites that can be launched off of unmanned
launchers. We’re not going to risk crews,” etc. So we
changed the whole mode.
Station was coming along. The model and the theory was that the building
that we had for Shuttle was not enough to fly Station, which was a
continuous operation when it came into place. So Building 30 South
was funded and was built. At that same time, the commercial technology
for minicomputers was blooming and was available, and we embarked
on a process to distribute the processing, get away from the mainframe,
which we deemed to be more expensive and go to these things. That
was an evolution that began in the ’90s. The [new] building
[B30 South] was finished ’93ish or thereabouts. We said we were
going to populate that out. We were going to do that with a distributed
Now that took several years to do, and we had command, we had telemetry
processing, we had trajectory processing. Telemetry processing was
first to move to a distributed system. Command was later. So about
1995, I think, we started our first flight doing telemetry processing.
We still had the MOC, the mainframe. Command went through there, and
trajectory was done there. Then they distributed that data off of
a local area network. Why am I telling you all this? This is all background.
But what kind of things did we do? So we put all of that in place
to make the change process mostly software, because hardware would
take longer and was more expensive, depending on the kind of hardware.
We tried to put as much in software as possible so that what you changed
for a Shuttle flight is pretty much all software.
Now, the thinking at the time was on Payload Operations Control Centers
(POCCs). You asked a question along those lines. We put in hardware
to account for what we considered to be the peak loading, so that
[when] we’d have a Spacelab customer or something like that,
and we said what’s the maximum that could be. We put that in
place. When you have less requirements for that, they just use fewer
of the hardware consoles. It was again a distributed system, so you
could buy these DEC Alphas, which is what we used to begin with. When
you needed them, you’d buy more. Then as they obsoleted, you
wouldn’t replace them.
Now while I was there in the 2000s, DEC went out of business. Their
Alpha chip was not a bad chip, it was a good machine, but they just
quit manufacturing. We went to a PC [Personal Computer] class machine,
an Intel type processor. We went to a Linux operating system for most
of it, not all of it. The main core processors and its distribution
system are IBM. The [Cisco] switches, switching networks all internal,
the Ethernet switches, those are commercial. We just use them as we
So what that means is that as change needs to come in, it’s
pretty much all software. If a customer comes in, and he’s going
to operate out of the MCC, what do you need? Well, we need three of
these consoles, four of these consoles. Working through the Shuttle,
if they have commands, command typically goes up to the vehicle, goes
through the GPC [General-Purpose Computer], the SM (system management)
computer and off to the payload. That means they have to go through
the Shuttle process to define those commands. That’s all a well-defined
process. It goes through the Shuttle Program. They take all those
requirements, build a mass memory load that is the flight software.
Also, that process of developing that software spins off Shuttle data
tapes, which is what we use to build command and telemetry datasets
that we can use in the control center. As the Internet expanded and
became more reliable, some of these customers said, “We don’t
even want to bother to come there. Just ship us the data.” Okay,
well, we’ll do that. We have interface servers and stuff like
that. Ship it to them. Command is a little more controlled. If they
want to send commands, they come here or from Marshall [Space Flight
Center, Huntsville, Alabama]. Marshall has a payload ops control center—POIC
[Payload Operations Integration Center] for Station, but this is Shuttle.
When we were running Spacelab operations, Marshall was responsible
for Spacelab, even though the Germans built the first one. Marshall
picked it up. So they had an operations control center there. They
could send commands because we had those direct interfaces. They’d
send commands through here, and then they’d go up to the vehicle.
Again all this allows you to do software, and it is through a software
process, some of which MOD controlled and some of which we are customers
of the Shuttle Program, because Shuttle Program, today, owns and keeps
their flight software development and production. Now, we house it
in our buildings as a facility, but they own the process, if you understand
the distinction. They pay the people that do the work. We house, we
power, we have the people that maintain the functional system. But
they own it. Now does that help you?
It does. Let me just make sure that I understand it. When you’ve
got a new mission, say, STS-28, primarily the only things that would
change would be software. If you had a different Orbiter than the
one you used last time, depending on the payloads. Is that correct?
Yes, that’s essentially correct. That’s where we tried
to go. I think we were pretty darn successful at that. The software
requirements that are for that new mission come out of the Shuttle
Program. We take that, and then we modify, build, and test our software
appropriately. Then we also build the training loads that go to the
Can you talk to us about working with the various customers over the
years? DoD, partners, other Centers?
Working with DoD—they actually came here. We helped train them,
they sent a lot of people here. They worked for us. They were intending
to have their Blue Cube [operations center at Onizuka Air Force Base,
California] out there and were going to control flights out of Vandenberg
[Air Force Base, California]. All that collapsed. So that was the
kind of interface. It was just flight controller to engineer. After
51L, our interface with DoD was search and rescue—that was a
KSC [Kennedy Space Center, Florida] interface with them. Our interface
with them was for the debris avoidance and for certain use of their
assets if we needed them for photography, taking pictures with some
of their assets. So we worked with them on that kind of thing.
We also worked with them for range safety at the Cape [Canaveral,
Florida]. We would send them our predicted launch trajectories. They
would build their impact predictors, so they’d know when to
do destruct if they had to. Then we worked with them a lot on the
destruct issues. That was just people-to-people interfaces. Mostly
it was trajectory and flight director, but in fact, there’s
a little contingent of DoD people that live in the control center.
Mostly I think for asset usage, and in case you have to dump a Shuttle
or something like that.
It’s a very select group of people. There’s what’s
called a STU [Secure Telephone Unit]-III phone that the FDOs [Flight
Dynamics Officers] have that is a secure phone. So you can talk to
them using secure access.
What goes into that debris avoidance? How does that work?
Well, the Air Force for years has [had] a bunch of radars. I think
their control center is Colorado Springs, but their radars are somewhere
in various places. They’re there to track ballistic missiles.
They also track other debris so you can distinguish good things from
bad things. These pieces that occur because of parts come apart, explode,
stuff like that, well, now there’s debris all over the place.
Most of it is very small. They can track down to a certain level,
but those debris trajectories meander around. They eventually can
have intersecting trajectories between human stuff: the Station, the
Shuttle, whatever, and we prefer that not to happen. The bigger it
is, the more potential impact it would have.
They track that stuff all the time, and those, because of solar activity,
the atmosphere goes up, comes down, those trajectories change. Depending
upon what your launch azimuth is, those can have potentially intersecting
trajectories. Now, those are all statistical calculations. So you’ll
have a big ovoid that says the Shuttle will be here, and this debris
will be here within some probability. If those probabilities reach
a certain level they call us and say, “You got a potential conjunction.”
Depending upon that conjunction probability, the flight director and
the FDOs will decide—and whatever else is going on in the mission—whether
or not a maneuver is worthwhile. If it’s cheap to do, you got
the consumables, maybe they’ll move, but it’s all a probability
distribution. When you move, you’re always going to make a maneuver
that’s going to reduce the potential for conjunction. That’s
the debris avoidance stuff that the DoD and MOD does.
Does that happen on a regular basis? Are there any missions you can
Oh, it’s all the time for Station, because the Station is up
there all the time. Its trajectory is moving up and down. It decays.
It gets lower and lower and lower over the months, and then you have
to push it back up again. Now when we launch a Shuttle to the Station,
you want it as low as possible because it takes less energy for the
Shuttle to get there. So those plans are done over long periods of
time. Then as soon as the Shuttle is gone—or sometimes if Shuttle
has extra fuel, it’ll push it up a little bit. Then it can come
down. Then usually one of the Russian FGBs [Functional Cargo Block]
or one of their Protons or whatever—those have fuel, and they
will run it up to a higher orbit. Then it decays again, but that’s
Now when the Shuttle launches, they have constraints, one of which
is meteor showers. You don’t launch during that period of time
in the year when you have the—is it the Perseids or something
like that? I think it’s November. There’s a meteor shower
that comes once a year. We typically avoid launching in there if we
can, but it depends on the other circumstances as well.
So that’s debris avoidance. Once the Shuttle is launched, and
you know exactly what its trajectory is or what it’s projected
to be, then the Air Force’ll run their conjunction analysis.
Any time you make another maneuver, you run another conjunction analysis
because now you’ve changed the conditions. That goes on as long
as the Shuttle is in flight.
Do you remember any instances?
Oh, there have been conjunctions, yes. There’ve been maneuvers.
I don’t remember a specific one, but you could go back and ask
if you are interested in specific ones, ask the Flight Director Office.
Probably they can go back. All of them that were done on a flight,
that’s been recorded in the logs.
What about working with some of the other federal agencies or Centers?
You tend to work with Goddard [Space Flight Center, Greenbelt, Maryland]
all the time, because Goddard has the network and the TDRSS [Tracking
and Data Relay Satellite System] network, so we always work with them.
Their network director comes down and is part of the Flight Readiness
Review [FRR] process, says, “The network is ready.” Which
includes the TDRSS and White Sands [Test Facility, Las Cruces, New
Mexico] and MILA [Merritt Island Spaceflight Tracking and Data Network
Stations] and a few other sites around that are still there and functioning.
Marshall we work with all the time, because they own the ET [External
Tank] and the SRBs [Solid Rocket Boosters] and the Main Engines and
so those, the values that have to do with propellants and engine performance
and SRB performance comes from Marshall. That’s done all the
And they also did a lot of payload ops. So on a flight-by-flight basis,
you work with Marshall a lot. On top of that, in case we have a hurricane
here, you can go to Marshall and use some of their facilities. Mostly
with Shuttle, though, you go to the Cape I think, if I remember. Now
things have changed, it’s been three years since I’ve
been there. So it depends on which of those two programs you’re
I think the Marshall thing is mostly a Station thing for emergencies.
I think we still go to the Cape if we have a hurricane here when the
Shuttle is on orbit, and you’re going to enter. Shuttle can’t
stay up—well, if it’s attached to Station, it’s
got a long period of time. Hurricane will come and go, you hope the
place doesn’t get wrecked up too bad. Once Shuttle is free,
it doesn’t have enough—some of the onboard systems like
IMUs [Inertial Measurement Units] degrade over time. They drift. Unless
you have some independent means of tracking all that, they’ll
get to the point where they can’t guarantee entry. Typically,
if you don’t have that capability to do those drift tracking,
which you typically don’t have in an emergency situation, we
just take up a few laptops and go to the Cape.
All this is documented in an emergency Mission Control Center plan,
but you have to come back pretty soon. So for Shuttle it’s the
Cape. Now other Centers, if they have payloads, like Ames [Research
Center, Moffett Field, California] will have a payload, then we’ll
work with them on that particular payload. Other agencies of the government,
Homeland Security now, FAA [Federal Aviation Administration]. If you
have to land, there’s some east coast landing sites; you work
with them on an off-and-on basis. Let them know that there might be
It’s typically a black zone situation, very unusual, but it’s
one where you can’t make a TAL [Transatlantic Abort Landing
site] because an engine has quit or something like that. Now there’s
some east coast landing sites that you could come screaming in as
they say, and you’re gliding. There’s no go-around, so
it’s one of those where you say, “Clear the runways, clear
the runways, clear the runways,” to run everybody off and you
hope you make it. Or you bail out.
Let’s see. Goddard, Marshall. KSC you work with a lot for the
range safety, and of course then they are responsible for the recovery.
Once a vehicle has landed, they have to get it back, whether it’s
Moron [Spain] or someplace like that. So you’re always working
with KSC in the normal end of mission. Most of it is fairly standard
stuff. Things have evolved over time. … It was intended to.
Does that help?
Yes. One of the things that you mentioned in the chapter that I thought
was interesting that I was hoping you could give some examples, you
talked about payloads and resource conflict. Could you give some examples
from some missions?
Well, we flew a mission called SIR [Shuttle Imaging Radar], and that
mission used some DoD stuff, but it was a radar mapping mission. That
kind of mission, first of all they wanted to go to a higher launch
azimuth so you’d get more of the United States. The most efficient
launch out of KSC is to launch due east, because when you launch due
east, you get maximum advantage of the Earth’s rotation. At
the Equator it’s about 1,000 miles an hour. The higher up you
go, it drops off generally. I think it’s by the cosine of the
angle or something like that. Then the more northerly you launch,
the less you have advantage of that velocity. You lose payload capability,
launch mass capability, the more you launch north.
Putting the Station up—the reason it’s at the launch azimuth
and the angle that it is to the Equator is because of the Russians.
Their due east launch site is much more northerly than our due east.
It’s 51.7 degrees, and that’s where their launch site
is. For them to get a maximum capability for their launch vehicles,
they want to launch due east, but that means that you can’t
have an angle of inclination to the Equator that is lower that would
help us. So that’s why it’s where it is.
Well, SIR was another one, and it wanted to look at a lot more of
the US and a lot more of North America. It had to launch more northerly,
because it was a radar scanning mission and it was in the payload
bay. You had to have the payload bay to the Earth. If you had another
payload that wanted to say look at the Sun, you were out of luck.
That’s a trajectory conflict. Also it’s a mass properties
conflict. Those are the kind of conflicts that you have. It means
you can’t mix certain types of payloads, or you can’t
mix them easily.
I’ll go back to Skylab for a minute because it had similar types
of conflicts. Skylab had biomedical [experiments]. It had about four
major areas for science. Solar physics, which means you want to point
at the Sun. That means you want to have a vehicle that when it’s
not blocked by the Earth, it’s always pointing at the Sun, so
it’s inertially Sun-oriented. You had a biomedical [investigator]
which said, “I don’t care where I’m pointing, but
I want time for the crew.” You had Earth resources, which meant
you wanted to point at the Earth. That’s not an inertial thing.
That means you’re constantly pointing along a vector to the
Earth, which means the vehicle has to rotate all the time. That conflicts
with the solar physics. It also conflicts with getting energy from
the Sun, because on Skylab the solar arrays did not rotate like they
do on Station. That meant that if you’re going to point to the
Earth all the time, then the solar arrays don’t point to the
Sun nearly as often. The batteries run down. Then the fourth thing
was called corollaries, which is whatever else you can fit in.
Skylab was a constant balancing of all these priorities, as well as
you [have] got to keep the batteries charged. That’s the physics
of keeping the vehicle going. Since you’re up there for a longer
time [on Skylab], you could finally balance all these things out.
Now you get to Shuttle. Shuttle is a little less time on orbit, but
when you have payloads that are like that, you have the conflicts,
and you can’t put certain payloads together.
The other conflict is crew time. How much time you could have individual
crewmen or crew people devoted to working your experiment. They have
to sleep, they have to eat, they have to do their exercises. Then
whatever eight hours or so is left over can be devoted to somebody’s
experiment. How much is that? Some of those experiments, they want
them to take pictures, they want them to narrate, they want them to
react to given phenomena. That takes crew time. The more of those
things you have, the more you have to split. Now the Spacelab missions
were a lot like that. You pile a bunch of experiments in there, and
then somebody has to integrate them so that everybody gets an appropriate
amount of time, because it’s very expensive to launch a Shuttle,
no matter how much you work on it.
You’d like to get as much out of a flight as you can. You had
contingencies, so that if this fails then you can move this in here.
It was a constant replanning activity going on during a flight. If
something failed, you had to do in-flight maintenance. You had one
thing or another. You had to adjust things. Or the ground people said,
“I can’t make it.” Or they had a failure or something
like that. You could try to adjust these things. There’s a constant
tweak of the plan going on just to maximize return.
When you were building a mission from the beginning, then the program
office—and I said in here—the program office mostly, because
they were looking out way [beyond one flight]. The Shuttle Program
funded some of these experiments. They were years in the making. University
XYZ or commercial McDonnell Douglas or something like that says, “We
want to do this kind of experiment. We think we can build the hardware,
test it, and have it ready four five years down the road.” So
they would put that tentatively on a flight. Then you would gather
things up that would be more or less compatible with crew time and
the trajectory requirements and whatever your major payloads were.
Does that help?
That’s great. I think the example of Skylab is perfect.
In the Shuttle world it has to fit into those sets of Shuttle constraints.
Generally you might have one or two driving payloads. These are the
ones that force the trajectory. They needed solar, they needed lighting
at this point in time, they needed this or that. That drove the trajectory.
Then you had a lot of stuff that you could add into that. The Spacelab
flights, the ones that Marshall had, where you had an internal Spacelab
module, they typically were filled with a lot of biomedical stuff,
stuff with animals, stuff with flame propagation, some chemical reactions.
It didn’t matter what orbit you were in, you just wanted a weightless
Talk to us about how the flight control team worked on trajectory
planning for launch and for landing. How does that work?
The trajectory flight control team did all of that. The systems flight
control team, payload ops, EVA [Extravehicular Activity], Robotics
had almost nothing to do with that. Over the years, the trajectory
team evolved and had a very rigorous rigid process to go through,
because if you screw up, you don’t have a chance to recover
for a launch phase or entry phase. It’s just too late, if you
make a big mistake. Typically early on they had what they called an
engineering release, and then they had a final release in the early
part of the program. That would be about three or four years’
worth of effort. It wasn’t necessarily a lot of people but once
you got this you iterate on it, because there’s a lot of iteration.
There was the control points of the Shuttle where you had to control
the temperatures. There was the load numbers during the launch phase,
because it’s an asymmetric launch vehicle.
You have the winds in the year. Marshall ran a bunch of studies real
early on to define what the upper atmosphere winds were. They’re
seasonal winds. I don’t know if they were done on a monthly
or a quarterly basis, but you have spring, summer, fall, winter environments,
and you had a set of trajectory preliminary loads that were tailored
to those environments. In the later part of the Shuttle Program what
we have, and we have it today, is day of launch winds. You have a
preliminary set of trajectory parameters, and then in order to maximize
your margins you have a day of launch wind. So they release some balloons
and track those balloons, and then that’ll tell you what those
upper level winds are, and then you factor those into the last minute
set of constants or I-loads that are put on the vehicle on the day
There were people that ran ascents, people that ran orbit [analyses]
and people that ran entry [analyses]. They would get a flight and
define, “I got an Orbiter,” probably don’t have
necessarily the engines you’re going to fly with, and you certainly
don’t have the SRB datasets yet. You work a set of preliminary
trajectories. They will include aborts to RTLS [Return to Launch Site]
aborts. They’ll include Transatlantic Landing site aborts. They’ll
include abort once around trajectories.
They set them up, and then they do what they call a Monte Carlo analysis
where they will have a bunch of variables. Then they will change the
variables and make a bunch of runs and change the variables and make
a bunch of runs. Those are trajectory runs that are against a set
of criteria. Then what you’re looking for is what they call
two or three sigma margins relative to hard lines that you do not
violate: “Do not exceed this.” Those, you really probably
talk to a trajectory guy if you really want to get more detail. I’m
giving you the layman’s view.
There’s also other things. They’re trying to maximize
performance, which is get the most out of the propellant that you
have, and get the maximum amount of payload or mass that you can launch.
It’s a constant iterative process to maximize performance. That’s
part of the reason that it’s expensive, because you don’t
do it like commercial airliners. Commercial airliners, they’re
driven by a different metric. Also the FAA defines margins. You just
don’t go outside those margins. An airline says, “Okay,
I’m going to take off from [William P.] Hobby [Airport, Houston,
Texas] and I’m going to Dallas [Texas] or something. Or let’s
say further way. I’m going to Indianapolis [Indiana].”
Now, the FAA says you have to be able to go to Indianapolis and then
have the ability to divert to another airport within a certain circle
and have enough fuel to do that and loiter for so long. That’s
to protect the public [and] the passengers. So that can define a minimum
Now then the economics of the situation will define for the airline,
like Southwest, what else it wants to do, because okay, I want to
go from Indianapolis to Detroit. Well, it may be better to load a
little more here in Houston and load less there, because they only
want to spend 15 minutes in Indianapolis. Then the economics takes
over, but their structural margins and all that, those are defined
by the FAA, “Do not exceed,” etc.
We optimize every single Shuttle flight. You optimize it for performance,
which is max payload to orbit. You optimize it for structural margins,
three sigma variance of the variables that can happen like the winds
and the errors, things that can happen because of the IMUs have potential
errors in there, those kind of things.
Once you’ve built the software, it’s going to do what
it’s going to do. It has no errors. If you have a bug in it
that’s inherent, then it’s there, but in and of itself
it’s going to execute on whatever data comes in. The data that’s
coming in from its rate gyros or its IMUs or whatever, that’s
where errors might occur. There’s variation in those things.
All that is done on a statistical basis. Those other errors and the
unknowns from the outside, like winds that are different from what
you thought, those introduce load errors and things like that. All
that is part of this Monte Carlo analysis that’s done. Software
is just going to execute and do what it’s told to do.
If you screwed up, you put a bad load in, well, yes, you’re
screwed—probably. In fact, that’s how some of the launch
ascent training is done, they put bad errors into the actual flight
software. Otherwise they can’t get anything to go off to the
side one way or another. That’s the ascent case. They have all
The on orbit is typically [where] you’ll have rendezvous. So
where is your rendezvous point? What if you had a bad burn, what if
you had a failure of a jet, or an OMS [Orbital Maneuvering System]
went out? You can rework trajectories for that. Then they constantly
optimize to maximize fuel use, maximize margins in case something
else goes wrong.
Entry, you got a capability to enter almost any time. Not quite. So
every day the FDO generates potential entry points in case some systems
problem causes you to have to quit right now. You have a hole in the
cabin, you have a debris impact, meteoroid, or whatever. So those
are done. That’s not so much the prelaunch stuff, but that’s
done every day. On the prelaunch planning, then the entry is a planned
entry. The program office used to have objectives, like crosswind
landing objectives. Sometimes you’ll have more crosswinds at
a given time of the year than others. They’ll put that factor
into the equation. They also will plan entries in case you had a deployable
payload you could not deploy. You have to enter with more propulsion
mass than you had planned on. Those are variables that go into the
entry trajectory planning.
You asked a question in here. After [the STS]-107 [accident], they
decided in case we have another one of these things not [to] have
all that debris that fell over Texas. They tend to try to plan the
entry profile—it’s called an ascending node, which means
that you come across Mexico. As you’re getting lower you’re
coming across the Gulf, so the debris path now falls in the water,
and then you land at KSC. That limits some of your options. You can
go the other way, you can have a descending node, but that puts you
across the entire US just like 107 was.
Now 107 was not a flight to the Station, because that would have put
you in a higher inclination. That was just a due east launch. So that’s
why it followed the path it had. Had it been a Station flight, and
they came across the US, it would have been quite a bit higher. Or
if it was coming in from the bottom, it’d have been lower down.
So after , they put that factor into the equation of entries
so that you can avoid population areas.
Do you want to talk about how the flight control team works on things
like cargo operations, maneuver plans, consumables, any of those things?
Typically maneuver plans are a combination of the prelaunch trajectory
work and the propulsion guys. Propulsion guys and their systems people,
they track the consumables usage. You had a question in here: the
preflight work, the trajectory work. There’s also other work,
one of which is consumables. The consumables typically is water loads,
cryogenic loads, propulsion loads. I think you said something about
CO2. CO2 is something that is generated by the crew, and then lithium
hydroxide is what takes it out, if you’re using the canisters.
They had another thing called the regenerative CO2 removal system
that we used a couple times. It adsorbs CO2 to a bed, and then you
heat it and expose that bed to vacuum on a cycle, and it pushes the
CO2 out. Then you put it back into the cabin, and it adsorbs CO2 again.
So you had two beds working like that I think.
There’s always a tradeoff on that kind of thing. The weight
of that regenerable package was typically a little more than the weight
of the canisters for a typical Orbiter flight, which was typically
seven days. Now it’s gone longer. Those tradeoffs were made
way back in the early part of the Shuttle Program. Those canisters
are consumables. You load as many as you think you need plus spares.
Let’s see. The water—for drinking and waste management;
the cryo, for electricity. We don’t typically load too much
of that, because you generate water with the cryogenics. What other?
Propulsion. Got the forward RCS [Reaction Control] system, got the
aft RCS system, the two OMS pods, and that’s a lot of propellant
as it turns out. Then APU [Auxiliary Power Unit] fuel and APU water.
Those sometimes were managed for mass properties considerations, and
then there’s a CG [Center of Gravity] control, and you can load
ballast in the aft compartment again depending upon the flight as
to where that CG will vary. There’s a box, and it has to be
in the box or you don’t have good control during entry. Not
a launch problem typically, just mass you add or subtract.
People know, “Here’s what the flight is, here’s
the duration, here’s the users of electricity,” so you
generate how much cryo you need. Then the mass properties guys are
saying take it off. We’d say, “Well, EECOMs [Emergency,
Environmental, and Consumables Operations Manager] want as large of
them as you can have.” It’s a balancing act that’s
done preflight. Then tell KSC what to load at the last month or so.
Then they’ll load and go. Load up when it’s on the pad.
They generate how much ET load. That’s loaded up of course day
[of] launch, or the launch process. There’s also a payload safety
process that MOD runs. There’s a whole set of safety criteria
that is put on the payload providers. It would have to do with [something]
as simple as sharp edges, anything, what are you doing that might
be toxic, offgassing, shock, heat, temperature, those kind of things.
They just go through that process and say what it is and evaluate
what crew protections need to be in place.
There’s also some integration, especially later in the Shuttle
Program when you could have all these digital cameras and laptops.
Everybody’s got to have a laptop, maybe multiple laptops. All
those things require power, and so you got to find places to plug
them in. So you’ll end up with conflicts there. There’s
not enough plugs in the wall, so to speak, or downstairs or upstairs.
So you put a plan together called a plug-in plan for that. Day one
this way, day two it’s this way, day three. You like to minimize
the plugs and unplugs if you can. You optimize that way as well. All
that is done preflight.
What about planning for rendezvous and docking?
The thing we rendezvous with—if we’re going to retrieve
something or go to Hubble [Space Telescope] or Station, you’ve
got to know where they are. Somebody tells you, the Station guys,
“We will be at this place at this point in time.” That
helps define the launch time. The launch windows [are set up] to minimize
rendezvous time and rendezvous propellant. See, if you had plenty
of energy, plenty of propellant, plenty of delta-v, a lot of these
problems go away, but you don’t. That’s why you optimize.
That’s why we have a launch window of about five minutes. Five
to eight minutes is your launch window, like tomorrow morning. If
you don’t get launched, you could launch a little bit later
than that, but it means it takes you four days to get there instead
of two days or three days. You don’t want to spend that time.
You don’t have enough propellant, you don’t want to use
it to just burn.
If you look in the early days, we could do one-day rendezvous if you
had the propellant to do it. We just don’t. At the Moon when
we did the Apollo, we launched off the Moon, we rendezvoused [in]
one rev. Those are considerations that go into it. Now, when you try
to do that, you don’t have much margin. One-day one-rev rendezvous,
everything’s got to click. If something goes wrong and you’re
off, you either got to have a lot of propellant to make up the difference,
or you’re going to spend a lot of time catching up. You can
do it, it’s just time and optimization of flight plan.
What about docking?
The Apollo docking, the Skylab docking. Those were designed in, so
they were always axial docking. The Russians are the same way. You’re
docking along the axis that includes the center of gravity. That’s
pretty much a piece of cake, [relatively speaking], or it reduces
the variables. Now all you’re really concerned about is how
much structural impact there is. That tells you what the impact velocity
needs to be. Typically it’s low. You want it to be as low as
possible, but you also want to hit strongly enough to engage the latches.
It depends. Again, that’s a design issue. You can do it in different
If you did, say, very strong magnetic latches, you could come up extremely
slow, but the slower you go, the more variation there is, because
you’re going along in space. You’re going along at five
miles a second in the low Earth orbit. Well, the further you go, the
more these two vehicles are varying, because their orbits are always
slightly different until they contact.
The way the Russians have it, it’s along the axis of the CG.
The Shuttle was never designed for this kind of work. So their CG
is offset. The docking module is typically right behind—especially
if you’ve got other payloads—the crew module. That means
it’s offset from the CG by quite a bit, relatively speaking.
Working off all the software and the maneuvers to do the actual docking
took a while to do. [The Charles Stark] Draper Labs [Cambridge, Massachusetts]
did the work for the digital autopilot. The actual maneuver, you come
up and then you have to burn these jets in a certain order right at
the last minute to clunk them together with the minimum offset loads.
It was a tricky kind of a thing. It’s a result of trying to
use something for what it was not really intended to do. There’s
other constraints having to do with the jet plumes and the solar arrays
[they] are impacting, all of which is a very complex kind of a thing.
So it was trying to make two things do stuff together that were not
optimized and designed to do them. We forced the use of Shuttle, so
to speak, on this thing. The Shuttle is a unique beast in that. When
Shuttle goes away, whatever you design thereafter can be optimized
for that. The Orion is much more like the Apollo Command Module. It’s
going to be docking along its CG axis pretty much. You can adjust
the jets to account for that.
What about working on EVA plans? How far out does that happen?
Of course they always want to know as soon as they can, because EVA
is typically a choreographed activity. If you have to make any models
and whatnot to put in the NBL, then you want some lead time on that,
again for scheduling purposes, procuring equipment, and procuring
materials. The longer you have, the more you can optimize for cost.
So of course, where you are now, you know you’re going to Station.
That’s the last part of Shuttle you’re doing. It’s
all you’ve got left to do, and it’s been going on for
years now. You know there’s going to be EVAs to install the
stuff and connect it up and whatnot.
A lot of that is canned now. You know where the handholds are, but
when you’re doing something new that you hadn’t done before,
what you do is you go look at the payload. What am I going to do with
it? Where can I install handholds to make this easiest for the crew,
give the most leverage? All those things are part of it. Now the other
thing is you’re always dealing with different crewmen. You’re
training new people in many cases. You were in the older days. That’s
all part of it, why you want to know as soon as possible.
Now there was resistance on the part of the Flight Crew [Operations
Directorate] and especially George Abbey when he was running the show
to name a crew. Because once you have named a crew, you’ve put
things in place that you take them out of the PAO [Public Affairs
Office] rotation, the PR [Public Relations] rotation. They’re
now focused entirely on that flight. They are locked in, and other
people know they’re not. So there’s a certain amount of
things going. You’ve read the books on that. I’m not telling
you anything you don’t know, but Abbey would delay as long as
possible for those reasons.
You’ve excluded a bunch of people, and you’ve also focused
in on people. So they had an EVA cadre. Sometimes early on, a lot
of it was just paper exercises. Once you get a named crew, then you
can go through the actual practicing this. “We’ve got
a paper choreography. Let’s now go through it in the NBL.”
Robotics was somewhat similar, because they need to know if you’re
going to take something out of the bay, or you’re going to capture
something, where’s the CG. Has to do with what the arm can do
and not do, what its restrictions are, what your margins are. Hubble
was designed for capture and EVA. It was designed to be deployed with
an arm. Early on they’d say, “Okay, put a grapple fixture
here or here. Gives us our best CG capability, gives our maximum margin
getting it out of the bay without banging around or anything. Capturing
it. Putting it down. Getting crewmen available where the handholds
[are], so you can open doors.” All that was optimized on Hubble,
but you had to get started at the early design phases of Hubble. You
have to define what your payload is and what you want to do with it,
and then you can assign somebody to start working on it.
Let’s talk about training. Move from the planning to training.
Talk about the flight certification that flight controllers had to
participate in for the Shuttle Program.
Certification typically was not necessarily programmed. It was how
does the operator operate, but you had to understand your systems.
So that became Shuttle-oriented. Certification was a written evaluation
that said, “This person understands their systems, they can
communicate effectively, they can recognize and evaluate problems
in telemetry signatures and perform in a way that gives us confidence
they can do the job in a real situation.” So people over time
defined problems they wanted [to see]. If you were a propulsion person,
they wrote down [for example], “We want them to see an OMS failure.”
They want them to see an RCS leak. They want to see a failure of this
valve or a failure of that valve. So they defined a whole bunch of
those. That became fodder for the training people to build scenarios.
It was fairly expensive to do training with the best trainer, which
was the SMS (Shuttle Mission Simulator). When you did team training,
you couldn’t put too many failures in, because it blew the sim
[simulation] out of the water. You did a few, and you’d optimize
those for who you were particularly trying to get certified on this
particular run. There were a lot of part task trainers. There was
a lot of what’s called tribal knowledge extraction or on-the-job
training. So you get a new person in the systems world or the trajectory
world, and they were assigned to a discipline like EECOM or the EGILs
[Electrical Generation and Illumination], the power guys, or the PROP
[Propulsion] guys, or GNC [Guidance, Navigation, and Controls Systems]
or somebody else or Robotics, EVA. They got in the group. Then they
learned by doing and learned by watching and learned by participating.
They would go in and they’d sit beside a certified flight controller
during a flight, during a sim. Then they would go on their part task
trainers and just work on their particular areas and learn how it
looked from the crew’s perspective. What happened if you did
this? What happened if you did that? They were assigned systems handbook
drawings. They were assigned console handbooks procedures. It was
a lot of learn by doing, learn by observing, learn by doing. Then
they’d be given a little more responsibility. Write a flight
rule for this. Then work with an expert person. Then they’d
typically start out on orbit. There were three basic phases for Shuttle:
launch, orbit, entry. Two critical ones were launch and entry, because
once you were embarked on those there was no turning back. You couldn’t
back out of it and you didn’t have a lot of time. So if something
went wrong, you had to respond immediately or the system responded
and you went from there.
On orbit you can say, “Well, okay, we’ll turn it off and
think about this.” The MER [Mission Evaluation Room] was there,
and the MMT [Mission Management Team] wanted to have a say. You safe
the system, but you had time often then to wait and bring in more
expertise. Ascent and entry you did not. Once you were there, you
were there. So you’d start off typically in the MPSR [Multipurpose
Support Room], which is the back room position. You’d train.
You’d be assigned to a flight. Well, sometimes you were assigned
a flight before you were fully certified, but you’ve had some
practice runs. You’ve sat in with some people. You’ve
run on another mission a sim or two or something like that.
Your supervisor says you’re okay. You’ve had evaluations
by the sim people on your performance during a sim. You’ve demonstrated
to your management that you have some modicum of knowledge of the
flight rules and the procedures for your systems and the console procedures.
So they’ll assign you to a sim. Then you go execute the sim.
Then you’ll be evaluated. Then you go do another one, you go
do another one. Then you’ll say, “I’m ready to be
certified,” and you’ll tell the training people that.
So-and-so, this is a cert [certification] run for him or her. Then
they will tune that sim up to exercise these guys in a number of ways.
So you might have one or two of those. Then if you get evaluated by
your supervisor and your sim guy for the back room, and maybe somebody
else, and they’ll write that down. They’ll certify you,
and they’ll write a piece of paper, and you’re certified
now for that phase and for that system.
Then you move on and you move up. Sometimes you can move from a MPSR
orbit to an orbit FCR [Flight Control Room].
What’s a MPSR?
Multipurpose support room. It’s called the back room. In the
Apollo days, it was called the SSR, System Support Room. Now it’s
called the Multipurpose Support Room. There’s some more history
with that, but that’s not worked out the way it was thought
it might work out. The FCR is the Flight Control Room, that so-called
front room. So you can go from orbit MPSR to orbit FCR. Or you might
go from orbit MPSR to ascent entry MPSR. Just depends on the circumstances.
You typically start there, and then you’ll move out to the equivalent.
Some people decide they don’t want to do that, or can’t
do that, or they can’t take the pressure, or don’t need
to, don’t want to. So they just stay orbit. That’s what
they want to do.
Payload, similar kind of a thing, except they typically don’t
have an ascent or entry role. FDOs, the trajectory, similar kind of
a thing. Back room to the front room. They’ll do back room certification,
front room certification. When you’re certified for the FCR,
the front room, you also have again sim supervisor and a flight director.
How long does it take normally to get certified?
It varies a lot. It varies for a lot of reasons. Some of it is just
personal problems. Some of it is is there enough sim time around to
get them. Because ascent entry sims, for those, because of the rapidity
of response capability, you can’t just have sim and then wait
a month, another sim and wait a month, and then have a cert. You just
lose your proficiency. For an ascent entry certification, you usually
need to have at least a sim a week for two or three weeks before you
have your cert sim, or maybe two sims a week. Sometimes those are
hard to come by, [depending on] what flights are running and how close
they are. It can take a while. A really proficient guy, just bang
bang bang you hit them, you might get it done in a year and a half
from the time you started into the process and maybe you spent six
months or more there, but that was real rare. John [P.] Shannon may
have been one of the real fast ones.
A lot of it is just due to circumstance. Rick [Richard N.] Fitts wrote
up a presentation of that many years ago when Bonnie [J.] Dunbar was
assigned to MOD, and we went through that with her because they said,
“Why is it taking so long?” A lot of it was just circumstance,
availability of slots, finding enough sims where you could do cert
sims, because you were trying to use flight-specific sims to certify
somebody for another flight. So it was awkward. We didn’t have
a purely independent certification process. It was integrated in with
flight support. There’s a template, but there’s not an
absolute time. You could always force things if you wanted to, but
then you had to give up something to make that happen or cause people
to do more work.
When did flight control teams start training for a mission? Was that
well after the crew had been selected?
Pretty much. The crew had to be named, and then you could start into
it. Usually the template would typically start with when’s launch
day. Then you backed up from that. There was a lot of pressure over
the years to reduce cost. Reducing cost meant you tried to make the
template shorter, because remember, I was telling you about how these
costs worked out. You had time going that way and so you had mission,
mission, mission, mission. [Demonstrates] Then preparation for this
mission might take this long.
For this mission you started back here. Maybe the crew was named there,
then flight controllers. I was running Systems Division. We tried
to let people know what’s your life like. So for a couple years
we’d like to name teams a couple years in advance. Didn’t
mean that’s exactly how it was going to come out, because who
knows? People might get hurt or die or go off to a career change or
whatever. You could lose some people. Nevertheless, you had these
things going on.
If you take just a particular slice in time I might have one, two,
three, four flights in flow. Simulations had to be account for that.
Now I think my recollection is—again I’m three years out
of date—you typically start integrated sims about six months
prior to launch day or whatever you knew that launch day was at that
time. That could slip, as we all know. Things slip for one reason
There’s constant iteration of these things. Typically a flight
director said, “Who’s my prime team?” That’s
his team. A lead flight director typically is an orbit guy, because
that’s what I’m going to do on this flight. Then you have
an ascent entry flight director. You have fewer of those. They might
just do the ascent and the entry, and then you’ll have three
other flight directors do the orbit stuff. If a flight was long enough,
you might have four teams because we had these work limitations. So
many days in a row. That was driven by incidents, like 51L was an
incident. We had another incident where somebody put a bad vector
up, caused the vehicle to start going out of control.
We did those kind of things. Once a flight exceeded like 12 days,
they would have a fourth team. That makes it awkward scheduling, because
to me once I got on a shift, like if I had the dayshift or the mid-shift
or the nightshift, I liked to stay there. Because your sleep cycles
and your work—if you get off of that, try to come back, I don’t
know, for me it was not very good.
… What aspects of the flight did you typically work most frequently?
Ascent and entry, or orbit, EVAs?
Me personally or people?
Just the flight teams in general.
Typically ascent/entry is going to get more sims, both standalone
crew and flight team, because they’re critical phases. The timing
is critical, and you want to get those pretty well down pat. Orbit
sims, what do you pick? Well, you pick a critical phase, so if there’s
a deployable you probably pick the deploy, and that’s about
all you do. If there’s a Spacelab, you want to integrate Marshall
in there. You pick a day that had enough stuff in it to keep them
all going. You do a rendezvous and the rendezvous docking. You do
an EVA or two or three.
You’d involve the NBL sometimes. For the trajectory guys, when
you’re doing an EVA, what do they care? They’re just boring
holes in the sky. They won’t have a lot of participation, or
they’ll do emergency deorbit kind of playing around with, because
they’ve got separate computers and they can go run those kind
Booster won’t participate in any of those. Robotics may or may
not. Depends on whether they have anything going on that EVA. Usually
the systems guys are all going to be there mostly thumb-twiddling.
Payload maybe, maybe not. Flight activities, yes. So you have those
focused. They were doing something. They would do FDO booster sims
where only FDO and Booster was there for launches. Those maybe you’d
have a crew, maybe not.
So again, over the years we modified things to try to optimize training
and minimize the amount of standing around that you had to do. It’s
constantly going on.
Were there any simulations done with Launch Control?
With the Cape? I don’t have a lot of recollection of that. Apollo
used to have a little more. There was a trainer at the Cape; the crew
would go down to the Cape, and then we’d have some integrated
sims, but generally it wasn’t with Launch Control. I think they
do some paper sims, and they do a lot of talking. But it’s just
too expensive. KSC has their own training capability. Early on I think
they didn’t have much of that. They said, “Hey, we do
enough work just with the vehicles itself. That’s all we need
Over time they did institute some capability. In fact, it led to a
couple problems. If you’re not careful what you’re doing,
and it has to do with how you set things up. They have a thing called
Shuttle Data Center. That’s where all their data is established.
They’ll ship out their downloads that go to their computers
in the Launch Control Center. They also do some sim stuff from there.
They had four Launch Control Centers, and they have certain places
where you can send commands out and it’s supposed to go over
to the Shuttle Data Center, but it can also go to real stuff. If somebody
is not paying attention to that, you can think you’re sending
stuff here, but it’s going there. They had an incident down
there one time. They were going to do a sim, then it got postponed,
they were doing something else, shift change happened, and they came
back on. They started to do the sim, but they hadn’t moved the
command path. So these guys were doing the sim and they were sending
out commands, and there was somebody walking over in the VAB [Vehicle
Assembly Building] and they heard this click click click click click
around one of the Solid [Rocket Boosters].
Well, that was ordnance. Fortunately, it was unhooked. “But
what’s going on here?” They went back and traced it back,
and they had not made the switch. There’s manual interventions
that you do for convenience purposes to give you flexibility. If you’re
not really careful with your procedures, and you do shift changes,
and you’re not communicating, you can end up with a real bad
situation when you have real stuff down there. We don’t have
that so much here.
Our system is connected. The sim guys can go in and log into the flight
side. In fact, they use that for simulations sometimes where they
can modify our calibration curves and force things to look like—they
had cases where they have logged into the real flight thinking they
were doing a sim, because we can do sims and flight simultaneously.
I think this was probably on Station, but somebody went in and modified
a cal situation on the Station with the real [time operations]. Fortunately
a flight controller says, “Something’s funny here.”
He knew something was wrong. They tracked that back down, too.
With a real flexible system like that, you have to have well-trained
people. So we tried to put in place some things that says, “You’re
in the wrong place,” by color, something like that. We participate
in countdown demonstration tests, sometimes do, sometimes don’t.
That’s when the crew is on the vehicle. We’ll go through
a countdown demo, send commands and do some [monitoring].
Let’s talk about the flying portion. How does MOD determine
that it’s ready to go for flight?
We have a Flight Readiness Review about a month before flight. That’s
our internal MOD Flight Readiness Review, and says either everything
is already ready or there’s still a few things [yet to do].
Like remember the day of launch I-loads? That doesn’t happen
until later in the game. So those don’t get put in. “We
got these processes in place, and we got this work yet to do, and
it’s scheduled,” and [etc]. Goddard guy comes down, “We’re
ready to fly. TDRSS is going to be ready,” [etc]. We say, “We’re
all ready, this work left to do.” That’s our readiness
statement. “Flight controllers are certified or will be certified
by this date.”
The MOD flight directors take that [to the] FRR down at the Cape,
go down there and say, “Okay, this has been done, this has been
done, this is left to do, we’re ready to go.” Everybody
comes forward and says, “All the things that we’re responsible
for—the flight data file is ready, the ground procedures are
ready, the software is ready, it’s locked up,” whatever
they’re responsible for they say is ready right now or will
be ready on launch day or a week before launch day.
Tell us about the launch phase at the Mission Control Center in those
eight and a half minutes as the crew goes from the pad into Earth
Of course KSC is responsible until SRB ignition. So we’re monitoring
and following, and flight director is talking to the launch director
or is available. He’s polled and says, “Is MCC ready?”
They have hold points. They have a something like—is it 20 minutes?
I forget. Something like a 20-minute hold point. Then there’s
another one at five minutes before they started the APUs. Once you’ve
started the APUs, you’re using that fuel. Once you get down
to that point, if you have to abort—you’ve got a window
because the APU fuel only lasts so long, because it’s got to
go through orbit, and it’s got to be there for entry. So you
have a short thing there. You better be ready to go.
I think when they come out of that 20-minute hold, the launch director
is going around. “Is everybody ready?” He calls every
position including MCC. Then the flight director polls his people.
“Is everybody ready? Yes, yes, yes.” Then they say, “Go.”
They come out of that 20-minute hold. Then the APUs get started at
five minutes. So they click click click [through their processes]
and there’s a whole bunch of other stuff that’s going
on at the Cape. I’m not familiar with that, but they’re
topping off the ET and doing whatever they do. The Orbiter goes on
internal power before APUs start. It goes on internal cooling just
after. [Actually], I’m a little fuzzy on whether it’s
before or after APUs start. So you have this rising tension, I’ll
put it that way.
Do you want to take a break for a second?
Well, I’m trying to remember here. Let’s see. The IMUs
are freed up, and onboard GPCs get control, and there’s a launch
sequencer. It’s a GPC thing. It just goes down and counts. It’s
five minutes or so, and they have this other potential place to stop,
and if no then the crew starts the APUs. The vent doors shut. It’s
four and a half seconds or something like that. The Main Engines start.
It’s all automatic. I think they come up to speed, and they
have to pass a bunch of criteria internal to the Main Engine controllers.
It passes all these automated criteria, and then the Solids ignite.
Once the Solids ignite it’s moving. At that point, control is
shifted to Houston in terms of abort calls and whatnot, but everybody’s
still monitoring and watching. So it’s lifted off. Goes through
a roll pretty much right off the pad.
You asked about that. I’m not sure. Originally the way the US
did it, it aligned the launch pads in a certain way. For whatever
reason that’s lost to me, but I think having the launch pads
aligned in a certain geographical thing has to do with—I’m
guessing here—gravity vectors and alignments of IMUs. Because
the way the axes of the IMUs are aligned they’re called [x,
y, and z]. [One of them is pointing] north, one of them is pointing
west, and one of them is pointing up. That allows you to calibrate
Of course the pads were originally all built for Apollo. It was a
symmetrical launch vehicle, going to launch due east. The Shuttle
comes up here, and it’s an ungainly thing, and it can launch
at multiple azimuths. When it comes off the pad it just goes up. Originally,
I’m not sure we had a roll in it. It just went up, tilted, and
went on into orbit. Much later in the Shuttle Program, they wanted
to come off with the Orbiter on top, probably for lighting purposes.
Because when you get up there, if you’re launching in the morning,
and you want to launch in the morning at the Cape because the weather
is better or less likely to have thunderstorms or whatnot, so when
you come off the Sun is nice for photography. Also, the ET falls away
down. If you come off on the bottom, you’ve got to now maneuver
to do your burn. I think it was done to ease or optimize some of the
later on activities.
So you come up. They watch you do the roll. You’re just watching.
The [ground trajectory] computer is taking in the velocities, and
it’s taking in the Main Engine performance, and it’s got
this thing called abort region determinator (ARD), which is a bunch
of software that takes current velocities and current engine performance
as best it knows it, and it’s predicting what if the engines
fail here, where is it going to land. So it’s constantly, as
this thing goes up, plotting potential aborts and telling you what
kind of aborts you can do. That’s a big FDO thing. Most everybody
else is watching. Of course, Booster is watching his engines. How
are they performing? Solids, you’re watching them, but there’s
not much you can do about the Solids. They’re going to do what
they’re going to do. You’re sitting there watching. FDO
is watching all that trajectory and his abort region determinator.
Generally, if you have a Main Engine failure in the first four minutes
or thereabouts, 3:58, four minutes, it’s a Return to Launch
Site, but it’s velocity-driven.
Coming off about a minute up, thereabouts, the engines throttle down.
They throttle down because of these structural limitations that I
mentioned to you before. Even though you’ve got nearly 6 million
pounds of thrust on these two Solids combined, and you’ve got
1 million pounds of thrust on the Main Engines, they’ll throttle
down the Main Engines from 100% down to 60% or something. I guess
this is one of the variables on a given flight. It throttles down
for a short period of time till they get through that max dynamic
pressure, because there’s a limitation of like 800 pounds per
square foot or something like that. They wanted to maximize the margin.
So they throttle down, [and] then [they] throttle back up again.
Now, if one of them doesn’t throttle up, and it just keeps on
burning at 40%, well, you can still make it, but you’re probably
going to be a little short or you have to burn a little longer. There
is consideration for that. So you come up. Now then your big criteria
is your two minutes or thereabouts where the Solids run out. They
start slinging slag and whatnot, and the pressure drops off. They
hopefully will come down at about the same—because if they came
down at significantly differential thrusts, it would start to tilt,
and it may be more than the gimbals can take care of, but they don’t.
I’ll divert. They make Solids in pairs. These pairs need to
be always kept together. They are segmented. Morton Thiokol will mix
up a batch of propellant. Half of it is for this segment, and half
of it goes in this segment: on the right solid, on the left solid.
Then the next segment, they mix up another batch. Half of it goes
in this segment, half of it goes in this segment. You have a matched
pair. Hopefully all the burn time will be the same, and it’ll
be very close to the same thrust.
The Solids go off. Everybody says, “Yay!” Now you’re
on your three Mains. They just keep on burning. Depending on the flight,
there are sometimes during the real late parts of the ascent, I think
they’ll burn some OMS propellant, which helps reach trajectory
a little bit. It varies. Again that’s another optimization activity,
but you just keep on running up. Just maybe 30 seconds or thereabouts
before scheduled MECO [Main Engine Cutoff], they start to throttle
down, because they don’t want to exceed three or 3.3 Gs or something
like that. If you keep the engines at full thrust, because now you’re
getting lighter and lighter and lighter, you would exceed the design
So they throttle down. Then when you reach the velocity cutoff, the
Engines shut off. Then the ground—they’re watching everything
because there’s other things that could go wrong. An APU failure
or a leak in the cabin or some fuel cell or something like that. They
have defined procedures for each one of those. They’re watching
for that kind of stuff. You reach MECO. They do a couple things on;
closing off the Main Engine valves. I think they may move the engine
bells in a certain position. Then they go through APU shutdown. Now
you’re on orbit, more or less. If there’s any trim that
needs to be done, FDO says, “Okay, trim, burn two tenths foot
per second,” or something like that. Then they go through and
[give a] go for orbit ops. Then [the crew]’ll go through and
start doing things like take their helmets off. Then they go and open
the payload bay doors. Then you’re [set up] for on-orbit ops.
Then you can take off your suits. You go through a whole bunch of
other crew things [in] preparation for orbit ops.
Tell us about communications with the flight crew and how that evolved
over the years.
It all really started back in Mercury. I wasn’t here for Mercury.
Then we went to Gemini and Apollo. I guess probably early on, maybe
it was flight director that talked to the guy, but you didn’t
want to have too many people talking to somebody, because they’d
step on each other. You could miscommunicate. Eventually we got to
the point where in Gemini and Apollo, you liked to have preferably
a flown crewman, but if you didn’t have one, somebody that trained
with the flight crew to be the guy that communicated with them.
We used to send these guys out to remote sites. So you had to have
several. Well, let’s see. It wasn’t always a crewman at
the remote sites. Once it became consolidated in the MCC, typically
it was a crewman. It was a couple of reasons. One, they were familiar
with the training. They were familiar with the cockpit. They had discussed
with the actual flight crew things that were going on, in case they
were the ones that flew. They had a real close relationship and familiarity
with what the cockpit looked like and what the impact to a crewman
was of asking him to do one thing or another. They could give a best
Now within the control team, the control team would say, “Flight,
we need the crew to do this or that. Could you ask them to do this
or that?” Then the CapCom [Capsule Communicator] was there,
and he was listening. Then if the flight director wanted to slightly
modify that, he’d hail CapCom. “Okay. Go ask them to do
this or do that.”
Early on it was minimized, because you only had short site passes.
You might have a three-minute pass. You might have a maximum of a
ten-minute pass. Everything had to be pretty concise. The CapCom would
be the primary communicator. Now when the guys are talking back down,
they’re talking to the whole world, but the guy they expect
to answer is the CapCom.
That has stayed with us for a very long time. It’s changing
a little bit in Station, because the crews are just tired of being
there all the time. They don’t want to be there 24 hours a day.
“We haven’t got enough crew,” and that kind of thing.
So we’ve got some other people that do that, but the Russians,
for example, [I’ve heard] any position can talk to their crew.
I don’t know how much that’s true or not, but that’s
what I’ve been told. We have not done it that way. We’re
a little bit more control freakish. It also minimizes the chance of
getting stuff really garbled. A CapCom will garble things every once
in a while, but there’s people that are listening say, “Oh,
no, this, say this.”
When the guys are talking down everybody’s listening. The expectation
is that the responsible positions will hear a crew person say something.
They say, “Oh, Flight, ask them that.” Or “No, that’s
wrong.” Or “No, they got that wrong.” Or “Do
this.” Or “Do that.”
Tell us about the Mission Control and how it monitors the vehicle
Well, telemetry comes down through TDRSS to the White Sands Ground
Station [Las Cruces, New Mexico] into the MCC. Calibrated, put up
on displays that the people built. They are always monitoring. There’s
a human intervention. Sometimes they will have built special computations
that will calculate, sum up total quantities of this or do a rate
calculation, so many pounds per minute or hour or something like that.
They’ll have limits on those so that they get alerted. They
have a lot of tools now that we didn’t have early in the game
that monitor for events or combinations of events and will give you
messages. That part of the job has got a lot easier now since we’ve
got some of those tools and we learned how to use them.
Also it can have a detrimental effect in the sense that if you come
to count on them too much, you forgot what’s there, and you’ve
lost sense of your own system. One guy told me some years ago, he
says during sims, he turns off some of these tools every once in a
while to force himself to pay attention and to learn what his scan
patterns are. It’s like passwords in your computer, in the sense
of if you keep your email online you can tell a computer, “Remember
my password,” and it does, as long as you’re on that computer.
If your computer dies and you haven’t used your passwords in
months and months and months and it asks you, “What’s
your password?” if you didn’t write it down you forgot
what it was. Personally I don’t do that. I say, “Do not
remember this password,” so I’m forced to put it in every
time, which helps keep my memory.
These tools have good effects and can have bad effects depending on
the particular operator, but it’s monitored constantly. Since
you have TDRSS, you’ve got pretty much constant communication.
When we’re at lunar distances, you had constant communications,
because there was one of the three deep space sites was always in
view once you get far enough away. When you’re working just
with ground sites, like real early Shuttle was before TDRSS was, you’ve
got sporadic [coverage]. You have a three-minute pass here, an eight-minute
pass here. Then you may have an hour with no passes at all. It varied
depending upon where you were.
Can you talk about some of the support the MCC provided in terms of
satellite deployment or retrieval, EVA, things like that?
The crew is very limited in they have no sense of trajectory. You
can keep a world map and say about where you are, but you don’t
know precisely where you are. If a satellite needs to be deployed
at exactly over this point rather than this time, the ground tracks
all of that. If you want to delay it, anything goes wrong, you want
to delay it, then the ground generally has to be involved in all that.
The ground manages the com [communication]. The crew has no idea whether
TDRSS is working or not unless they’ve got communications. If
west TDRSS is good and east TDRSS has gone bad, the crew has no way
of knowing that until they get there. The ground knows. All of that
kind of stuff is what the ground does. The ground helps crew keep
track of all the consumables. Crew has too many other things they
need to worry about. So this business people talk about autonomy depends
on how you define it, but especially with payloads, they’re
interacting with the ground people, unless they have something that
you just turn on in the mission, go back and turn it off.
Tell us about reentry in the Mission Control Center. How does that
The entry, they’re always planning for emergency entries. You
prefer to land at KSC, so there’s weather considerations. You
have a couple, two or three opportunities. The weather will be different
on each one of them. Lighting will be slightly different. Your entry
trajectory is mostly onboard-controlled. You could have a situation
where first entry the crew makes a left-hand turn, whereas the last
one it could be a right-hand turn, so it’s a different visual
thing. (You need to take that with a grain of salt. I think that’s
true, but I’m not absolutely sure.)
They’re looking at the weather, they’re looking at the
various opportunities. Because if the weather is bad, can I wave off?
You have to make that decision before the deorbit burn. You’d
like to make that decision before you close the payload bay doors,
because once you’ve gone through the payload bay door closure,
you’re now on internal water boiling to cool the thing rather
than using the radiators. Then backing out of it takes longer.
There’s a lot of decision making, especially in regards to weather
and consumables planning, because you want to have as much water as
possible. It’s an interactive kind of thing. Like this last
one, you waved off a couple times. That’s the typical thing,
is try to get your wave-off decisions done before payload bay door
close, which means you delay payload bay door closing as long as you
can. Then you can wave off again, if you have to, before the deorbit
burn. But after you’ve done the deorbit burn, you’re in,
and it’s all pretty much all automatic after that. You’ve
done the deorbit burn. You’re pointing in the wrong direction.
You pitch over, now so you’re headed nose first. Your vehicle
will get the right angle of attack. Then you’ll hit entry interface
about 30 minutes later.
It’s all trajectory. The deorbit burn is about one hour from
landing. Entry interface is about 30 minutes from landing. That was
always my observation. Just before the deorbit burn you start one
APU, two to three minutes before the deorbit burn. Let it keep burning.
Just before entry interface, about five minutes, you start the other
two APUs, assuming they’re good. After that you’re pretty
The crew doesn’t really do anything. John [W.] Young did. He
flew the needles, because he either didn’t trust them or whatever,
but they’re all auto. So the vehicle does its S-turn and dadada
until you get down about 20,000 feet or thereabouts, just before you
come around the heading alignment circle. At that point, they switch
to crew sort of controlled. Crew is making stick inputs. You’re
still flying the needles, but they always claim they want to get a
feel for the vehicle. Because if you have to take over late and you
don’t have a feel for the vehicle, it’s problematic. You’re
more likely to make errors.
So they take over about that [time], and then they fly it around the
circle. It’ll fly auto, but that’s what they typically
do. In fact, we never certified autoland, but it probably would. What
you can’t predict is winds. That’s why we typically fly
an STA [Shuttle Training Aircraft] up there just before the crew enters.
[The STA pilots] say, “Upper level winds are this.” You
tell that [to the] crew. When you come around the circle you can either
go a little wide if the winds are pushing you this way, or you can
go a little tight if the winds are pushing you that way. [Demonstrates]
Then you come down. What you’re watching very closely is you’re
watching your altitude rate of descent and your velocity. You want
to maintain your energy margins until the last minute, because you
have no engines. If you come in short, you’re screwed. If you
come in hot, you’ve got brakes. You can just open your speed
brake as wide as possible. You’ve got the drag chute. You prefer
to come in hot, but on that landing site at KSC you’re in a
swamp if you come in short. It’s going to wreck everything.
He’s flying it, and he’s flying the needles. It’s
got a head-up display. It’s telling you too high or too low.
Just fly the needles. You’re looking out the window. So if the
needles are taking you to the wrong place, you can adjust for it.
I don’t think they ever have, but they could. You come down,
and then you’ve got checkpoints, and you got a place that says,
“Lower the gear.”
When you lower the gear, you put drag out there. You typically wait
[as long as practical]. You drop the gear. Then once you’re
coming down at that high angle of attack, it’s drag anyway.
You just set it down. Then you set the nose gear down, deploy the
chute, and just before you stop rolling you blow the chute off so
it falls off on the ground and doesn’t mess up the Main [Engines]
any more than it might. That’s it.
Following the end of the mission, you share lessons learned. How do
you implement those for the next mission?
Anything that’s real obvious you can do. If it’s a flight
rule change or procedure change, something like that, that’s
typically not a problem, if it’s applicable to the next mission.
It might not be applicable to the next mission. If it’s something
you learned, say, dealing with Hubble, it’s probably not going
to affect Space Station much at all, but if it’s something like
cuts on the gloves of the EVA crewmen, now that may or may not have
shown up. [It] depends on how fast somebody is inspected and says,
“Hey, there’s a cut here,” but that’s maybe
a sharp edge thing. It’s typically a procedural thing, because
the next mission might be a month away. So you’ve set a lot
of things in stone, but you can change rules and you can modify procedures.
If it’s something that’s a flight software problem, wow,
you just barely got away with this, you might have to delay, you might
have to patch or something. That’s a different story. The crew
typically will write up a report. They’ll have squawks, and
they’ll have three or four things they think, “By God,
you really need to change this.” Those are documented and shipped
over, and MOD will respond, ”Yes we will” or “We
won’t.” May or may not be the next mission. May be the
next mission on that vehicle, which could be three missions down the
road, but if it’s something that really needs to be done, it’ll
be done. It’s effective on that next mission.
Does MOD do the same thing that the crews do? Do they come up with
a lessons learned package?
Oh sure. Typically each discipline, like Systems Division will go
have their postflight review of systems issues: what needs to be changed,
what did we do, what could we do better, is there something that needs
to be changed in the MCC, how long is it going to take to put in a
statement of requirements for that. Trajectory does the same thing.
Trajectory have a very formal, they call it a postmission reconstruction
where they’ll go back and review the whole mission and codify
or write down altitudes, attitudes, those kind of trajectory-oriented
things for later reference in case somebody later on says, “What
altitude were we at? How close—wow, there was a near conjunction
You have to have that postflight reconstruction to know exactly where
it was. Whether where preflight it was supposed to be, because the
burns didn’t happen right on time or there was more drag or
whatever. There’s any number of reasons that they do that. Payload
people, but again, if that payload is not on this next flight—maybe
it’s never going to show up again. Not much to worry about there.
Everybody looks at it. Of course, they’re doing some of it in
real time too. Then program office has one, too, with their MER. Then
anomalies, risk assessments, and anomaly reviews go on after the flight.
I think you have answered all of my questions, but I wanted to ask
Oh, boy, that’s a lot of good information.
You think there’s anything we haven’t talked about?
Well, let’s see. Did you go down through these? DoD, flight
control trajectory, flight rules. Determining specific flight rules
for a new mission. There’s a whole documentation tree on the
flight rules. There’s a generic flight rules book. There’s
some other flight-specific books, because the rationale is in the
books. Typically generic rules are just what they do. They’re
generic. They don’t change that much from flight to flight.
Flight-specific rules are payload-specific. They will be unique to
that flight. They may apply to later flights as well, but they might
be unique to that flight, because there’s something unique on
that flight. They’ll probably be used for the basis for the
next flight, like EVA on Station.
So those are reviewed. There’s a thing called the Flight Rules
Control Board. That’s sanctioned by the Shuttle Program Office.
MOD runs it. Then prior to a flight, we come up to the program office
and say, “Okay, these are the flight rules that we have changed
or modified for this flight.” We brief them on that. They say,
“Okay. “ That authorizes them, so to speak. That’s
how that’s done. It goes on all the time. Probably Flight Rules
Control Board meets every month or as necessary.
Certification, training evolved over the years. It’s become
more formal over the years, I’ll put it that way. In terms of
what did we write down that we needed to give the sim guys to do,
it used to be they just listened at flight rules mission meetings,
flight techniques meetings and decided what they needed to do.
Fly. Launch phase. Launch windows. How are launch windows determined?
It’s just mission requirements. Like the launch window for 107
was two or three hours, because it didn’t have to rendezvous
with anybody. It just needed to get there. There are restraints on
how long the crew can lie on their backs. Once they get in there,
there’s a clock that starts. They’re closed out. Then
it’s about maybe two or three hours. Then they either launch
or get out. Even though trajectorywise, it doesn’t matter.
Then the launch windows, when you have to rendezvous, is very precise,
if you’re going to try to do it in a relatively efficient period
of time. Ascent period. Communication. Did I get enough on that one?
MCC support for EVA? We have specialists. EVA is a specialist position.
So they’re only there if there’s an EVA. Robotics, same
way. Booster is only there for launch. Sometimes they’ll come
in for entry if there’s something that they’re looking
Resources were monitored. Orbital debris we talked about. Entry data
we talked about. How did [the] Columbia accident change reentry landing
trajectories? As far as I know, that was adjusted to minimize the
debris fallout in case there was another one of these incidents over
land. It was population protection. It also may or may not have affected
some of the launch aborts as well. The guys ran through a certain
amount of—I don’t want to say it’s hocus-pocus,
but you can’t totally predict where the debris is going to be.
It depends on how the vehicle would break up as to where that debris
is going to fall. Once it falls apart, typically they say once you
start hitting atmospheric restrictions, instead of going like this
it comes [straight down]. [Demonstrates]
Somebody, I remember in the Columbia investigation, some guy said
most of these things, once you get at about 50,000 feet, it’s
just falling straight down at that point. If there was an explosion,
things are going to go all over. Some of them will be slowed down,
some of them will go forwards, speedier, some of them will go off
to the side. So they’re going to keep going in that direction
until they start running into atmospheric drag. Then after that, then
they start to really slow down and fall off if they don’t burn
up. That describes the debris field. You can only do that within so
much margin of error.
Okay. So I guess we did.
I think so, yes. Yes. I went through your chapter and things that
I had questions about. Just wanted to clarify with you.
Well, then I probably exhausted. Let’s see.
I saw you came in with some notes. Did you want to refer to those?
I said mission ops. Planning procedures. Program office was a big
part of that. The process evolved over time. There was a thing, an
official release called an FIDP, Flight Integrated Data Pack, that
the program office released. It’s mostly trajectory-oriented,
but it said, “This is what the flight is about. This is the
mission content. The mission objectives.” Those kinds of things.
So that became a checkpoint, especially for USA [United Space Alliance]
to do their trajectory work. We had a crew procedures management plan
that defined how flight procedures were managed. There was a flight
design process trajectory. EVA, the NBL was used. Robotics training.
Crew alone. Team training we talked about.
ISO [International Organization for Standardization] 9000 system procedures.
When Abbey took over, we got into this period of time when ISO 9000
was the greatest thing since sliced bread. That was put on the Center,
and then MOD is part of that, so we documented a number of things.
That was probably a good thing in some sense. We have work instructions
for most of these processes. Flight design in particular has an—I
don’t know, 25-volume set of procedures and processes.
Flight procedures. There’s a thing called a flight ops review
where we had the preliminary set of procedures were sent out to all
the players: payload people, customers and whatnot. We had a big review.
They got to review the procedures, and we had a big thing called a
flight ops review, and they got to comment on all the procedures.
Then we took all those comments and updated procedures. That was part
of that process.
When did that occur?
Gosh, I don’t know, a couple months, two, three months before.
There’s a whole template of this stuff. Let’s see. The
MCC ground facilities. Cargo payload unique formats. Customer service
provisions. You had asked, I think, about POCCs. Building 30 South
laid out all of that thing and put POCCs in place and the customer
support room. It evolved. Then after [the] Columbia accident, we added
a big whole new MER. MER had been in different places at different
times. We built a whole new one for them over in the 30M section as
it turns out.
The interesting thing is Building 30 South was built as a Space Station
Control Center. Space Station control is now in Building 30M. Shuttle
is in the 30 South. The latest Space Station Control Center is the
old FCR-2, which is where we flew Shuttle from originally, and Apollo.
Kind of interesting.
If you want real details about these things, now, Earl [W.] Thompson
was big in planning. He’s retired now. He ran the ops early
in the Shuttle Program. The people that are currently over there in
place that might help you, Pete [Peter J.] Beauregard on training.
Mike [Michael G.] Hess is running the EVA and Robotics, and his deputy
Sue [Susan B.] Rainwater. Dan Lindner was big on [Robotics in] the
early days. He’s running the MCC now, but he used to run Robotics.
He’s the division chief. Sue Rainwater is deputy to Mike Hess.
In trajectory world, Rick [Richard T. Gavin]. He’s the deputy
chief of trajectory, of DM. The chief of DM used to be in training
and is brand-new, relatively. So he wouldn’t have any history
on trajectory, but his deputy would. Rick is deputy DM, deputy director,
deputy division chief of DM. If you want a lot more detail or something
fleshed out. What I’ve given you is my observations.
I was always in systems. I can speak pretty authoritatively for that.
Then the later parts of the MCC development, and the earlier parts,
because I had a role in that. My knowledge of trajectory is observation
of years of flight techniques and watching the guys operating the
control center and occasionally talking to people and just general
interest. Operations, the payload officers is more observation and
then the flight activities officers. They take—what does the
crew do or what’s their timeline? It’s observation.
Well, I think based on what Helen told me she’d like to see,
I think just a general overview is sufficient. So this is very helpful.
to JSC Oral History Website