Shuttle, Houston

by Paul Dye

  Drag chute operational development took place to a large extent in some complex simulators, namely the Shuttle engineering simulator at the Johnson Space Center and the Vertical Motion Simulator at the Ames Research Center in California. Hundreds of pilots, both astronauts and engineers, flew thousands of runs in the big six-axis simulator at Ames to perfect ways of landing that gave the most margin—especially with blown tires, locked-up brakes, an unexpected drag chute failure, or failures in the nosewheel steering. All of this flying reflected back into procedures and rules, which then poured back into the training program for both pilots and flight controllers. It was frankly a fun time to be in the program. We were learning every day, and drinking from a fire hose is exciting when you’re young.

  While all of this was going on in the trenches, upper management was apparently going through its own soul searching. They reorganized things to make sure strategic decisions were made in the open, and that there were opportunities for objections from any quarter. The problem, of course, is one that any large, technical organization faces: it is easy to say that if anyone has a problem, they should say so and operations will be brought to a stop until their concerns are satisfied. It is another thing to actually make that happen. With literally hundreds of thousands of engineers involved in the Shuttle program, it would be surprising if you didn’t have at least one individual who wasn’t comfortable at any particular time. In fact, there are always small groups who are concerned about every launch and would like to see it stopped until more work has been done.

  The issue is one of risk acceptance. Some people accept too much risk and take chances when they shouldn’t. Taking too big of risks often leads to failure, which can also mean loss of life. Others are too risk averse and will try never to accept any risk at all, and as a result they never do anything. At least they are safe, but their mission is a failure. The trick is to be somewhere in between, maximizing safety while at the same time maximizing the chances of mission success. But a smart team listens to the naysayers, because oftentimes that lonely voice crying out in the wilderness is correct. You ignore them at your peril, because if you fail and kill someone, then it looks like you were being reckless by disregarding the warnings of someone who knew better. It puts leaders and management in a very tough spot. Folks in leadership roles understand that no one knows everything, and they also understand that sometimes the folks who are being more conservative don’t have the whole picture in mind. Other times, the folks who are pushing to go ahead don’t have all the facts. What is important is to make sure that everyone feels like they have been heard, and that their position has been weighed in the final decision. At least this was how I always saw it—so long as I felt my position was heard, understood, and considered, then I didn’t feel so bad if the decision went in a different direction. You simply don’t win every position that you take.

  I like to tell a story that was told to me by my Apollo colleagues about what they called “Burning Rocks.” Apparently, in the push to go to the moon, one particular scientist was concerned about the chemical composition of the lunar surface and its potential for interacting with the exhaust plume of the lunar module. He felt that there was a danger, but he kept it to himself because everyone else was pushing to go, go, go. Finally, he couldn’t contain his fears any longer, and just before the crew was going to power up the descent engine on the lunar module to start their actual drop to the surface, he spoke up and said that he was afraid that when the exhaust hit the surface, the moon might spontaneously combust in a cataclysmic event. This was, of course, after the crew had launched, transited to the moon, and put themselves in lunar orbit. The Flight Director was presented with this information just before the Go or No Go decision to begin the descent, and his reaction was essentially, “Well, what the heck do you want me to do with this?!”

  There are times and places for considered and supported arguments—and that time is before you have committed to the dangers of spaceflight. Once you are hurtling along at high velocities, you have to accept that you have already taken great risks to get there, so maybe you’ll have to take a few more risks to get the job done. However… if you have new information, something that you never had before, then it must be presented and thrown into the mix. Sometimes, you might just save the day.

  STS-26 launched on September 29, 1988, more than two and a half years after the loss of the Challenger. It carried one of the best-trained crews in Shuttle history, and it was monitored and controlled by probably the best-trained flight control teams in history. The flight controllers never stopped training during the downtime, and I personally went from one orbit discipline to being a front room member of the Ascent/Entry team in that time. It was a marvelous couple of years, despite the tragedy that started it off. The training teams put us through the wringer countless times, yet we all knew that if we were once again faced with a complete catastrophe like that which befell the Challenger and her crew, we would still be nothing but spectators at close range, helpless to affect the outcome in a meaningful way. But we trained for the thousands of cases that we could handle, and we did our best to ensure that the engineering teams had done their best to preclude the worst cases. Moreover, we were fortunate to be flying a much better, more capable, and measurably safer vehicle.

  Shortly after the main engines cut off and the Discovery was in orbit, Lee Briscoe, the Weather Flight Director for the launch (he assisted the Ascent Flight Director by assimilating and organizing all the incoming weather information), walked around the room. He leaned over each console and shook the hands of every flight controller, congratulating us on the work we had done to get to that point. Yes, we still had an entire mission to fly, followed by the entry—but the first step was complete. America was back in orbit, and we all knew that we had done a good job with the time we had been given to make the program safer.

  The Shuttle flew safely for years after that day, of course. Our flight rate never again came close to what we had done the year before the loss of the Challenger, and obviously we were nowhere close to the absurd projections of the 1970s that said we’d be flying sixty Shuttle missions each year. The system simply could not accommodate that. Gone were the commercial satellite launches, and soon to be gone were the dedicated Department of Defense (DOD) missions that took so much effort and expense to keep them classified. The DOD and Intelligence communities decided that going back to expendable rockets for their highly classified payloads was more expedient and cost efficient, so the Shuttle team began looking at science and engineering—and building a space station—as our goals. It is ironic that the real purpose of the Space Shuttle, as sold to NASA, Congress, and the American people when space travel was in its infancy, was to build, service, and provide transportation to and from a space station—that is what a “shuttle” is for. And eventually, that is where we came back to—first bringing cargo and crew roundtrip to the Russian Mir, and then building and servicing the ISS for the last ten years of the Shuttle program.

  From 1988 until 1995, the Shuttle flew many payloads, including the Hubble Space Telescope (HST) and deep space probes that flew on to the planets. We built and designed a wide variety of missions, and we perfected the techniques of EVA (Extravehicular Activity) and the manipulation and capture of payloads with the RMS (Remote Manipulator System). We tried out new space structures, and we tested electrical and fluid connections that would have to be mated and demated in a vacuum (by EVA astronauts when the ISS started to go into orbit). And we flew dedicated science missions that created a growing knowledge base for researchers interested in using space for a variety of reasons.

  As we began building the International Space Station and staffing it with crews that were brought up and down with the Shuttle, we made a little room in the manifest for a variety of small but important science projects. But they were all collected and put together to fly on a dedicated science mission, STS-107. This mission was slated to fly a number of different times, but it finally settled into a
