Hi,

There are many levels of supporting fault tollerance. Here are some suggestions..

Communication:
You can do something as simple as doing a checksum on the data and requiring an acknowledge back from the receiver before sending the next packet of information. If you don't get an acknowledge or if you get a negative acknowledge, the transmitter can resend the data until the receiver does acknowledge the data. If for whatever reason you cannot allow feedback, you will need to embed some sort of redundancy into the data so that if some portion was scrambled, it can be rebuilt by re remaining portion. This might be as simple as sending the data two or more times for each packet. You can also implement various CRC codes, but this can get very messy and still doesn't guarantee all the data.

Hardware...
First line of defence is the power source. Make sure it won't be interrupted. Then, you can implement multiple communication paths on the same processor or multiple processors. With multiple processors, you can have one be assigned as the master and do the normal work. If it fails, it could ask for help from the secondary processors. If the master really fails, a secondary processor will need to figure this out (sometimes by missing what is called a heartbeat from the master). However, when a secondary processor takes over as master, it will need to make sure the original master doesn't continue to try to work and screw things up. In the networking world, they have STOMITH devices (Shoot The Other Machine In The Head) that allows a system to kill another system.

Perhaps a more precise description of your problem will let us help you more. Also, let us know what your ideas are.

<>< Lance.