??? 07/14/06 17:33 Read: times |
#120265 - to be dramatic Responding to: ???'s previous message |
I have experimented with all kinds of noise and interference to test how to make a micro to run ill. And I can tell you, that there were numberous situations, where the watchdog did not do the right job!! Yes, it can even decrease the safety, when stupid engineers think they can neglect needed decoupling and filtering measures, because they have this wonderful watchdog.
So, how to proceed? I don't rely on the benefits of this wonderful watchdog. I prefer to enhance the filtering, so that a watchdog will never be "needed". On the other hand, I use a watchdog, of course, but only to calm my boss... to be dramatic let us discuss pacemaker examples 1) A cosmic event makes the memory location that stores pulse rate change from 63 to 31. There is no way ANY watchdog will detect that, so with 'usual' code the poor sod will get some jolts that he does not need. Now with good solid code code nothing would happen till 3 similar readings of the pulse were obtained and the disturbed pulse rate storage location would have no effect. 2) A cosmic event makes the program counter jump to some unrelated place in memory (maybe blowing the stack) can a watchdog catch that? Maybe. 3) a programming error makes the pacemaker miss kicking the heart when it needs it, that is reason for a lawsuit and maybe, just maybe, the generator of 'usual' code will be severely punished. Of course, unfortunately he will find another place to continue generating 'usual' code. So, the watchdog is not a panacea, but it WILL catch some things. The morale of this: a watchdog is good to have, it is a safety feature but can never be the safety feature, only good solid code can make safety the best it can be. Erik PS writing the above I recall: I have see ever so many 'averaging' procedures that miss the obvious. If, while avaraging you get a crazy read, throw it out. |