AVweb doesn't normally cover spacecraft accidents, but this one was just too interesting to pass up. Although not widely publicized, the space shuttle program recently had an in-flight mishap caused by a simple instrument failure that might have destroyed the orbiter and killed the entire crew...except that fortunately it occurred in the shuttle simulator, not the actual spacecraft. Although we've changed the names to protect the guilty (in case NASA doesn't have a sense of humor), we think this true-life account will prove fascinating to all pilots...especially glider and instrument pilots. After all, a shuttle landing is nothing more than a very steep instrument approach by the world's heaviest glider.
July 21, 1997
NASA memorandum illustrates that no matter the size of the aircraft — Cessna
152 or Shuttle — or how much training a crew receives, it's fundamentals like
instrument cross-check and airspeed control that count.
We've de-identified the folks involved, and we've attempted to decode
all the arcane acronyms unique to the shuttle program [in bracketed italics].
Otherwise, the memo is reproduced here verbatim.
Memo from NASA
[Mission Operations Division...the mission control center
As most of you have already heard, we failed to make the runway at KSC
[Kennedy Space Center, Cape Canaveral, Florida] at the end of our STS-xx
[Space Transportation System...the official name for the shuttle program]
D/O Prep [De-Orbit Preparation: a simulator session that trains shuttle
pilots for re-entry through touchdown] sim earlier this week. There were
several failures throughout the entire sim, including the glided entry phase.
However, by the time we reached the HAC [Heading Alignment Cone: the big
300-degree turn that the shuttle makes to do energy management; the crew "plays"
the HAC to account for high or low energy in the phase of the glide just before
lining up on final], we had configured for landing and the systems failures,
etc. were essentially behind us.
We at MCC
[Mission Control Center] had basically stopped talking to the crew,
except for the HAC energy calls — things were relatively quiet the way you like
it on the HAC. At some point on the HAC (or, earlier?) the SMS [Shuttle
Mission Simulator] suffered a real hardware failure of the CDR [Mission
Commander's] ADI [Attitude-Direction Indicator: the "8-ball" instrument
installed on both the left and right sides of the instrument panel, each
containing three error needles that are essentially flight director command bars
for pitch, roll and yaw] pitch error needle — it failed static [the
pitch-axis needle froze with no error flag]. As a result, about 20 seconds
after going CSS [Control Stick Steering: below about Mach 1.3, the mission
commander takes over from the autopilot and flies the vehicle manually, because
the shuttle's autopilot has no real redundancy...remember it was designed in
1972] the CDR began a continuous, gradual pitch down. About 20 seconds after
that, guidance commanded a HAC shrink [playing the cone: if you're low on
energy, you fly a smaller cone with a smaller circumference] as a result of
the altitude error low. At some point during this time, the crew called the MCC
and said that they thought they had some kind of guidance or nav problem.
The MCC confirmed good nav, good guidance, and good sensors. (The MCC called
that the airspeed was much too high and that they should check the airspeed; the
MCC energy call at the 90 was 5 knots low.)
Within 30 seconds from the time that the CDR started the pitch down, the
situation was very serious and essentially out of hand. The MCC knew that we
were getting much too low and that we needed to pull up. The crew knew that
there was a problem but had not identified exactly what it was, and thus had not
started to correct it (still pitching down). When the CDR realized that his ADI
needle must be failed, he handed over control to the PLT [Pilot:
second-in-command to the CDR]. The PLT managed to get theta and EAS
[equivalent airspeed] under control, but the vehicle stalled (Alpha 20
[angle-of-attack, 20 degrees pitch-up], EAS 155) about one mile short of
the runway while the crew was trying to stretch it in.
What happened? We suffered a single, real-world hardware failure, and we lost
the vehicle (and crew?) in this sim. How is this possible, with all of our tools
on the ground and with the many instruments and built-in crosschecks onboard?
The short answer is not an easy one to come to, but the consensus is that we
essentially had a breakdown in the cockpit — a cockpit resource management
problem. The crew feels like they were able to determine that there was a
problem, but that they did not identify the problem as quickly as they could
have, and thus their response and corrective action was too little too late. We
think also that perhaps the MCC could have been a bit quicker and more crisp in
our recognition of the problem and in our response. Additionally, we think that
for these kinds of scenarios, the MCC should be emphatic and forceful with our
calls to the crew in order to accurately reflect the criticality of the
This is a tough
case folks, but we need to be able to sustain a single real-world hardware
failure and make it to the runway. Indeed, in such a case we depend on the crew
to be prime for psyching-out instrument failures onboard. Everyone believes that
this crew and any assigned trained crew can (and will be able to) determine when
one of their primary instruments has failed, and ultimately recover from any
adverse affects. We certainly depend on this for many cases where we would not
be able to react in time from the ground. In a lot of cases, the crew is on the
scene and the actions are super time critical. We also depend on the MCC to sing
out when we see things that we don't understand or that look bad, whether it's
energy or altitude on the HAC, or some other problem.
I think the message here is for all of us to remember that most likely in the
real world we will not have the second or third IMU [inertial measurement
unit: gives the crew attitude data; there are three on board] failure, or
have to perform a single APU [Auxiliary Power Unit: the hydrazine-powered
turbine that powers the shuttle's hydraulics; there are three hydraulic systems
and three APUs on board] landing, or suffer two main buss failures. Rather,
we will probably see something like this, something that perhaps we don't
understand, or that we haven't seen before in a sim. When we do, we must be
ready to resort to our discipline and training, and we must separate those
things that we know to be true from those things that we don't understand, and
then communicate that as accurately and as expeditiously as the situation
requires. Be alert, talk to each other, and be aggressive if it becomes
Please take time to think about this case, and others like it. I think we can
learn from this, and that we should take some time to think about other such
scenarios that could "look and feel" like this one.
Additionally, we recorded the run on the GPO w/s [Guidance Procedures
Officer's workstation] in the MCC and I would like every GPO and GSO
[Guidance Systems Officer] to see this run at least once or twice on our
GPO displays. For those of you who have not seen it yet, please make time to do
so in the next week. I encourage you to take time to do this, and to invite
other folks to go with you.
A static needle — no shaky when it breaky — without a warning
flag is a serious condition waiting for an accident to happen. I've seen ILS
glideslope needles fail dead-center with no warning flag, and a failure like
that can kill you if it goes undetected. On a vehicle like the shuttle, the
approach sequence is so tightly controlled (energy-wise) that the needles must
almost always be dead-nuts center. A brief excursion can be deadly. It's a
miracle that this didn't happen on a real mission.
Aviate, Navigate, Communicate...and keep up your scan! —Ed.