Re: Long missions question

Well, I can include a few personal observations and opinions below. Consider
this from the perspective of an engineer at JPL, where I was employed at the
time. I no longer work there.

On Sun, 29 Jan 2006 11:03:26 +1300, "Katipo" <hamilton@xxxxxxxxxxxxx> wrote:

>I take your point, and Ten's.
>
>But what about the things that can go wrong after launch that the designers
>can't control?
>Obviously things like the possibility your probe might be destroyed by, say,
>a meteor are risks you have to take?

Of course, there are no sure things. Getting hit by an asteroid. Or as
Henry has pointed out, there were thruster issues. Or any one of a
bajillion things can go wrong. But that doesn't mean one never leaves the
harbor. For spacecraft systems the design rule was no single point
failures. That gives one some margin for a random failure but not in
general a systemic or common mode failure. I don't believe the instruments
had full redundancy. Now, is dual redundant with cross strapping good
enough? It depends is the only answer you can come up with, how much you
are willing to pay, how you trade off spacecraft vs. science, and how much
risk is acceptable. Of course, that is a high level policy decision. For
ths space shuttle (and this is sci.space.shuttle) they have a higher level
of fault tolerance. How much is enough?



>However, as cool as the work is, it can't be easy to put your heart and soul
>into a project when, for example, you know there are no gaurantees that
>funding will be available to process (or even collect) data sent back when
>(and if) the probe reaches its destination.

I never regarded that as a factor.

Since there are no guarantees for any of these missions it would not make
sense to require a guarantee of some sort. For example, consider just the
risk in the launch vehicle.


>I tend to look more at the longer term issues than many people (in my
>experience) do. If I was a rocket scientist and was asked to bust my gut
>working say 60 to 80 hours a week to get a probe ready by a particular
>deadline, I'd like a little certainty that when it arrives at its
>destination the information it gathers will be collected and analysed. If
>sufficient certainty is not there I'd rather not build the probe until I had
>developed the technology to get it to its destination while I was still
>around to ensure my time was not wasted..

Again, no guarantees, particularly in exploration misssions such as this.

I asked above how much is enough. Do you put two computers on? Or three?
Or four? Or five? It simply doesn't matter, you will never reduce the risk
to the point of having a guarantee. Consider the control electronics for a
digital fly-by-wire aircraft such as some Airbus models or the Boeing 777.
There are no guarantees and they design to a failure rate that is deemed
"acceptable risk" for the flying public.


>
>Katipo
>
>"rk" <stellare@xxxxxxxxxxx> wrote in message
>news:ulknt152kc86n39k9v9a0j2h9vdfasvu10@xxxxxxxxxx
>> Well, from an engineering point of view, it's just self-motivation to
>> achieving a goal -- they are exciting missions and the goals are simply
>> cool
>> enough to provide all the incentive one needs. Take Galileo, for example,
>> which arrived at Jupiter long after it was designed and built. Having the
>> opportunity to roam around the solar system exploring by the machines one
>> designs is simply exciting.
>>
>>
>> On Sun, 29 Jan 2006 09:20:57 +1300, "Katipo" <hamilton@xxxxxxxxxxxxx>
>> wrote:
>>
>>>Something I have always wondered about long missions such as New Horizons.
>>>
>>>I am sure the scientists involved work extremely hard to get the missions
>>>under way. How do they motivate themselves when they must know there is a
>>>real possibility they might not be around (eg moved to another job,
>>>retired
>>>or even dead) when the results start coming in?
>>>
>>>Katipo
>>>
>> --
>> rk, Just an OldEngineer
>> "The number of people having any connection with the project must be
>> restricted in an almost vicious manner. Use a small number of good
>> people."
>> -- Kelly Johnson in Skunk Works
>
--
rk, Just an OldEngineer
"The number of people having any connection with the project must be
restricted in an almost vicious manner. Use a small number of good people."
-- Kelly Johnson in Skunk Works
.

Relevant Pages

  • Re: embedded Vs Realtime
    ... >>You need to assess the system over much wider risk areas than just time. ... > irrationally on time to the exclusion of other design issues. ... >>are correct that the failure criteria are for the customer to define. ... More importantly the engineer must understand the process that he is ...
    (comp.arch.embedded)
  • Re: Cost of Cockpit Instruments
    ... large they are experimental crafts with many possible points of failure. ... attitude is too extreme for the actual risk involved. ... Is it true that if COTS components were used, ... supplied components in an otherwise "well-engineered" design. ...
    (rec.aviation.piloting)
  • Re: cquirke, whats your opinion?
    ... By design, the more clueless email apps will autorun ... > Where there is risk, design should be shrink-wrapped around intent. ... and it's been routine for malware ever since. ... > MS responded to the above as code defects and patched them, ...
    (microsoft.public.windowsxp.security_admin)
  • Re: Saturn V
    ... for vehicle or mission failure depends on the combined risks for the ... The practice of risk analysis is not ... Managing and understanding risks for better safety has a long history ...
    (sci.space.history)
  • Re: vague talk of safe hex is deadly !
    ... has "inherent design flaws", or has more "security vulnerabilities" than ... > Where there is risk, design should be shrink-wrapped around intent. ... and it's been routine for malware ever since. ... > MS responded to the above as code defects and patched them, ...
    (microsoft.public.windowsxp.security_admin)
Quantcast