The open-source FreeRTOS was created by Richard Barry while working at WHIS. WHIS identified all the weaknesses in the functional model and API through a complete HAZOP analysis based on the capabilities of FreeRTOS, mitigated all weak points, and redesigned SAFERTOS using the IEC 61508 SIL 3 development lifecycle.
SAFERTOS and its accompanying Design Assurance Package (DAP) provide excellent performance and safety-critical reliability for safety applications while consuming minimal resources.
Since the FreeRTOS kernel and SAFERTOS share the same functional model, upgrading is straightforward. Many developers prototype products based on the FreeRTOS kernel and upgrade to SAFERTOS during the formal development phase.
SAFERTOS and FreeRTOS share a functional model and are very similar to use. However, compared to FreeRTOS, SAFERTOS:
• Has fewer application programming interfaces (APIs)
• Performs more error checking within functions
• Most API calls return status codes
• Requires applications to provide all stack, task control block, and queue buffer storage space
• Uses static allocation and does not provide heap functions
• Defaults to using the processor’s Memory Protection Unit (MPU) features
• Is redesigned to meet the needs of safety-critical software
Therefore, when migrating a FreeRTOS project to SAFERTOS, some work is required to initialize and run the kernel.
FreeRTOS internally hides memory management implementations, such as dynamically allocating stacks when creating tasks and allocating buffers for kernel data at kernel startup. FreeRTOS can also be configured to use static allocation mechanisms, where the application provides the corresponding memory, but most users prefer the allocation functionality provided by FreeRTOS.
FreeRTOS also offers many compile-time options that allow application designers to insert additional functional code into the kernel through hook functions that run during task switching, such as when creating or deleting tasks.
API Differences
API function names in FreeRTOS and SAFERTOS are generally consistent, but the parameters differ, such as in the task creation function.
Implementation in FreeRTOS:
Implementation in SAFERTOS:
WHIS provides documentation on how to upgrade from FreeRTOS to SAFERTOS, detailing the API differences between FreeRTOS and SAFERTOS.
Upgrade documentation and a simple SAFERTOS user manual can be accessed at https://www.highintegritysystems.com/down-loads/manuals-datasheets/safertos-datasheet-downloads/ for registration and download.
The abstract type names defined by RTOS and the #include files are also different. In FreeRTOS, an application file needs to include the corresponding header files for the APIs used (tasks, queues, semaphores, etc.), while a SAFERTOS application only needs to include the SafeRTOS_API.h header file.
Static Allocation and MPU
SAFERTOS requires applications to provide the memory space needed to manage tasks and kernel objects.
For example, both FreeRTOS and SAFERTOS create an idle task that runs at the lowest priority to ensure there is always a schedulable ready task in the system. The idle task cannot block and can be used for “background” application functions, achieving energy savings or other specific application needs. Clearly, the idle task requires a task stack and task control block. FreeRTOS allocates this space from the heap (unless configured to use static allocation), while SAFERTOS requires the application to provide these buffer spaces. Part of the reason is that in safety-critical systems, static allocation is often preferred because it is easier to ensure that all runtime environments have sufficient memory, but another fact to consider is that in most cases, the SAFERTOS interface layer assumes the use of the MPU.
Using the MPU means that application designers need to oversee the exact location of all memory structures in addresses, with kernel tasks and queue buffers being an important part of this. Additionally, the MPU mechanism typically has restrictions on the alignment and size of protected areas, and the allocated space must meet MPU requirements to avoid resource waste.
In FreeRTOS, it is necessary to ensure there is enough free space in the heap before calling xTaskCreate, while with SAFERTOS, it is necessary to statically pre-allocate and explicitly locate a buffer of the appropriate size and alignment for the stack and task TCB, and then pass pointers to these structures as task parameters to xTaskCreate.
Task Privileges and Kernel Function Encapsulation Layer
Each SAFERTOS task is assigned an operational privilege: privileged or unprivileged mode. Privileged tasks have the same permissions as the kernel code. Many CPUs support privileged and unprivileged modes, restricting the CPU instructions used in unprivileged mode, and users can switch between different privilege modes directly through software traps, exceptions, or interrupts.
Typically, as many applications as possible run in unprivileged mode, with each task providing a set of MPU parameters that are usually configured for the corresponding MPU domain during task switching.
When creating SAFERTOS tasks, an additional MPU region is added for each task to access the user task stack, and the application must ensure that the task’s stack complies with MPU alignment and size restrictions.
Unprivileged tasks also need to have execution access to the kernel API functions. Kernel APIs operate in privileged mode, and each SAFERTOS API function has a privilege escalation encapsulation, typically implemented using a system call exception mechanism. The API encapsulation layer will temporarily elevate task privileges when needed, allowing unprivileged tasks to execute kernel APIs, and will return to the task’s original privileges after execution. Since the actual API function names differ from the names at the time of calling, debugging can be inconvenient.
Although FreeRTOS can use a similar privilege escalation mechanism to support the MPU, it only provides limited MPU porting layer support. In SAFERTOS, we assume that application tasks run in unprivileged mode. In FreeRTOS’s MPU porting, tasks run in privileged mode by default, but tasks can choose to be created as restricted, i.e., unprivileged mode.
The increasing interconnectivity of embedded systems has led to complex operational environments and an increasing number of attack vectors, raising security demands. SAFERTOS is based on the FreeRTOS functional model, allowing users to quickly upgrade from FreeRTOS to functionally safe SAFERTOS. For more videos, documentation, and example projects, please visit the WHIS official download site.
END
Source:Micron Technology
Copyright belongs to the original author. If there is any infringement, please contact for deletion..▍Recommended ReadingThe World’s Smallest Linux Computer Is Here! Smaller Than a Passport, with Screen and Microphone FunctionalityThe Flash of the Microcontroller Is Full Again, Come Try This Lossless Compression Library heatshrinkThis Girl Who Doesn’t Understand Technology, With a “Seemingly Unremarkable Little Idea”, Took Down Countless Software Giants!→ Follow for More Updates ←