launch slot in January 2003. It was out of the mainstream of ISS construction and operations, and many of us were so busy with those missions that we paid little attention to it. I had been flying the Shuttle as a Flight Director for over eight years by that point, and I had quite a few missions under my belt. I was working on my next Shuttle mission, and the next one after that, and the next one after that… and because I was not assigned to STS-107, I took it as a chance to take a little break from the weekly routine of mission preparations and training. (Because so many people were involved in the flight, it was hard to do anything else—no one was available for meetings or training.) So I just worked in the office as needed and took a little time off. I really wasn’t even aware of which day they were landing.

  I had driven out to the airport on that Saturday morning to go do a little personal flying. But by the time I got most of the way there, it was apparent that the fog and winter scud were getting worse, not better. It was going to be fruitless to even give it a try. So I turned around to head home, but first I stopped at a local auto parts store to pick something up. As I walked in the door, wearing my NASA flight jacket, a customer looked up and asked, “So what happened to the Space Shuttle?” Perplexed by the question, I answered, “I don’t know, what did you hear?” His answer chilled me to the bone. “Well, they say it’s falling down in pieces all over Dallas!” Just then my pager went off, followed by my cell phone ringing—and once again life was never going to be the same.

  The proximate cause of the Columbia’s breakup was a failure of the thermal protection system—a hole in the leading edge of the wing let in superheated (3,000 degrees) gases that melted the relatively light aluminum structure. The airframe failed, tumbled, and came apart. The cause of the hole was a piece of foam that had separated from the External Tank on ascent. This foam was so light that it essentially came to a stop while the Orbiter flew through it at supersonic speed. This impact generated enough force to fracture the Reinforced Carbon-Carbon (RCC) skin of the wing near the fuselage. The technical root cause was this foam. But, once again, if you ask, “Why did the foam fail?” you eventually come back to errors in judgment by a wide variety of people throughout the agency, the program, and the operational management teams.

  We were down for close to two and a half years once again. I was much higher up in the organization by then, and much more experienced in the leadership of space operations. I was therefore much more involved with fixing the people problems than I was in working on the details of technical improvements to the Shuttle system. Before I really began doing my part to fix things, I spent over two months living and commuting back and forth to East Texas, the scene of where the Columbia debris fell. It was a minor miracle in that the debris field was so close to home, and that it was over land. If the debris had come down over the ocean, we might never have known the details of what happened. It was another miracle that no one on the ground was hit by the nearly 80,000 pounds of debris that made it to the surface without burning up. My job was to help run the air search operations—I organized all the work of fixed-wing aircraft that were searching for debris. It was a big task, with assets ranging from powered parachutes to the NASA ER-2 (a high-altitude U-2 reconnaissance airplane in civilian colors and with unclassified sensors). It took the attention of a number of people to make sure the assets were used efficiently and safely.

  All the air work, although useful, proved not to be the best method for finding and collecting debris. What worked best was “boots on the ground”—people walking gridded miles shoulder to shoulder and looking down to see what they might find. Miraculously, the Orbiter’s Operational Recorder (Ops Recorder) was found on a gentle hillside nearly intact. This recorder was not designed to be a “black box” as you’d find on an airliner, but it served that purpose because the data engineers were able to extract an incredibly detailed timeline of sensors burning out and the wing failing. This allowed us to track the course of the failure. When this effort was completed, we knew why the Orbiter failed. By then we also had enough information from studying the interactions of the personnel involved in the mission to give us a good idea where the people had failed in their decision-making.

  Once again, it was a matter of getting too comfortable with success and, to some extent, discarding the cries of those people on the edge of the room who had reservations about what was going on. Once again, it could be thought of in terms of Russian roulette. The signs were there: foam was coming off the tank (click), again and again (click, click)—but it never seemed to hurt us, so we figured it was safe to go again (click…). We just hadn’t experienced the worst-case scenarios yet—until we did (bang!). And once the failure had occurred, there was little to nothing that could be done—the crew was essentially doomed from the start because there was no way that a rescue mission could be mounted with any sort of sane schedule or reasonable chance of success in the time available. In hindsight, many have suggested that it could have been done, but those people rarely have inside knowledge of what it really took to plan a Shuttle mission, and just how many chances there were for things to go wrong if you rushed through them. Realistically, we could have stood a very good chance of losing the second crew as well, simply because of something we would have missed.

  My task, once I put my flight gear away and settled back into my Houston home and office, was to help out training management to make better decisions. We spent huge amounts of time training the real-time flight control teams—and even the engineering support staffs—to make good, reasoned decisions quickly and accurately during flight. And we expected our management, many of whom had come from the flight control ranks, to do the same thing. But an equally large number of program managers and NASA leadership had not had the benefit of growing up (professionally) in the Control Center, and we felt that since any team is only as strong as its weakest link, this time around, we needed to concentrate on training for the Mission Management Team (MMT) just as strenuously as we were training the real-time team.

  The MMT was filled with good people, and everyone had a vote. But some votes were made by people who really didn’t understand the topics being discussed. A representative from the Space Life Sciences Directorate, for instance—while well-meaning—didn’t necessarily have the engineering background to help decide whether a limit could be changed in the hydraulic system because of a failure that was making it hard to control the temperature. They had no training in how to evaluate the presented information, and therefore no basis on which to vote other than to rely on the recommendations of other team members. The interesting thing is that sometimes this distance served a useful purpose, because it was not uncommon for those closest to the problem—the engineers and operators—to miss the big picture and forget that there were other options. It was not uncommon for a good idea to come out of left field, and the experts had to be trained to recognize it.

  Our training plan for the MMT was multifaceted. It included both stand-alone training sessions (participatory classes) and stand-alone simulations. We also included the MMT in some full-up simulations for the Return to Flight missions so that they had to make decisions with the real-time flight control teams and crew who were waiting on their decision-making. Creating simulation scripts that could challenge both the operations teams and the MMT was partly a matter of looking back in the records to find cases where we thought the outcome could have gone multiple ways. We also had to look at all the changes being made to how detecting tile damage was going to be handled, and we had to make sure we trained folks in the new way of doing things. However, we always remembered that we didn’t want to make the mistake of “fighting the last war.” It was unlikely that our next major problem would be related to the thermal protection system, the tiles, or foam coming off the tank—so we needed to be training in problem-solving techniques, not specific cases.

  One of my contributions to the training effort was a class with a twist. We wanted to make sure that the teams understood the importance of thinking ou
