

Cluster (spacecraft) - PiersonBro
http://en.wikipedia.org/wiki/Cluster_(spacecraft)

======
spuz
Though there are many factors leading up to the failure listed in the article,
I think the most serious one was not testing the system under the expected
flight conditions. It seems like such a big oversight that I wouldn't be
surprised if there were other bugs lurking in the system that had also gone
undetected.

------
alexsb92
Maybe someone more knowledgeable about these things can answer this for me:
when they say that this resulted in the loss of $370 million, is that number
the entire mission cost or simply the actual rocket plus Cluster cost? I
imagine the r&d cost far outweighs the cost of the actual build. I've been
wondering at the same time why we don't send another one or two rovers to mars
based on the design of curiosity seeing how it worked, as how expensive would
the entire build be to replicate considering there's no more r&d costs?

~~~
akiselev
Modern space programs operate on a skewed risk tolerance mostly for public
relations purposes. Given a billion dollar program with a $250 million final
build and launch cost, NASA and ESA will chose to spend $750 million on R&D
and launch one mission with a 95% success chance instead of $500 million on
R&D and two missions with a 80-90% success chance (money spent on R&D has
rapid diminishing returns on the success rate of satellites, whether you're
talking about CubeSats or billion dollar satellite arrays, and two launches at
80% has a 96% success chance). NASA knows that most projects (Mars Science Lab
excluded) can be done such that the budget pays for two launches instead of
one by spending money on cheaper components (a single CPU made specifically
for high radiation environments is like $1mil+) but when it comes to public
perception, 2 failed launches sounds better than 3 or 4 (despite the fact that
the latter would mean 6-7 successful launches versus 3-4 for the former).

The $370 million was probably the cost of the four satellites and the rocket +
operations. It might include R&D but not most of the scientific operations
part of the grant (there is tons of science to do before and after a
scientific mission like this).

~~~
mturmon
You're making some broad-brush proclamations here that are wrong. I think you
have a point regarding the risk tolerance of some NASA missions, but you're
exaggerating too much, and your comment can't be taken seriously as a result.

I don't want to thoroughly engage all the problems with your comment, but I'll
point out two: (1) Launching two spacecraft is not a cure for poor system
reliability. Systems fail after launch for all kinds of reasons; a 1-in-2
launch success rate and 2 launches does not guarantee a successful mission.
You can't build systems that are half reliable and half not. (2) Some things
really have to work on the first try: Earth and sun-observing systems that
need data continuity with failing earlier systems, planetary missions with
narrow launch windows, systems with standing armies of on-ground analysis
personnel who can't be put on hold while a replacement is built and launched.

~~~
akiselev
1) I'm not talking about stripping the budget willy-nilly but relaxing the
risk-tolerance that goes into making the calculations for the reliability
budget across the board. A trivial example from my own experience is in
working on a Cubesat thermal system. There were a lot of trade offs that we
had to make like whether to use cheap thermal tape or use some expensive
quartz reflective panels or whether to just slap a heat sink on something or
use a peltier cooler. Each trade off could drastically change the cost of the
final build and the cost of R&D time and equipment. For a Cubesat, the added
up differences wouldn't cover the cost of a second launch but I would expect
there to be major trade offs to be made that wouldn't totally compromise the
mission in larger projects.

2) I fully agree, and there are many missions that are just so important that
we should strive for success on the first try (MSL, some extremely better
telescope like NuStar, and probably the satellites in this article), but
NASA's/ESA's budget is much bigger than just those missions and I would argue
many of them could have afforded second launches without drastically
compromising reliability (i.e. without becoming half reliable and half not as
you say)

