Re: Ariane 5 failure

[Ken Garlington <garlingtonke@lmtas.lmco.com>]

Wayne L. Beavers wrote:
> 
> Ken Garlington wrote:
> 
> > That's actually a pretty common rule of thumb for safety-critical systems.
> > Unfortunately, read-only memory isn't exactly read-only. For example, hardware errors
> > can cause a random change in the memory. So, it's not a perfect fix.
> 
>   Your right, but the risk and probability of memory failures is pretty low I would think.  I have never seen
> or heard of a memory failure in any of the systems that I have worked on.  I don't know what the current
> technology is but I can remember quite awhile ago that at least one vendor was claiming that ALL double bit
> memory errors were fully detectable and recoverable, ALL triple bit errors were detectable but only some were
> correctable.  But I also don't work on realtime systems, my experience is with commercial systems.
> 
>   Are you refering to on-board systems for aircraft where weight and vibration are also a factor or are you
> refering to ground base systems that don't have similar constraints?

On-board systems. The failure _rate_ is usually pretty low, but in a harsh environment 
you can get quite a few failure _sources_, including mechanical failures (stress 
fractures, solder loss due to excessive heat, etc.), electrical failures (EMI, 
lightening), and so forth. You don't have to take out the actual chip, of course: just 
as bad is a failure in the address or data lines connecting the memory to the CPU. Add 
a memory management unit to the mix, along with various I/O devices mapped into the 
memory space, and you can get a whole slew of memory-related failure modes.

You can also get into some neat system failures. For example, some "read-only" memory 
actually allows writes to the execution space in certain modes, to allow quick 
reprogramming. If you have a system failure that allows writes at the wrong time, 
coupled with a failure that does a write where it shouldn't...