Showing posts with label space systems engineering. Show all posts
Showing posts with label space systems engineering. Show all posts

Tuesday, July 10, 2012

Crisis in Outer Space! (The True Story of Apollo 13)


My 26th book will be Project: Impossible, an exploration of how people achieved goals any reasonable person would have thought impossible. This week, the true story of the the Apollo 13 mission, continuing last week’s brief history of rocketry and spaceflight. 


Thirteen

Although the United States officially “won” the space race with Apollo 11 on July 20, 1969, there would be five more missions to the Moon, during four of which astronauts walked on the lunar surface. The exception was Apollo 13, the seventh manned mission in the program.

Gordon Cooper and Donn Eisele, originally scheduled for Apollo 13, were passed over by NASA management. The flight crew operations chief selected Alan Shepard, the first American in space, to replace Cooper, but management turned him down because of recent surgery. As a result, NASA selected the backup crew for Apollo 11, who were scheduled for Apollo 14, for this mission. Jim Lovell, who had flown on two Gemini missions and one previous Apollo mission, was to be the mission commander. Fred Haise, a research test pilot, had been on two previous backup crews but had never flown in space. The command module pilot, who would stay in orbit while the other two crew members went down to the lunar surface, was Ken Mattingly. It would also be his first time in space.

Seven days before launch, Mattingly was exposed to measles (as it turned out, he didn’t get them), and was replaced by Jack Swigert from the backup team. It would also be Swigert’s first time in space.

The lead flight director, in overall command, was Gene Kranz.

Crisis in Outer Space

Liftoff for the Apollo 13 mission came on April 11, 1970, at 13:13 Central Standard Time. There was a small hiccup during the launch: the center engine in the second stage had to be shut down early because of a malfunction known as “pogo oscillation.” It had been seen in previous missions, but never so seriously. Automatic cut-offs stopped the problem before it could tear the ship apart; later missions had technical modifications to prevent a reoccurrence. In any event, the remaining engines burned longer, and the vehicle continued to a successful orbit.

Such a problem was hardly unusual. Given the complexity and inherent risk of any space mission, it would have been far more notable had the flight gone off without a hitch. Solving problems was all in a day’s work for NASA’s talented and experienced people.

But what happened next tested their capabilities to the maximum.

About 56 hours after takeoff, with Apollo 13 much closer to the Moon than to the Earth, Mission Control radioed Jack Swigert and asked him to turn on the stirring fans for the hydrogen and oxygen tanks. About a minute and a half later, there was a loud bang. The crew’s first thought was that the lunar module had been struck by a meteoroid.

What had happened was actually much worse. Number 2 oxygen tank had exploded. Later analysis would reveal damaged insulation on the wires to the stirring fan, allowing a short circuit. A large aluminum skin panel on the outside of the ship blew off, damaging an antenna and momentarily interrupting communication with Mission Control. The shock of the explosion caused a break in the number 1 oxygen tank as well. Over the next two hours, the entire oxygen supply of the service module was lost. Complicating matters even more, the fuel cells needed oxygen and hydrogen to generate electricity. The command module was left with backup battery power only.

The damaged Apollo 13 spacecraft


Landing on the Moon was no longer an option. The crew hastily shut down the command module to save its limited power and moved into the lunar module. The new project was how to get the crew back safely to Earth.

What saved the Apollo 13 mission?

The Kranz Dictum

It’s only in the movie version of Apollo 13 that Gene Kranz says the phrase, “Failure is not an option.” The real message came after the 1967 Apollo 1 disaster, in which astronauts Virgin “Gus” Grissom, Edward H. White, and Roger B. Chaffee lost their lives, Gene Krantz addressed his flight control team, establishing what would become known as “The Kranz Dictum.”
Spaceflight will never tolerate carelessness, incapacity, and neglect. Somewhere, somehow, we screwed up. It could have been in design, build, or test. Whatever it was, we should have caught it. 
We were too gung ho about the schedule and we locked out all of the problems we saw each day in our work. Every element of the program was in trouble and so were we. The simulators were not working, Mission Control was behind in virtually every area, and the flight and test procedures changed daily. Nothing we did had any shelf life. Not one of us stood up and said, “Dammit, stop!”
I don't know what Thompson's committee will find as the cause, but I know what I find. We are the cause! We were not ready! We did not do our job. We were rolling the dice, hoping that things would come together by launch day, when in our hearts we knew it would take a miracle. We were pushing the schedule and betting that the Cape would slip before we did. 
 
