wouter van ooijen wrote:

> I am reluctant to trust the article in such detail, I have seen similar
> articles to get such details subtly wrong.

Ok, you have a point with this. But then, we don't know anything... I was
just assuming the article was correct, and arguing from that position. If
you know it wasn't, let's talk about this. If you only suspect it might not
be, then there's not really much to say anyway...


> IIRC I argued that I did not see evidence for an (in flight?) software
> error.

That might be so, but nobody claimed that there was one.

I argued that it seemed -- from the article -- that there were not enough
safeguards (in ground software and procedures) against an almost
predictable error.


>> -- and none of them required a user to change configuration parameters
>> using raw address tables. From my experience, this would be a support
>> nightmare.
> 
> Was any of these devices you made accessible by remote access only (in
> the sense that it would cost $$$ to replace the device, and $$$$ to get
> a human near it)? In such circumstances you want *total* remote access.

I said that the very first time, and in every msg since: I never argued
against total and totally free access. I just argued against using such an
access without the appropriate safeguards -- which, according to the
article, seems to have happened:

"'The particular procedures that were in place didn't have as much rigor in
them as you could have expected,' Perkins said. 'For example, they didn't
require people to go back to this very basic and not-always-easy-
to-interpret set of tables that show everything that's in the memory on the
spacecraft to verify what was going on.  There wasn't any obvious thing
between June and November that would have led someone to discover [the
faulty parameters].  Among our findings is that... there were no systems in
place that would have discovered it and brought it to the attention of the
operations team.'"


> In space stuff everything is terribly expensive, even the parts and
> software that will not fly.

Right. But the loss of the craft (total cost $210M) shows that there was a
problem. /This/ was terribly expensive. Apparently a few $10k in better
procedures/ground software would have been well spent. (I also know that
afterwards everybody is smart -- I'm not attempting to judge the involved
people here.)

The only thing I argued was that this was -- IMO, and according to the
article -- not an operator error, but a problem in the procedures (which
probably include several pieces of ground software) that made it possible
that a single operator /can/ make a mistake with raw memory addresses in
the first place.

> As an example: guess what a "normal" resistor for in-space use will
> cost? (I will have to look it up too)

No clue. I'd guess over $1, after you factor everything in. But the more
expensive, the more it is an argument in favor of what I'm trying to say:
put better safeguards in ground procedures and software, so that the
probability of such silly things is smaller still. If a single operator
mistake can wreak such havoc, it's generally not the operator's fault, it's
the whole procedure that's missing something. 

Gerhard

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist