FreeRTOS-MPU and Functional Safety

Kernel
1

Hello everyone,

I am contacting you to know your experience regarding Functional Safety - IEC13849 and IEC 61508 - certification using FreeRTOS as RTOS.

I’ve been using FreeRTOS for many years and I’m taking my first steps in FreeRTOS MPU porting (Cortex-M4). The goal is to use FreeRTOS supported by hardware memory protection in a product to be certified for functional safety (PLd and SIL2).

In the past, I had already written a firmware certified as PLd and SIL2, but in bare-metal mode (NO RTOS).

In the new release (v11) of FreeRTOS kernel is released with a MISRA compliance file [MISRA C:2012], but (for my experience) a certification authority usually needs more analysis (coverage analysis, documentation, etc.) to certify a software – or part of it - in a functional safety context.

Does anyone have experience with this? Was it complex to certify the FreeRTOS kernel for functional safety purposes?

Thanks in advance.

Ps: I know there is SafeRTOS, but - besides cost reasons - I’d like to understand if FreeRTOS can be used in a functional safety product.

2

I’m going to give the unhelpful engineer’s answer: “It depends”. System’s are certified to IEC 61508, not components, so you can architect your system such that software under the control of FreeRTOS can’t do harm, or if it can do harm, the hazardous condition is detected by an external monitor in order for the system to be placed in a safe state.

I am aware of FreeRTOS’s use in many safety related systems, from syringe pumps to automotive ECUs to aircraft navigation - but these folk don’t share how they achieved that (through system design, or through a rigorous design/documentation/test process as per SafeRTOS).

You will see safety appears on our roadmap, so I’m interested in your use case. You can contact me on r dot barry at freertos dot org.

3

This is one of the most important parts. Much of the complexity will be determined by how much you want FreeRTOS to safeguard against. If you’re using FreeRTOS to make promises that your tasks will run in a safe environment then there is more to test and validate in the FreeRTOS kernel. If you make no claims about the kernel used, then your tasks can become more complicated as they need to implement the guardrails themselves.

Part of our safety work is determining the appropriate balance of validated functions - much like your use case would likely involve.

1 Like
4

Thanks Richard and Kody for your useful answers.

For my little experience in functional safety, in order to use FreeRTOS as a scheduler in a SRESW (Safety-related embedded software), two main points should be demonstrated:

Achieving spatial independence
Achieving temporal independence

The first point (spatial independence) is easy to achieve using the memory hardware protection (MPU), it’s strictly hardware dependent I know, but for my architecture (Cortex-M4) it’s the easiest way to achieve it (this solution is explicitly cited by 61508-3:2010 Appendix F).

Instead, proving temporal independence is little more complicated: in a sequential programming (or otherwise, in a single-task firmware), an error in temporal independence (or timing) can be monitored using a watchdog with time window (the method is cited in both EN 61508-2 and ISO 13849, and it’s the method implemented in my previous firmware).

In multi-task design it’s not easy to use a watchdog to detect a fault in timing (or temporal independence) between two or more “safety” tasks or between “safety” tasks and “non-safety” tasks. In addition, the scheduler (FreeRTOS) must be considered as a safety element, it would represent a potential common cause of failure of the independent elements.

Normally, a software to be certified does not have to be perfect, but it must demonstrate that it has implemented the useful mechanisms to detect possible faults.

I hope this discussion will produce a useful topic.

Ps: Thanks for your message Richard, I will contact you by email in the next days.

Pps: I knows FreeRTOS well enough to know that it works very well and its scheduler mechanism is very robust (of course if the priority and task are well designed), but for the certification authority this is not enough.

1 Like
5

“It depends” is also my experience with functional safety :slightly_smiling_face:

Usually, you have to certify your entire product/systems, meaning your entire hardware and software. If you want to use an RTOS as part of your software, you can certify it yourself along with your remaining software, or you can use a pre-certified RTOS like embOS-Safe or SafeRTOS.
A pre-certified RTOS comes with a certificate and necessary documentation which proves that it is already safe. embOS-Safe is based on embOS-MPU.