From this day forward, Flight Control will be known by two words: “Tough and Competent.” Tough means we are forever accountable for what we do or what we fail to do. We will never again compromise our responsibilities. Every time we walk into Mission Control we will know what we stand for. 
Competent means we will never take anything for granted. We will never be found short in our knowledge and in our skills. Mission Control will be perfect. 
 
When you leave this meeting today you will go to your office and the first thing you will do there is to write “Tough and Competent” on your blackboards. It will never be erased. Each day when you enter the room these words will remind you of the price paid by Grissom, White, and Chaffee. These words are the price of admission to the ranks of Mission Control.

The Apollo flight teams had prepared for disaster time and time again. Exercises, simulations, and extensive training all went into achieving the goal of “tough and competent.” This is an essential ingredient in effective crisis management. By preparing for different eventualities and maintaining a high level of readiness, you and your team are in the best possible position to handle a crisis.

However, no matter how good you are, failure is always an option.


Timeline of the events in the Apollo 13 crisis


Working the Problems

Crises differ from more general projects in several ways. First, they are often imposed on the project team with little or no notice. Apollo 13 was going well until suddenly it wasn’t. Crises normally have extreme constraints in time and resources. The clock was ticking with Apollo 13. If problems could not be solved in very short order, the consequences would take hold at once — with fatal results.

While NASA had an extensive supply of spare parts, machine shops, and trained engineers who could have fixed the ship easily, those resources were on Earth, and the problem was more than a hundred thousand miles away.

Evacuating and shutting down the command module was the first order of business, but there were many obstacles yet to be overcome before the crew of Apollo 13 would once again see home. There were plans for aborting an Apollo mission, but some of them were ruled out by the exigencies of the situation. The quickest way home required jettisoning the lunar module, but that was serving as the lifeboat for the crew. The service module integrity was in doubt, so they didn’t want to fire its engine except as a last resort.

That left a circumlunar option, using the Moon’s gravity as a slingshot to send the crippled ship back toward earth. To do that, they needed to make a minor course correction, but debris from the explosion made it impossible to use the onboard sextant device, requiring Jim Lovell to fly the spacecraft using the sun in the cockpit window as an alignment star.

The problems mounted. While there was plenty of oxygen in the lunar module, carbon dioxide removal required the use of lithium hydroxide canisters. While there were enough of them available, the square command module canisters wouldn’t fit in the round LM openings. An engineering team created a kludged-together system using plastic bags, cardboard, and tape, working on an extremely limited time span.

(As an aside, the duct tape and other supplies that made this possible were also part of planning for crisis management: there was a kit containing some basic utility items available for use. One can only imagine the planning that went into deciding exactly what would be part of that kit.)

Power supplies were limited. The LM was rated for two people for a day and a half, and now it would need to accommodate three people for four days. All nonessential power was shut down. Water and food were limited. The crew became dehydrated. Lovell lost 14 pounds.

The team managed to overcome one problem after another, but the toughest technical challenge came at the end of the mission. There had never been a case where the command module had to be powered up after a long sleep, and the flight controllers had to test and write new procedures to accomplish it. (In the movie, that’s the suspenseful scene in which Ken Mattingly, played by Gary Sinise, tries to find a start-up sequence that draws less than 20 watts.) The normal time for a project like that was three months; the team had three days.

By the time the Apollo 13 team reentered the command module, condensation had covered the interior with fine droplets of water. Water was inside the circuit panels as well, and the chance of a short circuit was all too real. Fortunately, the tragedy of Apollo 1 had led to various safeguards against short circuits; there was no problem.

Four hours before landing, the crew jettisoned the service module, and one hour before landing they jettisoned the LM that had served as their lifeboat. As they entered the atmosphere, the heat of reentry created rain inside the command module.

