[X] My Assistant

[nprev]

Hey, everybody. I'm beginning work on my thesis for a master's in system engineering, and my selected topic is built-in-test equipment. Specifically, what I'm trying to do is determine how much is TOO much, and/or not enough; I suspect that there is a critical point where BIT equipment becomes more complex (and therefore more failure-prone, and more of a maintenance burden) than the system(s) it monitors.

Most of my case studies will involve aircraft systems because of the direct maintenance burden and extensive human interfacing implicit in such systems. However, I'd love to also examine a planetary spacecraft fault-protection system as an extreme example with respect to airplane stuff (i.e., it theoretically absolutely, positively HAS to be accurate to a very high degree, and it'll be pretty darn hard to fix if it breaks). The data I'm looking for is the number of interfaces with monitored systems, redundancy features, and cost as a fraction of total developmental expenditures.

So, if anybody has any of this information available (and, of course, releasable...NOT trying to get anyone in trouble, here!), please ping me. Thanks!

[Bob Shaw]

I believe one of the first paper studies was for STAR - 'Self Testing And Repair' on the TOPS spacecraft (Thermoelectric Outer Planetary Spacecraft) which was part of the planning for the original Grand Tour.

One to avoid, however, is any reference to spurious error conditions in an AE35 antenna guide module!


Bob Shaw

[ugordan]

One to avoid, however, is any reference to spurious error conditions in an AE35 antenna guide module!

Actually, current belief is that simple (but unlucky) cosmic ray induced bit-flips in one of the integrated circuits were responsible for the error predictions.

[dvandorn]

And I suppose HAL's final breakdown was caused when there was an extremely unlucky flip of the bit in its programming that turned on the "Become monomaniacal and murder the crew" subroutine?

I think the question then becomes the sanity of Dr. Chandra for including that subroutine in HAL's programming in the first place...

-the other Doug

[nprev]

All I know is that if the Discovery had the old C-5 aircraft MADAR (malfunction analysis detection and recording) system instead of HAL, Bowman & Poole would have spent every waking moment fixing it & chasing false failures... ...heck, they might've had to defrost the rest of the crew to help!

[tty]

If you can suggest some way to prevent designers from making fault detection routines so sensitive that they raise an alarm every time an aircraft hits a rough spot on the taxiway it would be a giant step for reliability engineering.....

tty

[Greg Hullender]

"Open the pod bay doors, Hal."

"I'm sorry, Dave; I can't do that."

"Why not, Hal?"

"There's been a General Protection Fault in POD.EXE at 7E0D3947F4BC8900"

[Bob Shaw]

"Open the pod bay doors, Hal."

"I'm sorry, Dave; I can't do that."

"Why not, Hal?"

"There's been a General Protection Fault in POD.EXE at 7E0D3947F4BC8900"

Greg:

The University of Urbana, Ill. does Microsoft Windows development work, then? It explains a lot. Of course, I'd already noticed the lack of a 'Bonnnng' when HAL rebooted!

Bob Shaw

[nprev]

If you can suggest some way to prevent designers from making fault detection routines so sensitive that they raise an alarm every time an aircraft hits a rough spot on the taxiway it would be a giant step for reliability engineering.....

tty

Actually, that's almost my precise objective rather colorfully captured! . I spent many years as a USAF aircraft avionics maintainer, and chasing down false BITs was a major annoyance to say nothing of a waste of taxpayer dollars; trying to ameliorate that in some small way via the miracle of Excel modeling...