Code Isolation for Functional Safety

[arthiJan]

HI,

  I am considering the use of STM32F0 device for my project. How do I isolate the safety related code(for functional safety)  from the general code, so that a f/w update on the general code doesn't affect the safety related code? Are there any hardware provisions on the STM32 devices to help me isolate these sections? Or are there any software means to isolate the two?

[arthiJan]

​Chris,

What you are describing is exactly what I am looking for! Thank you very much for your message. How do I restrict access to safety related RAM and peripheral resources? Is this done by the FreeRTOS? Could you please point me to some resources that talks about how to achieve this? Thanks very much once again!!!

[Chris1]

When using an RTOS with MPU support, essentially, memory regions are pre-defined for the tasks in your system, and variables used by each task are located in the appropriate regions using linker directives, as AvaTar mentioned. The RTOS reconfigures the MPU to match the predefined regions for each task whenever context switches occur.  

https://highintegritysystems.com/downloads/white_papers/Using_an_MPU_to_Enforce_Spatial_Separation.pdf

[arthiJan]

​Thank you very much for the idea and white paper. Would firmware update(or access to FLASH memory) also be handled by RTOS such that only the non-safe code gets overwritten?

[Chris1]

I don't know if that is a typical safety requirement. Many firmware update scenarios replace the whole application with the new version (done by the manufacturer, not necessarily an end user). The firmware can be designed to test the flash memory contents to ensure that it's self-consistent (e.g., computed checksum matches checksum determined at compile time).  

Fully secure firmware update / access control is a whole topic of its own (involving digital signatures, encryption, secure bootloader, etc.).  If secure end-user firmware update is a required feature along with functional safety, you may have to navigate both areas...

[arthiJan]

​My concern with updating the whole application fw is then the need to get the code certified to safety standards every time there is a small fw upgrade for the non-safety portion of the code. Are there any workarounds to where I can get by, without having to get code certified if I change just the non-safe code? 

[Chris1]

For the functional safety standard that I am familiar with (IEC 61508), you need to follow a suitable development process to produce or modify safety-related firmware, which includes a lot of documented reviews, analysis of potential impact to safety, validation and verification testing, etc.  

If you follow such a process, you can revise firmware in a certified device. Modifications to non-safety related code (in a system where you can claim isolation) provides a basis for doing less analysis / test (for example, not repeating all the validation and regression tests for the safety requirements), depending on the safety integrity level of the device. 

[arthiJan]

​Got it, Chris! Thank you very much for all your suggestions. They have been very useful to me.  One last question 🙂  Did u mention that FreeRTOS also has the same level (or similar) of resource management capabilities as that of SAFERTOS? I don't know if our budget can accommodate SafeRTOS. Do you have experience with both of them?

[Chris1]

I have used SafeRTOS and FreeRTOS / OpenRTOS; they are very similar, the main difference is that SafeRTOS comes with all the safety-related documentation that should satisfy assessors that the RTOS can be included in your certified product (and the cost is a lot different...). "Smooth path to certifying SafeRTOS within an application".   

FreeRTOS-MPU has all the functionality of SafeRTOS (possibly more), but I don't know how you could justify that it is suitable for use in safety-related systems.

[AvaTar]

> ... and other code is not permitted to access those resources. 

I would not exactly agree.

Non-safe code must be able to read safa data. It is forbidden to write/change them, though.