The document summarizes the timeline and technical challenges faced by NASA in determining the flight readiness of the Space Shuttle following a malfunction with a main engine valve during launch. Teams worked to understand the failure mechanism, potential risks, and establish acceptable flight rationale. After two initial Flight Readiness Reviews were inconclusive, continued testing and analysis eventually provided the necessary insights. The third review approved the next launch, which proceeded safely. Key lessons included the importance of diverse perspectives, challenging assumptions, and creating an environment where issues can be raised without fear.
The Challenger Disaster A Case-study in Engineering Ethics.docxmamanda2
The Challenger Disaster
A Case-study in Engineering Ethics
• Shuttle Components
– Orbiter
– Liquid Rocket
Booster
– Solid Rocket
Booster
Shuttle Components
Chronology of the Related Events
• 1974
– NASA contracts Morton Thiokol
• 1976
– NASA accepts the design based on the Titan
missiles
– The joints are sealed by
• Two synthetic rubber O-rings,
• 177 clevis pins,
• Heat shield putty
The Cause of the Disaster
Early Problems
• 1977
– Tests at Thiokol show O-ring leakage
– Joint is made stronger by changing sizes
• 1981
– Post-launch investigation showed O-ring
erosion due to hot gages.
Early Problems
• January of 1985 launch
– First cold-weather launch
– Post-launch investigation showed joint failure
– Tests showed O-rings inability to fill the gap
due to joint rotation at lower temperatures
Early Problems
• July 1985
– Thiokol redesigns the joints w/o O-rings – The
design was not ready for Challenger launch
Political Climate
• Congress is unhappy with NASA
• Competition with Russians to be the first to
observe Halley’s comet.
• Pressure to launch before President
Reagan’s State of the Union Address
Days before Launch
• First launch attempt postponed
• The next launch date was set and was to be
attended by Vice President Bush.
• The temperature at launch: 29 degrees F.
Days Before Launch
• NASA starts an investigation of the effect
of low temperatures on the O-ring seals
• Organization involved
– NASA
– Marshall Space Flight Center
– Morton Thiokol
Engineering Investigation Before
Launch
• Players at NASA
– Larry Mulloy: SRB Project Manager at Marshall
• Players at Thiokol
– Roger Boisjoly: A SRB engineer
– Arnie Johnson: A SRB engineer
– Joe Kilminster: SRB engineering manager
– Alan McDonald: SRB engineering director
– Bob Lund: Vice president for engineering
– Jerald Mason: General manager
Engineering Investigation Before
Launch
• Boisjoly and Johnson recommend the
launch to be postponed.
• Bob Lund, the VP for engineering agrees
and makes a similar recommendation.
Investigation Before Launch
• Larry Mulloy, the NASA manager of SRB
asks Joe Kilminister, the SRB manager at
Thiokol, for his opinion.
• Kilminister agrees with other Thiokol
engineers and recommends a launch delay.
Investigation Before Launch
• After discussion with Mason
• Lund reverses his decision regarding
launch!
• Thiokol recommend the launch to proceed
The Launch in January 1986
• The overnight temperatures drop to 8 F
• The temperature of SRB at launch is 28 F
• There is an immediate blow-by of hot gas at
launch. The seal fails quickly over an arc of
70 degrees.
The Launch in January 1986
• The by-products of combustion forms a
glassy oxide that reseals the joint.
• The brittle oxide is shattered
• Hot gases quickly burn through.
The Challenger Disaster A Case-study in Engineering Ethics.docxmamanda2
The Challenger Disaster
A Case-study in Engineering Ethics
• Shuttle Components
– Orbiter
– Liquid Rocket
Booster
– Solid Rocket
Booster
Shuttle Components
Chronology of the Related Events
• 1974
– NASA contracts Morton Thiokol
• 1976
– NASA accepts the design based on the Titan
missiles
– The joints are sealed by
• Two synthetic rubber O-rings,
• 177 clevis pins,
• Heat shield putty
The Cause of the Disaster
Early Problems
• 1977
– Tests at Thiokol show O-ring leakage
– Joint is made stronger by changing sizes
• 1981
– Post-launch investigation showed O-ring
erosion due to hot gages.
Early Problems
• January of 1985 launch
– First cold-weather launch
– Post-launch investigation showed joint failure
– Tests showed O-rings inability to fill the gap
due to joint rotation at lower temperatures
Early Problems
• July 1985
– Thiokol redesigns the joints w/o O-rings – The
design was not ready for Challenger launch
Political Climate
• Congress is unhappy with NASA
• Competition with Russians to be the first to
observe Halley’s comet.
• Pressure to launch before President
Reagan’s State of the Union Address
Days before Launch
• First launch attempt postponed
• The next launch date was set and was to be
attended by Vice President Bush.
• The temperature at launch: 29 degrees F.
Days Before Launch
• NASA starts an investigation of the effect
of low temperatures on the O-ring seals
• Organization involved
– NASA
– Marshall Space Flight Center
– Morton Thiokol
Engineering Investigation Before
Launch
• Players at NASA
– Larry Mulloy: SRB Project Manager at Marshall
• Players at Thiokol
– Roger Boisjoly: A SRB engineer
– Arnie Johnson: A SRB engineer
– Joe Kilminster: SRB engineering manager
– Alan McDonald: SRB engineering director
– Bob Lund: Vice president for engineering
– Jerald Mason: General manager
Engineering Investigation Before
Launch
• Boisjoly and Johnson recommend the
launch to be postponed.
• Bob Lund, the VP for engineering agrees
and makes a similar recommendation.
Investigation Before Launch
• Larry Mulloy, the NASA manager of SRB
asks Joe Kilminister, the SRB manager at
Thiokol, for his opinion.
• Kilminister agrees with other Thiokol
engineers and recommends a launch delay.
Investigation Before Launch
• After discussion with Mason
• Lund reverses his decision regarding
launch!
• Thiokol recommend the launch to proceed
The Launch in January 1986
• The overnight temperatures drop to 8 F
• The temperature of SRB at launch is 28 F
• There is an immediate blow-by of hot gas at
launch. The seal fails quickly over an arc of
70 degrees.
The Launch in January 1986
• The by-products of combustion forms a
glassy oxide that reseals the joint.
• The brittle oxide is shattered
• Hot gases quickly burn through.
Reality and Nature . . . The Challenger Disaster RevisitedKurt D. Hamman
The Space Shuttle Challenger disaster occurred on January 28, 1986, when Space Shuttle Challenger broke apart 73 seconds into its flight, leading to the deaths of its seven crew members. The spacecraft disintegrated over the Atlantic Ocean, off the coast of central Florida at 11:38 EST. Disintegration of the entire vehicle began after an O-ring seal in its right solid rocket booster (SRB) failed at liftoff.
Testing Hyper-Complex Systems: What Can We Know? What Can We Claim?TechWell
Throughout history, people have built systems of dramatically increasing complexity. In simpler systems, defects at the micro level are mitigated by the macro level structure. In complex systems, failures at the micro level cannot be compensated for at a higher level, often with catastrophic results. Lee Copeland says that we are building hyper-complex computer systems—so complex that faults can create totally unpredictable behaviors. For example, systems based on the service-oriented architecture (SOA) model can be dynamically composed of reusable services of unknown quality, created by multiple organizations, and communicating through many technologies across the unpredictable Internet. Lee explains that claims about quality require knowledge of test “coverage,” which is an unknowable quantity in hyper-complex systems. Join Lee for a look at your testing future as he describes new approaches needed to measure test coverage in these hyper-complex systems and lead your organization to better quality—despite the challenges.
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
Elevating Tactical DDD Patterns Through Object CalisthenicsDorra BARTAGUIZ
After immersing yourself in the blue book and its red counterpart, attending DDD-focused conferences, and applying tactical patterns, you're left with a crucial question: How do I ensure my design is effective? Tactical patterns within Domain-Driven Design (DDD) serve as guiding principles for creating clear and manageable domain models. However, achieving success with these patterns requires additional guidance. Interestingly, we've observed that a set of constraints initially designed for training purposes remarkably aligns with effective pattern implementation, offering a more ‘mechanical’ approach. Let's explore together how Object Calisthenics can elevate the design of your tactical DDD patterns, offering concrete help for those venturing into DDD for the first time!
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...Jeffrey Haguewood
Sidekick Solutions uses Bonterra Impact Management (fka Social Solutions Apricot) and automation solutions to integrate data for business workflows.
We believe integration and automation are essential to user experience and the promise of efficient work through technology. Automation is the critical ingredient to realizing that full vision. We develop integration products and services for Bonterra Case Management software to support the deployment of automations for a variety of use cases.
This video focuses on the notifications, alerts, and approval requests using Slack for Bonterra Impact Management. The solutions covered in this webinar can also be deployed for Microsoft Teams.
Interested in deploying notification automations for Bonterra Impact Management? Contact us at sales@sidekicksolutionsllc.com to discuss next steps.
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf91mobiles
91mobiles recently conducted a Smart TV Buyer Insights Survey in which we asked over 3,000 respondents about the TV they own, aspects they look at on a new TV, and their TV buying preferences.
Securing your Kubernetes cluster_ a step-by-step guide to success !KatiaHIMEUR1
Today, after several years of existence, an extremely active community and an ultra-dynamic ecosystem, Kubernetes has established itself as the de facto standard in container orchestration. Thanks to a wide range of managed services, it has never been so easy to set up a ready-to-use Kubernetes cluster.
However, this ease of use means that the subject of security in Kubernetes is often left for later, or even neglected. This exposes companies to significant risks.
In this talk, I'll show you step-by-step how to secure your Kubernetes cluster for greater peace of mind and reliability.
UiPath Test Automation using UiPath Test Suite series, part 3DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 3. In this session, we will cover desktop automation along with UI automation.
Topics covered:
UI automation Introduction,
UI automation Sample
Desktop automation flow
Pradeep Chinnala, Senior Consultant Automation Developer @WonderBotz and UiPath MVP
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...Ramesh Iyer
In today's fast-changing business world, Companies that adapt and embrace new ideas often need help to keep up with the competition. However, fostering a culture of innovation takes much work. It takes vision, leadership and willingness to take risks in the right proportion. Sachin Dev Duggal, co-founder of Builder.ai, has perfected the art of this balance, creating a company culture where creativity and growth are nurtured at each stage.
From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...
Ryschk wow
1. Poppet Learnings
Chris singer
Deputy Director Engineering MSFC
Mike Ryschkewitsch,
NASA Chief Engineer
PM Challenge
February 10, 2010
2. FCV Timeline
•On November 14, 2008 during the launch of STS-126, flight controllers monitoring data
during the ascent noted an unexpected hydrogen flow increase from one of the
shuttle’s main engines.
•The likely causes of the malfunction were either an electrical failure or a mechanical failure,
which might have resulted from a broken valve.
• At least on paper the consequences could be really bad
•Over-presurization of the LH2 tank
•Starvation of the turbopump leading to catastrophic overspeed
•The shuttle touched down at Edwards Air Force Base on November 30 after
unfavorable weather conditions at Kennedy Space Center (KSC).
•This delayed work until December 12, when the shuttle was ferried back to KSC aboard a
specially equipped 747.
•The next launch, STS-119, was scheduled for February 12, 2009. STS-119 to launch
prior to mid March so that it would not interfere with the March 26 mission of the
Russian Soyuz to transport the Expedition 19 crew to the ISS and avoid impacts to the
long term manifest, crew safety and consumable margins.
•A x-ray taken December 19 showed evidence of a problem with a poppet in the valve.
Inspection determined that a fragment had broken off the poppet, the first time such a
problem had occurred during flight. In 27 years, the shuttle program had never
experienced a valve failure like this.
3.
4. A Tough Technical Problem
• Analysis of the cracked valve showed that the failure resulted from high-cycle
fatigue.
– This raised the question if STS-126 had presented an unusual environment, or if another valve was
likely to break in flight due to fatigue-related damage.
– What was the likelihood of another broken valve?
– What would be the worst-case consequences of a break?
– Need to determine the probable size and the maximum size of a loose particle, understand how it
would move through the propulsion system, and what the system could tolerate without
experiencing a potentially catastrophic rupture in its lines.
• Several teams worked on the problem from multiple angles, including materials,
structural dynamics, computational fluid dynamics (CFD), and fracture mechanics.
The initial efforts relied on visual inspection and a number of non-destructive
evaluation (NDE) techniques,
– Electron microscopy could only discover small cracks after the poppet was polished, however, and
that polishing invalidated the flight certification of the hardware even as it provided greater ability to
inspect it.
– One NDE technique that was initially dismissed was the use of an eddy current system because the
size of the probe head was too large for the hardware.
5. February 3, 2009: Flight Readiness Review #1
• Significant work remained to be done before sound flight
rationale could be established.
– three different lines of impact testing to learn more about whether a particle
would puncture the propulsion line.
– material properties of the flight hardware and the impact of particles striking
the material at a certain velocity and orientation
– test stand that fired particles through a full-scale mock-up of the propulsion
system within the External Tank and a similar effort focusing on the Orbiter
part of the system near the flow control valve FCV exit.
– Computational fluid dynamics (CFD) analysts improved their characterizations
of the environment inside the propulsion line --velocity and spin and probable
path
– Fracture analysis to understand the release mechanism
– Systems safety analysis to understand consequences
6. February 20, 2009: Flight Readiness Review #2
• Re-synching the team - understanding the risks and what we
new
– session lasted nearly fourteen long hours, and the outcome was not clear until
the end.
– more of a technical review than typical Flight Readiness Review
– Different people had different opinions about what the data meant, and they
were able to voice that in that forum with enthusiastic debate
– Significant discussions about all technical attributes
– Significant discussions about the risks in other areas if we didn’t fly
• Determination that we didn’t know enough yet about either
the likelihood or the consequence to understand the flight risk
or understand the risk balance
• “One of the key tenets of flight rationale that most individuals
and organizations were looking for was a maximum bound on
the potential particle release size. “
7. Picking up the challenge
• At the end of the second FRR people were drained and it wasn’t clear that
we could come to resolution quickly.
• Gerstenmaier -“Rather than make the decision to go move somewhat
arbitrarily at this point based on the data, I decided to go ahead and kick
it back to the team, give them the action, see what they can go do and see
how it comes out.”
• The team attitude shifted ‘We cannot let this opportunity go by us if there
is any responsible, technical way to fly this. What can we do? We will not
accept not being able to make this window—we will find a way to do this
and still be able to stand up and say ‘this is technically right.’
• The testing and analysis continued on all fronts. At the peak, roughly one
thousand people were working to solve the problem.
8. Breaking through
• “One of the key tenets of flight rationale that most individuals and
organizations were looking for was a maximum bound on the potential
particle release size. This action had been in work for some time, but
proved to be a difficult problem to solve. We knew this answer was
important and would play hand in hand with the other elements of flight
rationale especially in understanding the consequence and risk of release,”
-- John McManamen.
• MSFC and JSC NDE experts developed a variant of the eddy current
technique that could “see” small cracks without polishing
• Fracture analysis team used all the previous results plus the new NDE
insights to determine the maximum likely particle size
• Combined results allowed understanding of the likelihood and
consequences and an acceptable flight rationale
9. March 6, 2009: Flight Readiness Review #3
• Bryan O’Connor – “We had a great deal of understanding of not
only what we knew about, but what we didn’t know about. We had a good
understanding of the limits of our knowledge as much as possible,
whereas before we didn’t know what those were.”
– Test data and analyses had been thoroughly vetted
– NDE allowed for crack screening
– Testing and analysis showed the likelihood of liberation
– Maximum particle size was understood
– Effects on the plumbing was understood
– Consequences of a plumbing rupture were understood
• Problem was handled in an end to end probabilistic sense –
– No one piece of “killer” data but each part allowed understanding of the risk
associated with it and the uncertainty of the understanding
• STS-119 was approved to proceed to launch and after delays
due to unrelated problems launched safely on March 15,
2009.
11. Takeaways
• “Learning how to create some alternate trade space for this very
disciplined engineering rigorous community is an art, but it’s definitely
worth doing. We fly complex systems and the rigor usually works, but
sometimes we have to have a little different trade space. It takes some
special people who have some multi-discipline experience to be able to
start creating that trade space.” -- Chris Singer, Deputy Director of
Engineering, Marshall Space Flight Center
• Steve Altemus thought Koshti’s NDE efforts exemplified the engineering
curiosity that NASA needs to succeed, and he viewed it as an engineering
leadership responsibility to create an environment in which new and
diverse ideas could receive a fair hearing. “It’s important to recognize that
we’re not always the smartest one in the room, that perhaps there’s
somebody over there in the corner of the room, and that we have to pull
out of them what their thoughts are, because they’ve got the answer. He
had the answer.”
12. Takeaways
• Bill McArthur, Safety and Mission Assurance Manager for the Space
Shuttle at the time, said, “The fact that people were willing to stand up
and say ‘We just aren’t ready yet,’ is a real testament to the fact that our
culture has evolved so that we weren’t overwhelmed with launch fever,
and people were willing to tell Bill Gerstenmaier, ‘No, we’re no-go for
launch.’”
• As the participants filed out of the meeting, Joyce Seriale-Grush said to
Mike Ryschkewitsch, “This was really hard and I’m disappointed that we
didn’t have the data today, but it feels so much better than it used to feel,
because we had to say that we weren’t ready and people listened to us. It
didn’t always used to be that way.”
13. Takeaways
• “As a leader, it’s my responsibility to create an environment that is open to
ideas and diverse perspectives, to say, ‘Hey, I’m not necessarily the
smartest guy, show me what you know,’ and then be able to act on it and
get an audience so that the broader community understands there’s a
good solution out there.” - Steve Altemus, Director of Engineering,
Johnson Space Center
• You have to worry that your team might play “clump ball”
– When the team is focused on a really tough problem, what else is out there that we are
not watching?
• The context of other risks is important but can’t be the overwhelming
driver
– It was important to know what risks were being pushed to other places but they can’t be
allowed to drive the conclusion to rationalization as opposed to rationale
14. Takeaways
• “The one thing I would take away from this effort is that NASA can solve
any problem if the right experts are involved and that Centers with
different perspectives and cultures can work extremely well together. To
have developed flight rationale for this problem with only a one month
delay to the STS-119 mission, while preserving the rest of the manifest
was truly an amazing feat by this incredibly talented team. In retrospect,
as the Orbiter Project Manager, I should have enlisted the assistance of
the materials experts from the MSFC much earlier in the process, since
ultimately they had the proper expertise to deal with high cycle fatigue.
Additionally, we should have established a better mechanism for
establishing communication of fast developing information from the
beginning of this failure investigation so that the entire team could remain
equally informed.” - Steve Stich, Orbiter Project Manager
15. Takeaways
• Leaders must actively create “space” for safe communication
– May be small groups –virtual or physical
– May be expectation in large groups that discourse and disagreement are not
only OK but needed
• When people are made to feel they own the problem, you get not only
constructive dialogue but increased commitment to finding a way forward
• “Gerst [FRR chairman Bill Gerstenmaier] was absolutely open. He never
tried to shut them [the participants] down. Even though he could
probably tell this wasgoing to take a long time, he never let the clock of
the day appear to be something that he was worried about. I thought,
that’s bad in one way, it says we’re probably going to have a long day, but
it’s good in another, and that says that you don’t have the chairman of this
panel putting undo pressure on people to sit down or be quiet,” - Bryan
O’Connor .
16. Takeaways
• Two months after the completion of the mission, Bill Gerstenmaier,
Associate Administrator for Space Operations spoke to students at
Massachusetts Institute of Technology (MIT) about the flow control valve
issue. In an email to Shuttle team members, he shared a video of the
lecture and wrote, "I am in continue to learn mode. There is always room
to improve.” “I had better be empowering and I had better be motivating
folks to stay hungry…to keep digging, keep looking, and figure out what
the heck is really going on if I want a good decision.”