Posted on November 02, 2015 at 22:39 I haven't taken this road, but I've studied it.
My biggest concern would be that you have to demonstrate that all the safety-related firmware has been rigorously designed and tested (including design reviews, code reviews, and full unit test). To reduce the effort involved with that, you could partition the system software into safety-related and non-safety-related, similarly partition RAM, and use the MPU to deny access to safety-related memory except by the safety-related tasks. (Unless your project can accommodate rigorous design and test of all the firmware).
Incorporating a safety-certified RTOS would presumably allow you to ignore that software (rather than having to qualify it yourself), ST's peripheral library functions would likely be judged inappropriate and should not be used in the safety-related functions.
Certified self-test libraries such as from Yogitech could be useful:
''fRSTL for ST’s STM32 MCUs is a set of software libraries addressing the STM32 microcontroller series, and meant to detect hardware random faults. They are an application-independent, off-the-shelf product designed to be easily integrated into safety-relevant systems.''
http://www.yogitech.com/en/press-and-news/press-release/frstl-software-test-libraries-stm32-microcontrollers-stmicroelectronics Use of an independent ''windowed'' watchdog is important to cover many hardware failures, the watchdog should reset the system to a safe state if program flow (monitored at ''very many'' checkpoints) is not occurring normally.
Your system's outputs should also be monitored and set to a safe state if there are discrepancies between the commanded value, and actual (to the extent possible).
This is a substantial topic...
