No it isn't.  I used to work for a comapny making railway signalling
equipment.  This stuff had to be totaly fail-safe.  All microprocessor
equipment was duplicated, each side cross checking the other.  The micro's
continuously ran RAM tests and ROM CRC tests.  A hardware watchdog would
blow the main supply fuse to the micros if anything went wrong. There was
even circuitry to make sure the PSU's could supply enough current to blow
the fuses and that the fuse blowing transistors were functional.  These
things were just looking for any excuse to shut themselves down, in which
case the signals would default to red.  Would you rather have your train
late, or end up as the filling in a train sandwich?

The 'chute opener should have similar fail-safe capability.  It seems to me
that it needs to signal the user that it has shut down and that manual
operation is required.  In any case, I really don't think a PIC is suitable
for this kind of thing, Microchip definately say PICs are not to be used in
saftey critical applications.

On the other hand, a micro controlling your TV remote, or the tuning in your
car radio can quite safely go loopy without the possibility of hurting
anyone.  The trouble is that faulty code is unpredictable, you don't know
exactly what problems it could cause until it's too late.  You only have to
look at the numerous Y2K software issues to see this.

Regards


Mike Rigby-Jones
mrjones@nortelnetworks.com


> ----------
> From:         Alan King[SMTP:shadedemon@MINDSPRING.COM]
> Sent:         09 February 1999 06:43
> To:   PICLIST@MITVMA.MIT.EDU
> Subject:      [OT]Re: Failure modes (was: wierd jump)
>
> But that's the point.  Complete shut down and relying on a fail safe is
> a poor choice in any safety related case.
>
<snip>


>   My opinion of which way is better overall doesn't count.  Neither does
> your's.  The first way FITS this problem with a better outcome.  Your
> prejudice against 'subtle malfunctions' keeps you from even seeing why
> someone would do it that way, much less why it's better in some
> instances.  In my STRONG opinion, Pics are the best thing since sliced
> bread, they are easy to use and versatile.  But regardless of my
> opinion, when I first look at a project the first thought is 'Should it
> be microprocessor controlled?' and the second is 'Is a Pic the right one
> for the job?'  You still see dogged opinions as a plus to engineering
> skills.  I've been bitten in the ass enough by that dog (my opinion and
> other people's) to realize they're a minus.  No one method of handling
> errors can be the right one in *all* cases, and you aren't pulling back
> far enough to see when other ways may be better..
>
> Alan
>
>
> Gerhard Fiedler wrote:
>
> > actually, from a parachute opener i'd very much like to have a strongly
> > audible beep -- and NOTHING else -- if =anything= goes wrong with it.
> and
> > if it's a situation where the beep is not enough, maybe a complete shut
> > down with of course the following fail-safe parachute opening. but not
> any
> > kind of "subtle malfunctioning"...
> >
> > ge
>