tside the box—whatever box that might be. I pulled an accident case out of the aviation files and created a two-hour team-building exercise that was based on the July 2000 Concorde crash in Paris. This crash was caused by a cut tire that cascaded into a ruptured fuel tank, which failed two engines and eventually caused a crash on takeoff. Only my students didn’t get told it was the Concorde accident until the end of the session. Instead, we split the students into two teams—Airline A and Airline B. They didn’t know at that time that they were really British Airways (BA) and Air France (AF). Each team was given data on a tire problem that had been going on for some time. Occasional blowouts seemed to be increasing in frequency, and some had even shed rubber that dented the lower surface of the aircraft. We used real data from BA and AF but didn’t mix the two.

  The two teams were put at opposite sides of a large conference room and told that they had a flight leaving on this particular type of aircraft in just a couple of hours. A maintenance manager had decided he was worried enough to bring the growing tire problem up to management, and they had only a short time to decide if they were going to let passengers fly that afternoon on the aircraft, or if they would have to cancel the flight and reroute them. We also told the teams that they could use whatever resources they could think of to come up with a good solution. Without exception, every time we did this, the teams pored over the data we gave them, and they almost always decided that they didn’t have enough data that indicated they should cancel the flights.

  The one thing they never did was to send someone over to the other team’s table to ask them what they were seeing in their own data. They were flying the same type of machine after all. If they had, they all said (in the debrief for the exercise) they would have seen that the problem was much more widespread, and they probably would have decided not to launch. Of course, this was after the “gotcha” moment when we showed them the video of the Concorde going down in a fireball. It was always a sobering moment. After we had used the training class on the program management, we did the same thing for our operations leadership and flight controllers. The lesson was that you never know as much as you think you know, and that so long as you have time to gather more data, you should do so. Eventually, you have to make a decision based on the data you have, so have as much as you can to better your odds of making a good decision.