But that was the final hazard.

On April 17, 1970, Apollo 13 splashed down safely near American Samoa.

Apollo 13 Mission Control right after splashdown


Crisis Management and the Impossible Project

What distinguishes a crisis from other kinds of projects is the way it tightens the constraints. Time pressure is normally high, and the nature of the situation normally limits resources that would otherwise be available to the team. These revised constraints are normally established by the situation, not by the will or desire of the project team. In the case of Apollo 13, a procedure that would normally take three months had to be developed in three days, for the simple reason that three days was all they had. Modifying the carbon dioxide removal system would have been trivial on Earth; it was a nail-biting project in space, with only the resources available on the ship able to be used for the job.

Had the mission control team not been well prepared — had Gene Kranz not insisted on “tough and competent” — had simulations by the hundreds not taken place, it’s almost certain that the Apollo 13 mission would have ended in failure.

But that’s the point. To prepare for crisis, prepare early.

By the time the crisis occurs, it’s usually too late.

Tuesday, April 3, 2012

Some Notes About Decision Making

Some of this material appears in my chapter in Applied Space Systems Engineering: Space Technology Series, which I wrote a few years ago. While originally aimed at making mission-critical decision in a complex engineering environment, some of the ideas are more generally applicable.



“A decision,” wrote author Fletcher Knebel, “is what a man makes when he can’t find anybody to serve on a committee.”

Committees and teamwork are often an essential part of decision-making, but even in that framework, each of us must sooner or later take our stand, knowing full well the range of potential consequences. In an organization, a decision-making process must often be open and auditable. We must know not only the decision we make, but also the process that led us to that decision.

Decisions often require tradeoffs. A perfect solution may not exist. Each potential choice may have a downside, or may be fraught with risk. In some ways, making the least bad choice out of a set of poor alternatives takes greater skill and courage than making a conventionally “good” decision. Napoleon Bonaparte observed, “Nothing is more difficult, and therefore more precious, than being able to decide.”

The outcome of a decision, whether positive or negative, is not in itself proof of the decision’s quality, especially where probability is concerned. The odds may be dramatically in favor of a positive outcome, yet the dice may come up boxcars. Equally, if someone makes a stupid decision but gets lucky, the decision is no less stupid in spite of a good outcome. A good decision process improves our odds and results in the desired outcome the majority of the time.

Decision-making is tightly woven into the risk management process, but one does not follow automatically from another. An engineering evaluation might tell us that there is a 42% probability of an event happening, and that the consequence involves the loss of $20 million and three lives. What the evaluation does not tell us is whether the risk is worth running. Values—organizational values, mission-related values, ethical values—address the consideration of worth.

There are two types of complexity in decision-making. The first, and most obvious, is the technical complexity of the issue and the tradeoffs that may be required. The second, though not always openly addressed, is the organizational complexity: the number of people involved, the number of departments or workgroups that must be consulted, the existing relationships that shape communication among people and groups, the organizational culture, and the pressure of the political process.

Decisions also vary in their importance. Importance can be measured in terms of the consequences of the decision and the constraints imposed on the decision process.

There are two slogans about decision-making: “Don’t just stand there, do something!” and its reverse, “Don’t just do something, stand there!” Both can be worthwhile pieces of advice; the trick is deciding which philosophy applies to the decision at hand. The first question is whether an actual problem exists, and, if so, the nature of that problem. The second is whether an action should be taken, and if so, the nature of that action.

At different times in the decision-making process, consider the opportunities as well as the negative consequences that can result both from the decision to act and from the decision to wait. If the consequences of a missed opportunity are greater, then the appropriate bias is in the direction of action. If an inappropriate decision could cause greater harm, the bias should fall in the direction of delay: gather more information and reassess.

Threats and opportunities both require proactive management, but opportunities even more so. Good luck and bad luck operate differently. If a person, say, loses $100, it’s gone, and all the consequences of that loss flow automatically. If, on the other hand, there’s a $100 bill somewhere in the area, it’s possible to miss it, there is no requirement to pick it up, and no obligation to spend it wisely. Exploiting opportunity requires observation, initiative, and wisdom.

