Hi,.....
i am developing a product. The same requires Hot redundancy of the two microcontrollers. The input & Outputs will be comman for both controllers. HMI & keyboard will be comman for the both. The failure of one controller shall be taken care by another. Is it possible to do the same. If any other option is available please suggest.
Why two controllers? Why not three? After all, an odd number of controllers allows you to design hardware to handle majority votes. So with one microcontroller failure, two-out-of-three votes would still keep the system running.
Of course, failures are often more sw-related than hw-related, in which case multiple processors are likely to perform the same error.
Note that common outputs are problematic - you can't just connect two outputs together arbitrarily. You can with open-collector outputs but then one chip holding the signal low will make the signal low whatever the other processor wants. So even if you have just two processors, you need glue logic between the processors and the output from your electronics - glue that decides somehow if processor A or processor B should be the owner of the output signal. Possibly by having the glue logic behave like a watchdog monitor, checking if the two processors sends kick signals. If only one processor kicks, then that processors gets ownership of outputs. If both processors kicks, then other logic decides which one gets the priority.
But exactly what problem do you want to solve? Note that processors seldom fail. So your special logic may be the weak link, actually resulting in a combined circuit with less reliability than a single processor.
Another thing here is that having logic that switches with of two processors that owns an output is way easier when talking about a digital output - like driving a LED or a relay. But if that output is a serial link like USB, then you get into much bigger problems. If processor A is correctly registered and performing communication - how will you then manage to get processor B to be connected instead and in correct state to be able to continue? This in relation to the alternative - that the PC sees the keyboard being disconnected and one second later it sees it connected again (next processor getting connected to the USB link).
But even then, you would have issues in case we talk about a smart USB device where the device would have had a reason to store lots of local configuration or state information based on what communication that has happened earlier. Think about two identical gaming USB mouse that supports a local profile to set resolution and if some of the mouse buttons should have macro functionality and possibly instead generate keyboard key presses - the PC program that sends the profile would not know there are two mouse controllers that needs the same state information.
Anyway - your original post contains much too little information for anyone to really be able to help you.
... what if the "compare logic" fails.
Erik
That is probably the least of all problems involved.
1) I have to control 6 VFD in parallel. These 6 VFD’s to be connected to this controller. 2) VFD communication will be through serial communication. 3) VFD speed reference command can be given through communication or through analog output. Preference should be given to serial communication based. 4) There will be another communication port for the communicating controller to central control system. 5) The Display shall be touch screen type 6) There must be provision for connecting 6 Analog inputs. 7) There may provision of 20 DI & 20 DO 8) Controller will react depending Analog inputs given from the central controller.
In past projects, we found the most likly failure was the sensors and actuators. We designed the actuators such that a failure would not be critical and we had sensors to detect acuator failures. We had second and third controllers to sense but they were not always connected to the same sensors as the main controller. Control lines from the 'helper' controllers would enable or disable drive from the main controller. So, the 'helper' controllers were just redundant monitors, not parallel controllers. Bradford
But none of the above has anything with redundancy to do. It's just a list of a normal (typically non-redundant) system without any analysis of failure modes and recovery alternaties.
Redundancy would discuss what happens if a VFD fails. Who drives the VFD (data and power). Who supplies the data to display? What failures should be possible to detect? What fallback should a detected failure result in? How is a real failure separated from a broken sensor claiming to have detected a failure? How is everything powered? What happens if that power supply fails? What if the central control system fails? Or the link to the central control system? How do you know if the touch input works? What is implication of broken touch function? How do you know if a digital input is low because that is the correct value, or low because it is broken? What if the analog values are measured using a damaged voltage reference, giving huge scale errors?
It isn't meaningful to think about redundant controllers until you have evaluated every part of the total system and figured out all failure modes and what that would mean. It really is far more likely that your I/O fails or your software contains bugs, compared to probability of a controller failure.
Just for fun - what happens if one controller gets an issue with the oscillator, making it run at wrong speed. Which of the microcontrollers would know it has correct speed and the other runs at wrong speed? Asynchronous communication would obviously be very problematic with one processor running at wrong speed and probably having the baudrate similarly off.