duplicate a variable!!!!

[VAUGHAN Jay]

> Realistically, radiation causes enough bitflips in DRAM cells that most
> servers have ECC memory. It causes so few bitflips in processors that
> most systems ignore that possibility - other risks greatly outweigh
> processor bitflips. When you are talking about something that is so
> safety-critical (or cost-critical, or high-risk - such as in space) that
> it is a real concern, then you duplicate or triplicate the processor,
> and/or you use radiation-hardened devices, and/or you use external
> shielding, and/or you use specialised processor designs with ECC right
> through to the register level.


... and then, on top of that, you duplicate your variables into different parts of RAM and 
do a bit comparison before you use them for some purpose, just in case you have the chance 
to catch something - and perform a safety reaction - in time to avert disaster.

> Certainly nothing in software can be of any help when you are facing
> unreliabilities in the processor itself.

Aggressive Online testing is really the only thing you can do, to detect such errors in 
the first place and - hopefully - have time to perform a suitable safety reaction.

> Maybe I should be taking a slightly more humble tone here :-) I have
> done some safety-critical embedded software development, but not at your
> level - in the systems I have done, there has always been a human that
> can override the system in the event of failure, and it is always safe
> to switch off.

Well when you've got hundreds of tonnes of train hurtling down the track, and the light 
says "RED", and your computer says "GREEN" because its got a problem, you don't have time 
for humans to get involved. ;)

I'm no expert on this issue, I merely work in the group of experts providing an 
industrial-standard solution, and I'm learning a lot too.


> Well, if you are correct that such variable duplication is a help (I
> still don't see how, but you are more qualified than me to talk about
> it), then I agree that it would be a cool feature to have in gcc.

It is not supposed to be a full solution - early detection of RAM corruption can only help 
bring the system, which is being depended on, offline so that other backup systems can be 
inserted in place.

> However, generally when I have seen discussions about the use of gcc in
> safety-critical development, the main concerns seem to be about testing,
> validation and certification of the compiler using things like Plum
> Hall. Do you use gcc for such safety-critical systems, and if so do you
> do any sort of certification for it?

Of course, all validation of the compiler and certification is a requirement as part of 
its uses for this purpose ..

> The other feature that gcc could gain that would improve its use in
> safety-critical systems is a set of warnings for MISRA compliance. Much
> as I hate MISRA, it is a standard that is often used in such systems.

Its one thing to hate standards, its another thing to implement them, ship them as part of 
a product, and reliably see the fruits of such labour in safety statistics. ;)


> And while bitflips due to radiation do occur, I think application code
> bugs are a much more common source of problems.

Absolutely, there are no absolutes! :)

 > Compile-time warnings
> and error checking are steadily improving with each new version of gcc,
> but I'd say that more work here would have greater benefits for code
> safety than automatic variable duplication.

I concur - and this is why I suggest that anyone looking at a safety-critical application, 
wanting to do variable duplication for protective reasons, implement it themselves.


-- 
;                                           Thales Austria GmbH
Jay Vaughan,                                Scheydgasse 41
Software Developer                          1210 Vienna AUSTRIA
============================================--------------------