We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi, I am working on a safety critical system project for railways and I am using AT89C52 micro controller.
I use a number of buffers (74ls373), decoders (74ls138) , multiplexers(74ls157) etc. During self test of the I need to check the presence of each of the components mentioned above. If any of the component is removed from the system or it has failed to function then the AT89c52 need to detect the failed or removed component and the whole system need to go to fail safe mode.
Can anyone help me with this issue. Raghu
I think you need to read up a bit about designing reliable, self-testing and/or redundant hardware.
The only thing your uC knows is if it's individual signals are high or low. It is up to you to decide if the combination of signals are reasonable or not.
To make your hw testable, you need to look into programmable logic with support for boundary scan, to allow you to serially read out the state of all signals (i.e. not just the signals between the chip and your uC, but all the other signals too).
You may also use shift registers to scan signal states in the system. Of course, it is hard to detect if an input is broken and always reading a high or a low, if the actual signal on that pin is normally expected to have that specific state. Because of this, serial communication and timed data is advantageous. You will then know if you can get data, or if a signal has locked up.
Remember that buffer chips are most likely to fail on the external signals, since it's the external signals that may suffer unconditioned signals.
In some situations, it is also advantageous to add extra output signals, to let your uC force changes to mux or decoder chips, and then use serial detection to verify that your forced changes can be detected.
If the system controls critical functions, then you want the hardware to be able to stop dangerous processing if the uC stops responding, or the board detects invalid sensor data. One more reason for serial communication - it is easy to build hw watchdogs.
By the way: removed components? Are people expected to steal components from a live system or???
"Loopback" is a technique where data sent out from an output is "looped" back to an input - so that the processor can verify that the complete path is working.
As well as implementing the loopback path, You also need to design the test signals carefully to ensure that they really do confirm that everything is working and, preferably, can also precisely identify the nature of any fault...
Loopback is very good to have, and to make use of. Alas, it often isn't enough. Many communication chips that have loopback support only have internal loopback, because the receive and transmit signals are on separate external pins. All logic in the chip is tested, but no actual hw pins are used.
External loopback requires that the interface is using the same signal line for both receive or transmit, or that the communications chip can listen to it's own physical transmit signals. Unless the chip does this by use of two bond wires, the signal input will not notice if the bond wire for the output pin is broken.
If external loopback is implemented using external hw, then it is hard to know if the external hw is working ok in non-loopback mode.
a safety critical system project ... I use a number of buffers (74ls373), decoders (74ls138) , multiplexers(74ls157
You are making a basic error, the issue of failure detect is, of course important, but failure avoidance is far more important. More components equals failure more likely, more solder joints equals failure more likely. Get rid of the discrete chips, use an 8 port uC (e.g. SILabs 8051f12x/f13x) and (if needed) a FPGA/CPLD.
With such a scheme you get far better reliability and, as a bonus, for the uC ports - they are always there; and, for the CPLD/FPGA implememnting loopback is a breeze.
Erik