~~~
mturmon
Regarding your (2), I think you may not be aware of the vast scope of Earth
observing missions (<http://science.nasa.gov/earth-science/missions/>).

Many of these are monitoring missions with data continuity constraints. For
example, solar irradiance monitors are hard to calibrate, so missions need to
overlap.

Also, they have a set of scientists that do calibration, who can't be told to
go away and do something else for two years while a replacement is built. This
kind of happened with OCO, and it was a bummer.

~~~
akiselev
You're right, I do not, and I admit I thought little about how important data
continuity is. Everything below is speculative and clarification would be
greatly appreciated:

I just read up on the OCO and that really does suck. In this case I doubt $280
mil would have paid for 2 launches without making it half-reliable but perhaps
a spread on risk across multiple similar missions would work. If (and this is
a big if) there are enough missions that need roughly the same payload
volume/size, orbit, etc. they can split the cost of a third rocket and both
build a carbon copy backup, or if a backup would be too expensive invest in
maintaining the staff and tooling for the most expensive instrumentation for a
faster, cheaper backup build later on. If one of the mission fails, they have
a third backup launch and a realistic shot of having/making a second
satellite. If they both succeed, the launch is sold for profit to someone who
really really needs the launch window or donated to civilian and less critical
mission satellites.

This is of course stretching into changing NASA bureaucracy and would have
tons of unforeseen consequences but would have the interesting side-effect of
providing more low-cost or even free piggy back launch opportunities,
especially for CubeSats. Also, talking to an engineer at Orbital, the
increased volume could really help lower costs for everyone Also, in the case
of critical staff for calibration, operation, etc., how the cost/opportunity
cost of having them just sit there while the mission rebuilds versus losing
them to other projects?

My thought isn't to passively set aside part of the budget for backups but to
actively use the resources to create a smart risk management system that (and
I'm making a big assumption) looks at the satellite and launch hardware as far
more expendable than it is now, in exchange for more overall throughput.
Thinking about the OCO, it's difficult to tell if it's an example of why it
wouldn't work or if the delay in what (I would think) would be a critical data
source on our impact on our planet is an argument for a shift in philosophy.
It would be like going from "Once in a while, the launch will fail but it's
rare so let's focus on making the satellite stay up as long as possible" to
"Rockets blow up all the time so let's make sure we're not the ones stuck
without a backup for what is already a ten to hundred million range dollar
project." With the rapid progression of everything from electronics to
materials to information technology, it might be beneficial to start thinking
on shorter mission time lines for Earth orbiting missions.

Rereading your comments though, it seems that I am under the delusion that a
larger portion of NASA's mission are exploratory and more flexible versus
missions that support critical infrastructure or carry instruments for data
that is far too valuable. Or maybe the bureaucracy carries more overhead than
I think it does and the days of NASA taking risks like the explorers of the
Old and New world are behind it.

~~~
mturmon
I just said you painted with too broad a brush. There is a range of mission
profiles, and (by design) some are more risk tolerant than others.

A starting point is <http://nmp.nasa.gov/> which is a series of missions that
specifically accept risk to develop selected new technologies. There are also
opportunities for higher-risk science-investigations
([http://science.nasa.gov/about-us/smd-programs/earth-
system-s...](http://science.nasa.gov/about-us/smd-programs/earth-system-
science-pathfinder/)). There is also a pathway through airborne systems, to
develop new mission concepts (e.g., <http://lidar.jpl.nasa.gov/co2las.html>)

It's a long road to space-qualify a new technology, and because system failure
is a logical OR of subsystem failures, you can't put too much new tech or new
science into a mission. You'll try a bunch of stuff and one thing will fail,
and you won't learn much.

Multiple launches of unreliable systems are not a particularly good way to
reduce risk. That's not doing engineering, that's throwing darts.

------
hdevalence
This is the video of the launch, or, "What integer overflow looks like":

<https://www.youtube.com/watch?v=kYUrqdUyEpI>

------
teeja
That one's bad enough, but my favorite is the $420M "Glory" satellite that
fell into the Pacific ... after the payload faring separation failed ... just
like it did for the previous, Orbiting Carbon Observatory launch.

<https://en.wikipedia.org/wiki/Glory_%28spacecraft%29>

------
quanticle
Can someone tell me why this article spends 90% of its wordcount talking about
the rocket used to launch the spacecraft rather than the spacecraft itself?

~~~
vilhelm_s
Currently, "Ariane 5 Flight 501" redirects to this article. There is a
category for launch failures
([http://en.wikipedia.org/wiki/Category:Satellite_launch_failu...](http://en.wikipedia.org/wiki/Category:Satellite_launch_failures)),
and looking at that I guess the Wikipedia convention is to name launch failure
articles after the satellite that would have been launched.

~~~
maaku
That's industry tradition. It's not common to number or name launches, but
rather to refer to the primary payload, e.g. “The MSL launch”.

EDIT: I'm sure that the launch provider has some naming scheme referencing the
rocket itself, but usage of that is almost universally confined to internal
communications. Human spaceflight is perhaps the exception (STS-125, not
Hubble Servicing Mission #4).

------
_jmar777
Sounds like it was a real cluster * * * *.

------
bttf
And if they used TDD, this wouldn't have happened.

