Authors: David Hitt,Heather R. Smith
Tags: #History
Mattingly had the unique vantage point of watching the shuttle program evolve from a concept through logistical support into its mature state, he recalled. “I look back and I say, ‘Well, we know what we started to do, and we know what we have, and they’re not always the same. Why?’ Because it was an extraordinary job. Apollo was a challenge because it was just so big and it was audacious, and time frame was tight, and all of those things.” But in many ways, Mattingly said, the shuttle was even more challenging.
Essentially, it was so demanding that all of the engineering and ops [operations] people . . . generally stayed on. We didn’t have a lot of technical attrition after Apollo. At least that’s my impression. At least the middle-level guys all stayed, and they kept working it because they recognized that the shuttle was a far more challenging job than Apollo in many technical senses.
The part of the shuttle that was different was Apollo was a collection of boxes. If you had a computer, you could build it, you could test it, you could set it out and do it all by itself. You had a second stage. You could build and test the whole thing by itself. Well, with the concept of this reusability and integration, you didn’t have anything until you had everything. There was no partial thing. There was nothing that was standalone. I remember we were trying to buy off-the-shelf
TACAN
s [Tactical Air Control and Navigation systems], an airplane navigational system, and as part of this integration process, rather than take the
TACAN
signal that an airplane generated in those days and used for navigation, we stripped it all out and put in all our own software so that this off-the-shelf
TACAN
box was absolutely unique. There was nothing else. And it was part of the philosophy of how we built this system.
4.
Possible configurations considered for the Space Shuttle, as of 1970. Courtesy
NASA
.
Despite the areas where the shuttle fell short of the original requirement-based specifications, Mattingly said
NASA
ended up with a very robust and versatile vehicle because of how ambitious the original discussions were. “At
the time we were doing this and putting all these requirements on there, we were actually, I think, quite proud of having had the foresight to look at all of these things. Today you can hardly think of a mission . . . you’d like it to do that it can’t do. It is an absolutely extraordinary engineering piece, just unbelievable. The shuttle really did fulfill almost all of the requirements that we were tasked to put into it.”
The shuttle went through a variety of widely different configurations during its early development. An inline version would have had the orbiter on top of a more traditional rocket booster, which would use parachute recovery to make it reusable. Another version would have had the orbiter launched atop essentially another space plane that would fly back to a ground landing site.
Discussions were held as to whether the primary fuel tank, which ended up being the external tank, should be inside the orbiter or not. There were trade-offs, according to Chris Kraft, the Johnson Space Center director at the time. Putting the tank inside the orbiter would have required that the orbiter be much larger but would have greatly increased the reusability of the shuttle system. However, Kraft said, the ultimate limitation was the difficulty of designing an integrated vehicle that wouldn’t suffer substantial damage to the fuel tank during landing.
Another major issue that had to be figured out early on was what sort of escape system should be provided for the crew. The Mercury and Apollo capsules both had powerful solid rocket motors in the escape towers at the top of the vehicle that would have been capable of lifting the spacecraft away from the booster in case of an emergency. “From the get-go, we tried desperately to put an abort system on the shuttle that would allow us to abort the crew and/or the orbiter off of a malfunctioning solid rocket or malfunctioning
SSME
s [Space Shuttle main engines],” Kraft said.
Originally we tried putting a solid rocket booster on the ass end of the orbiter, and the more we looked at that, the more we could not come up with a structural aerodynamic qualification and weight that would accomplish that job. We looked at putting a capsule in the structure of the crew cabin, making it something that would separate. We looked at the possibility of putting a capsule in the orbiter, at the structural problems of attaching a capsule, getting rid of the front end, making it strong enough, making it aerodynamically sound, building a control system that would allow it to descend under any and all Mach numbers. And we decided if we do that, we can’t build a Space Shuttle. We can’t afford the mass, and we don’t think we could build it in the first place.
So the answer to that question was, we will use the solid rockets that we have as our escape system and fly the orbiter back to the launch site if we have an abort. So we said to ourselves, the solid rockets have to, once you release them from the pad, bust those bolts on the pad, it has to be 100 percent reliable. And we always assumed it was, and any decision we made could not screw around the reliability of those solids. So our abort system was the solid rockets and a return to launch site,
RTLS
; you could fly that orbiter back.
5.
An early depiction of the Space Shuttle identifies major components as the orbiter, the three main engines, the external tank, and the two solid rocket boosters. Courtesy
NASA
.
Kraft said critics gave
NASA
a hard time about the shuttle not having an escape system. “I always thought that was unfair as hell,” Kraft said. “I don’t think they understood the system. And if you ask them over there [at
NASA
] today, I guarantee you won’t find five people who understand that’s what we did. But we did have an escape system, we had the solid rockets and the fly-back capability. Now, it didn’t save the
Challenger
, and nothing would have saved
Columbia
. But those two accidents were created by the fallacies of man, not by the machines.”
Recalled astronaut Charlie Bolden of the
RTLS
abort:
While a lot of us flew a lot of them in [simulation], I’m not sure any of us ever believed that that’s something you really wanted to do. This was a maneuver in which something goes wrong shortly after liftoff, and you decide you’re going to turn the vehicle around and fly it back to the Kennedy Space Center. And the computer’s got to do that, so the software really has to work. It’s crazy, because
you’re going upside down outbound, and all of a sudden you decide you’re going to go back to Kennedy. And while you’re still flying downrange, you take this vehicle and you pitch it back over so that it’s flying backwards through its own fire for several minutes. What has to happen is the computer has to calculate everything precisely, because it’s got to flip it over, have it pointing back to the Cape while it’s flying backwards, so that just before the solid rocket boosters burn out, it stops the backwards downrange travel and starts it flying back to the Cape. And then once that happens, then the solids cut off. They separate; they go their way, and then you fly back for a few minutes, for another six minutes, and the main engines cut off and you separate from the external tank. And that became a very tricky maneuver, because what you’re worried about was reimpacting with the tank, and if you did that, you were dead. So it’s a maneuver that . . . nobody ever wants to fly it, because just, it’s like, boy, this is really bad if you have to do this.
Once the general requirements were outlined from the mission baselines and the general type of vehicle was decided, work began on figuring out how exactly to design a spacecraft that would meet the requirements. Making the process particularly interesting was the fact that the shuttle was a collection of very diverse elements that had to be designed to work as an integrated system. The orbiter, for example, ended up with engines that, by itself, it couldn’t use because they had fuel only when the orbiter was connected to the external tank. The diameter of the external tank is another example of the integrated approach used in designing the entire shuttle system, according to retired
NASA
engineer Myron “Mike” Pessin, who spent the bulk of his career working with the external tank. Taken as a single element, there is no reason for the tank to have its 27.6-foot diameter. There was a constraint to the diameter of the solid rocket booster, however—it would have to be transported by rail from Utah to Florida, and so it was designed with a train’s dimensions in mind. That diameter determined the length of the boosters, which in turn established the range of locations for the explosive bolts that connected the boosters to the external tank. Given that engineers wanted to keep the connecting bolts off of the liquid hydrogen and liquid oxygen tanks inside the external tank, they were able to establish exactly how long the structure would need to be to make that possible. Since they knew how much fuel the tank would need to hold, they
could use the volume and the length to determine the needed diameter. Thus the diameter of the external tank was indirectly determined by the dimensions of the train that would be carrying the solids.
Another important part of the shuttle system design process involved computer technology that had evolved substantially since the development of
NASA
’s earlier manned space programs. “Now we get into the hard part of, okay, now we know the requirements, how do you make this all happen?” Mattingly said.
And that all settled down certainly after Skylab, and maybe even after
ASTP
[the Apollo-Soyuz Test Project]. Then we started working. I remember Phil Shaffer was designated as the lead for pulling together all of our software and stuff. Because the shuttle is such a highly integrated vehicle, it has the [software] architecture that makes the system run, and then it’s got all of the applications which are the heart of the vehicle. And so we were building all of this from scratch, and in Apollo we were astounded we had computers. I guess Gemini had a little computer, and then Apollo had something which, by today’s standards, your wristwatch is far more powerful than what we had those days. But we were still astounded with what you could do with these things. Now we were going to build this shuttle with these computers and they’re going to be its lifeblood. There won’t be a lot of direct wire. Everything goes on a data bus, and this was all relatively new for most of us.
It meant learning a whole new design process, and we learned that the software was the pacing item. We blamed it on software. When we think of developing software, we think of it as coding, “if/or” statements and counting bits, but in fact the massive amount of energy went center-wide into collecting the requirements—what does it have to do, write it down, and then see if you can package it, before anybody could start worrying about building. That was an extraordinary operation. Phil drove that thing. I’m sure if Phil hadn’t been there, there would have been somebody that could have done it, but I have a hard time imagining anybody that could have done it the way he did. He just had the extraordinary personality and insight. He knew all the key players from the Apollo days, and they just set out and they went to work, and they really made the program go.
In spite of all the delays that the shuttle program experienced—and we generally tended to blame that on truncated budgets, maybe some more money would have held the schedule a little better—the best I could tell, we were working as fast as
that group of people [could]. It was such a massive job, and it just took so long to get everybody educated up to the same level, because it was all integrated. I don’t think when we started anybody knew that it was going to be such a challenge, and so we learned to do those things and went through it. This doesn’t sound like a
CB
[Astronaut Office] perspective, but . . . a little more than half [of the astronauts] were working the engineering side, working on the development of these things and trying to look ahead to see what was going to be required as part of getting started.