This all amounts to the effort of getting requirements right in the first place. Requirements should only state WHAT needs to be done. The design specifications should then concentrate on the HOW.
As for redundant processing, you need to look at the types of failures you need to protect against. If it is a multi-channel solution then you can demand that one team employ positively asserted logic while the second team employ negatively asserted logic. This will eliminate much of the designed in problems. If you need a third channel, then that could be in a different technology (I have done systems this way before).
With regard to the PMR (Pulse Maintained Relay) as a watchdog, you need the software to be able to flip the state based on the outcome of a series of tests and only when the back-stop in the main process is reached. Tying in the results of walking memory tests, checks on correct I/O operation and other sanity checks will make it quite useful as a means of determining the systems health or otherwise.
Of course, developing for Safety Critical Systems will mean an involvement in Certification, usually with the oversight of a regulatory agency or two. This will mean that your development process and documentation needs to also be very sound and of a quality that it becomes hard evidence that you approached the whole task properly.