msnbc/oberg: 'Murphy's Law' rules outer space

'Murphy's Law' rules outer space

.... And NASA still needs to learn how to evade it

http://www.msnbc.msn.com/id/3033063/

Analysis By James Oberg

NBC News space analyst // Special to MSNBC

Updated: 8:18 p.m. ET Oct. 21, 2004

HOUSTON - In outer space, many earthly rules and standards don't apply.
But if space exploration has proved anything, it is that like the universal
Law of Gravity, the Law of Murphy also extends throughout the known
universe.

"If something can go wrong, it will go wrong," is the classic phrasing
of the observation attributed to rocket scientist Edward A. Murphy Jr. half
a century ago. But space historians point out that the original formulation
of Murphy's Law was more limited: "Every component than can be installed
backward, eventually will be."

The latest proof is the highly embarrassing crash of NASA's Genesis
capsule, carrying samples of the solar wind that were supposed to provide
clues to the origin of the sun and the entire solar system. The parachutes
failed to deploy over Utah last month, and the disk-shaped craft smashed
into the ground at full speed.

An investigation team has now determined that the deceleration
sensors - the accelerometers - were all installed backwards. The craft's
autopilot never got a clue that it had hit an atmosphere and that hard
ground was just ahead.

"Jim Oberg" wrote in message

An investigation team has now determined that the deceleration
sensors - the accelerometers - were all installed backwards. The craft's
autopilot never got a clue that it had hit an atmosphere and that hard
ground was just ahead.

Actually, I figure that the autopilot should have had at least a clue that
it had hit the atmosphere. The switches may have been installed backwards,
but if memory serves me well, about half the time the craft was traveling
_backwards_ in the atmosphere as it tumbled ...

Jon

Jon S. Berndt jsb.at.hal-pc-dot.org wrote:
[...]

Actually, I figure that the autopilot should have had at least a clue that
it had hit the atmosphere. The switches may have been installed backwards,
but if memory serves me well, about half the time the craft was traveling
_backwards_ in the atmosphere as it tumbled ...

The tumbling didn't start until after the capsule was past
the re-entry phase... it was aerodynamically stable at hypersonic
speeds (or else it would have burnt up in re-entry... the backshell
didn't have much ablator on it, and was obviously not charred badly).

By the time it went subsonic and unstable (without the drogue chute)
it was probably at too low a dynamic pressure for the G-switches
to activate even if it were upside down, though it is also
possible that it was more of a case of them not activating
for long enough to set off the timer.


-george william herbert

October 22, 2004

Jim Oberg wrote:

'Murphy's Law' rules outer space

And Jimmo still claims that flying saucers never crash :-)

I never laughed so hard in my life when I saw that picture.

I laughed so hard, I cried.

Thomas Lee Elifritz
http://elifritz.members.atlantic.net

"George William Herbert" wrote in message

Jon S. Berndt jsb.at.hal-pc-dot.org wrote:

Actually, I figure that the autopilot should have had at least a clue
that
it had hit the atmosphere. The switches may have been installed
backwards,
but if memory serves me well, about half the time the craft was traveling
_backwards_ in the atmosphere as it tumbled ...

By the time it went subsonic and unstable (without the drogue chute)
it was probably at too low a dynamic pressure for the G-switches
to activate even if it were upside down, though it is also
possible that it was more of a case of them not activating
for long enough to set off the timer.

-george william herbert

Yeah, I considered that - I wasn't completely serious.

Jon

The morale of the story here, I think, is that a
single sensor installed correctly is far more useful
than two sets of redundant sensors installed
incorrectly. And the morale of that is the same as
the lesson allegedly learned with Mars Observer,
Galileo, Mars Polar Lander, Mars Climate Orbiter,
etc; namely that organization and management are as
important as budget and design. If you can't put the
design together properly then it doesn't matter how
much the components cost or how much hardware
redundancy there is.

"Christopher M. Jones" wrote

The morale of the story here, I think, is that a
single sensor installed correctly is far more useful
than two sets of redundant sensors installed
incorrectly. And the morale of that is the same as

Also: software (to cross-check other relevant parameters for sanity) isn't
heavy and doesn't take up too much space. Backup systems should be present
and shouldn't rely on the same paths. For instance, given the state of
simulation and tracking that we have today, I'd bet that 8 hours prior to
entry a timer could have been kicked off that would have pretty accurately
been able to tell when the chute should have been deployed. Couple that with
another independent parameter reading such as atmospheric pressure or
nutation or something not possible in a vacuum and then you have a sanity
check.

Jon

"Christopher M. Jones" wrote in message
...
The morale of the story here, I think, is that a
single sensor installed correctly is far more useful
than two sets of redundant sensors installed
incorrectly.

The morale of the story is that you can only do so much with redundant
components. A better solution is often a redudnant subsystem or an entriely
redudnant system or even vehicle.

