Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
???
05/28/08 22:14
Read: times


 
#155236 - Have you considered this ...
Responding to: ???'s previous message
First of all ... if you have two controllers, how can you determine, in real time, which of them is correct and which is flawed?

Suppose you had three controllers. With a bit of judiciously placed monitoring logic, easily contained in a moderate CPLD, you can select which of three signal sources is in error, and simply ensure that's not the one producing the signals you require. You must, of course, drive the three with precisely the same clock input and use a separate PLL for each MCU so that the controllers can continue to run in the event the oscillator or one of the PLL's fails. This isn't perfect, but shift the likelihood in your direction, AND it is very easy and quick. It's the only way I have encountered over the years, that prevents issuing erroneous signals to the outside world. There are more sophisticated ways of establishing redundancy, but this allows you to switch out the errant MCU before even one of its errant outputs has effect on the system outputs.

If you have analog circuitry, this will not easily be adaptable, but with digital signals, it works pretty well, and quite easily.

Choose the signals that are most critical and simply compare the three versions of those signals. An occasional failure of a single MCU is likely to happen, though not frequently. A failure of TWO such MCU's is much less likely, and a failure of two such MCU's in precisely the same mode is even less likely.

Note that such an approach will not compensate for erroneous logic in the code you've written. Nothing is entirely fail-safe, though you can make the odds favor you by being conservative.

The easiest way for you to mitigate the risk of system failure is to ensure that your power supply is clean and as noise-free as possible. Inductors (ferrite beads) in the Vcc line can significantly reduce your risk of power system events causing random failures. It's particularly important to use such mechanisms when you have noisy circuit segments with >100 mV of relatively high-frequency variation on the positive supply.

Careful filtering of the output of a switching power supply is certainly necessary in critical circuitry. The "safe" way to effect this is to use the switcher as a pre-regulator, and use a carefully designed pi-filter to suppress the switcher's ripple, and a high-gain linear regulator to generate the primary supply for all critical circuitry. (Note the emphasis on careful!)

Your original query suggests that you simply wish to "inform" the redundant controller if the primary controller fails. How, exactly, do you intend to determine whether the primary controller has failed? Are you simply worried that it might stop? What about other components in the system? Are you willing to make the others redundant as well? What about the power subsystem?

If you don't need immediate (~20ns)replacement of a dissident controller, there are less costly and less-prompt, ways of establishing redundancy.

Good Luck!



List of 32 messages in thread
TopicAuthorDate
stanby controller for emergency            01/01/70 00:00      
   ALE pulse            01/01/70 00:00      
   What are the expected problems?            01/01/70 00:00      
   The problem here is...            01/01/70 00:00      
      What about processing speed            01/01/70 00:00      
         processing speed should not be an issue            01/01/70 00:00      
   How do you know if it has failed?            01/01/70 00:00      
      my querry            01/01/70 00:00      
         Use a watchdog            01/01/70 00:00      
            I think watchdog not suitable            01/01/70 00:00      
               watchdog            01/01/70 00:00      
                  if it is critical system            01/01/70 00:00      
               Backup controllers            01/01/70 00:00      
         does that going to help            01/01/70 00:00      
            Where are erik and Andy            01/01/70 00:00      
               Irrespective....            01/01/70 00:00      
                  What you say is correct            01/01/70 00:00      
                     engineering procedure            01/01/70 00:00      
               Where are erik and Andy - asleep            01/01/70 00:00      
   much simpler            01/01/70 00:00      
   always operating or failsafe            01/01/70 00:00      
   Have you considered this ...            01/01/70 00:00      
      there is always a gotcha            01/01/70 00:00      
         Yes, but it always depends ...            01/01/70 00:00      
            hardware description is needed            01/01/70 00:00      
               Is this feasible            01/01/70 00:00      
                  No,            01/01/70 00:00      
                  You have reinvented a watchdog            01/01/70 00:00      
                     this is running in circles because ....            01/01/70 00:00      
                        Nothing's perfect            01/01/70 00:00      
                           not if you are only concerned with hardware failur            01/01/70 00:00      
                              it's all about testing            01/01/70 00:00      

Back to Subject List