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

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
???
05/30/08 10:24
Read: times


 
#155283 - processing speed should not be an issue
Responding to: ???'s previous message
I think you fail to understand the problem. Using triple redundant micros is fine for a complex process that you simply can't shut down or shut down quickly, for a temperature controller, worst case you can simply turn the power off be it an electric heater or the gas in the case of a gas heater - fail safe in other words. I would expect the worst case with a temperature controller is that it gets stuck on and the furnace or whatever melts and/or catches fire, toasts a few people and burns down a building.

You want to keep things simple - using a single chip micro should be more 'reliable' than a micro with external memory devices - less wiring to pick up interference. The actual micro hardware should be quite reliable, you're more likely to have software errors doing the wrong thing in unanticipated conditions and transient errors due to interference. You're more likely to have site wiring problems, sensor failure and transients on the input signal. So your design has to cope with these issues first. As myself and others have previously said, you need to look at possible failures apart from and including the processor.

As for external ram slowing down an 8051 - depends on which one! There's a few to choose from - besides, speed shouldn't be an issue for a temperature controller and in the case of a fast micro with external memory with wait states, the slow down is <1% in most cases and only when you access the external memory - we're talking the difference between, say 50nS and 150nS for a memory access. If you wanted to do a TMR (triple multiple redundant) style controller - you could just have three controllers with the output contacts in series and maybe have them talk to each other by a RS485 bus - again speed should not be an issue. But happens if all three fail the same way? You need to have some means of detecting a failure - the failure may come from a variety of sources.


If you want reliability, then you have to delve into statistics as nothing is 100% reliable, so you need to decide how reliable you want it - what is the industry standard to the type of equipment you're making? Off the top of my head, the oft quoted figure is 1 failure in 10^9 hours which is quite a few years - more than I shall live. So how do you prove your controller have meet this? Statistics! Some manufacturers give failure stats for their products otherwise you have to 'make it up' or refer to standard publications that give the stats for various components - MIL HBK is one that comes to mind. Ever wondered how manufacturers come up with the MTTBF values? This is how. Nevertheless, you need to do a FMEA to identify the possible sources of failure then apply failure stats to these, add it all up and you get a magic figure. If the magic figure isn't high enough, then go back and figure out a means to make it so. The figure is probably next to useless expect if you need to defend yourself in court if your controller caused a Chernobyl style situation.

Whilst your requirement of 'if the controller fails and swapping over to a secondary controller and how do I write the software?' is quite a simple request, but can't be answered simply without knowing all the information on what you're building. Even then if we give you the information you need, you're not off the hook as you have to prove the reliability. Or is this an open question expected to be asked at an interview so you need to give a good answer otherwise you won't get the job? Any interviewer with an ounce of intelligence will pick you out after a few carefully crafted questions. The general idea is that you seek to understand the problem and give plausible solutions - that's what engineers do each day.

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