An example of this is the shuttle and Soyuz/Progress transports for ISS.
Two entirely different systems to provide access for ISS. When there is a
problem with one, the other can take up the slack. Soon there will be HTV
and ATV to add to this. This level of redundancy does cost, but really
pushes up the chances that you'll successfully complete the overall mission.

And the morale of that is the same as
the lesson allegedly learned with Mars Observer,
Galileo, Mars Polar Lander, Mars Climate Orbiter,
etc; namely that organization and management are as
important as budget and design. If you can't put the
design together properly then it doesn't matter how
much the components cost or how much hardware
redundancy there is.

I'd actually say that integration testing and full up test flights are more
important than budget and design. A test flight of Genesis to LEO and back
would have quickly uncovered the sensor design flaw, without impacting the
actual mission. Perhaps bolting the spacecraft to a "shake table" and
subjecting it to the level of "g-load" that should trigger the parachutes
would have been sufficient in this case, but could have missed other
problems, like the sensor never getting tripped because the re-entry
computer analysis was off a bit.

Furthermore, more reusable spacecraft (allows you to test actual flight
hardware then re-use it for the actual mission) and multiple copies of
spacecraft will push up the overall reliability when compared to the typical
one-off designs NASA seems to consistently come up with. The real problem
with these one-off designs is that their one and only test flight is nearly
always the operational mission. :-(

Jeff
--
Remove icky phrase from email address to get a valid address.

Jeff Findley wrote:
"Christopher M. Jones" wrote in message
...

The morale of the story here, I think, is that a
single sensor installed correctly is far more useful
than two sets of redundant sensors installed
incorrectly.

The morale of the story is that you can only do so much with redundant
components. A better solution is often a redudnant subsystem or an entriely
redudnant system or even vehicle.

An example of this is the shuttle and Soyuz/Progress transports for ISS.
Two entirely different systems to provide access for ISS. When there is a
problem with one, the other can take up the slack. Soon there will be HTV
and ATV to add to this. This level of redundancy does cost, but really
pushes up the chances that you'll successfully complete the overall mission.

To bring in a different set of examples, Mars Polar
Lander and Mars Climate Orbiter. Different designs,
different spacecraft, different sub-systems, both
failures. The reason behind the failures lies not
in redundancy but in the organization.


And the morale of that is the same as
the lesson allegedly learned with Mars Observer,
Galileo, Mars Polar Lander, Mars Climate Orbiter,
etc; namely that organization and management are as
important as budget and design. If you can't put the
design together properly then it doesn't matter how
much the components cost or how much hardware
redundancy there is.

I'd actually say that integration testing and full up test flights are more
important than budget and design. A test flight of Genesis to LEO and back
would have quickly uncovered the sensor design flaw, without impacting the
actual mission. Perhaps bolting the spacecraft to a "shake table" and
subjecting it to the level of "g-load" that should trigger the parachutes
would have been sufficient in this case, but could have missed other
problems, like the sensor never getting tripped because the re-entry
computer analysis was off a bit.

This also can fail. As with Galileo, where a g-test was
performed on the Jupiter atmospheric probe. However, the
test was invalid because the test harness was wired
backwards (fyi, Oberg covers this in his article). An
organization with a high rate of failure is also likely to
have a high rate of failure in testing procedures. There
is no silver bullet solution in design, or testing, or
funding, or anything of that sort for organizational problems
on this scale, the only solution is fixing the organization.


Furthermore, more reusable spacecraft (allows you to test actual flight
hardware then re-use it for the actual mission) and multiple copies of
spacecraft will push up the overall reliability when compared to the typical
one-off designs NASA seems to consistently come up with. The real problem
with these one-off designs is that their one and only test flight is nearly
always the operational mission. :-(

Reusability doesn't necessarily gain you much depending on
how you fly and test. If you fly irregularly and constantly
tweak the vehicle then, as with the Shuttle, you never really
know how reliable the mission is. If you fly regularly enough
and start off with a serious testing regime then you can be
more confident. However, for experiments like Genesis this
really isn't the answer. A more bug-tested spacecraft bus
(and return capsule) would help, but the spacecraft would still
be fairly custom.

In article ,
"Jeff Findley" wrote:

"Christopher M. Jones" wrote in message
...
The morale of the story here, I think, is that a
single sensor installed correctly is far more useful
than two sets of redundant sensors installed
incorrectly.

The morale of the story is that you can only do so much with redundant
components. A better solution is often a redudnant subsystem or an entriely
redudnant system or even vehicle.

I'd say the real moral of the story is that components should be
designed in such a way that they can't be installed backwards. This
isn't difficult; it's just something the component engineers didn't
think to do. It should be a standard design habit. If an engineering
firm tends to design symmetrical components that look the same forwards
as backwards or upside-down, they should be fired and replaced with a
firm in the routine habit of making their stuff asymmetrical.

,------------------------------------------------------------------.
| Joseph J. Strout Check out the Mac Web Directory: |
| http://www.macwebdir.com |
`------------------------------------------------------------------'