A good process does not necessarily result in a good consequence. Predicting the future is never an exact science, especially when probabilities are involved. Evaluate the decision process separately from the decision outcome. Hindsight is a useful tool, though teams must remember that what seems so clear in light of actual events looked different to the decision-makers.

Monday, June 20, 2011

Decisions, Decisions

Decision makers are faced with a host of challenges. Critical information may be unavailable. Certainty may be unobtainable. Consequences may be catastrophic. Conflicting stakeholder desires may be incompatible. And always, the clock is ticking. As a result, people too often try to avoid difficult choices altogether, become trapped in “analysis paralysis,” or pass the hot potato to someone else. The BOGGSAT process (“Bunch of Guys and Gals Sitting Around Talking”) is all too popular. While sitting around and talking may well be part of a decision-making process, a proper structure (not to mention selecting the right “bunch of guys and gals”) is necessary.

The twin challenges of risk and uncertainty complicate the process. In classical risk, we know the probability and impact of the various outcomes. Risk management involves (a) an assessment of the risk, including the probability of its occurrence and the consequence if it does occur, and (b) a decision on what action to take in response to that risk (avoid, mitigate, transfer, or accept for threat risks, and exploit, enhance, share or accept for opportunity risks). In project management, the fundamental characteristics of “temporary and unique” [PMBOK® Guide] mean that we don’t necessarily know the range of possible outcomes, and almost never have reliable probability information.

Critical decision-making information is often subjective and values-driven. An engineering evaluation might tell us that there is a 42% probability of an event happening, and that the consequence involves the loss of $21.6 million and three lives. What such an evaluation does not tell us is whether the risk is worth running. Values—organizational values, mission-related values, ethical values—address the consideration of worth. Some of these values are assumed and implicit. Some can be quantified, and others—usually political considerations—can’t even be discussed on the record.

Decisions often require tradeoffs. A perfect solution may not exist. Each potential choice may have a downside, or may be fraught with risk or uncertainty. In some ways, making the least bad choice out of a set of poor alternatives takes greater skill and courage than making a conventionally “good” decision.

The outcome of a decision, whether positive or negative, is not in itself proof of the decision’s quality, especially where probability is concerned. The odds may be dramatically in favor of a positive outcome, yet low probability events can occur. Equally, if someone makes a stupid decision but gets lucky, the decision is no less stupid in spite of a good outcome. A good decision process improves our odds and results in the desired outcome the majority of the time.

In addition, a decision-making process must often be open and auditable. We must know not only the decision we make, but also the process that led us to that decision. If the outcome is bad, someone else (a boss, a customer, a Congressional committee) determines—with the benefit of “20-20 hindsight”—whether your decision was reasonable and appropriate.

This leads to the rational (if not always appropriate) strategy known as “CYA” (cover your assets), where the decision is made not necessarily from a mission perspective, but in a way that ensures blame and punishment will fall elsewhere in the event of a bad outcome. “A decision,” wrote author Fletcher Knebel, “is what a man makes when he can’t find anybody to serve on a committee.”

If enough time and resources are available, even the most complex problems can be structured and studied in a way that leads to an optimal decision. When time and resources are not available, however, a decision still needs to be made, and your accountability remains unchanged. There’s the story of the person who called an attorney, who listened to the situation and said, “Don’t worry, they can’t put you in jail for that.” The person replied, “But counselor, I’m calling from the jail!”

No formal process or methodology can remove all risk from decision-making. Many tools and techniques can improve decision-making, but ultimately successful decision processes require good judgment. Good judgment comes from experience combined with wisdom. Experience can come from bad judgment. While wisdom is the product of experience, experience does not automatically confer wisdom.


Adapted from "Chapter 18, Decision-Making and Analysis," by Michael S. Dobson, Paul Componation, and Ted Leemann, in Applied Project Management for Space Systems (Space Technology Series), edited by Julie Chelsey, Wiley Larson, Marilyn McQuade, and Robert Menrad, McGraw-Hill/US Air Force Academy, 2008.