How to choose an embedded RTOS

First consider not using an RTOS. If the work fits into a few periodic tasks and can be expressed with interrupt handlers and a super-loop, analysis and testing are easier without one. An RTOS pays off when processes with different priorities coexist and each has its own deadline.

A rule of thumb is whether you can keep expressing the priority relationships between processes in your own state machine. When that starts to break down, it is time for a scheduler. Conversely, an RTOS adds RAM and analysis scope for context switching, multiple stacks, and synchronization primitives.

Fix the applicable standard and level (SIL for IEC 61508, ASIL for ISO 26262, software safety class for IEC 62304, SIL for EN 50128) before deciding the architecture. The value of a certified kernel lies less in code quality than in the work products that come with it.

What consumes effort in certification is preparing requirements specifications, design documents, verification records, and traceability. A pre-certified kernel supplies these, for example as a Design Assurance Pack. The right comparison is the effort to produce the equivalent yourself versus the price of the pack.

A certified kernel always comes with conditions of use (a safety manual). It lists the APIs you may use, how interrupt priorities are handled, prohibited configurations, and the verification the application must perform; stepping outside it breaks the basis of certification. Obtain it early in evaluation and check that it does not conflict with your design policy.

If safety and non-safety functions share one processor, you must argue freedom from interference. The argument covers three directions: memory, execution time, and information exchange.

Memory is shown with partition separation by the MPU/MMU. Execution time is shown by scheduling analysis or measured traces proving that low-priority work does not cause high-priority work to miss its deadlines. Information exchange is guaranteed by design so that data flows only along defined paths.

Decide how to argue these three points at the same time as choosing the kernel. If you later find you cannot show headroom because trace is not available, you will have to go all the way back to the board's trace port.

Even with the same functions, the total cost can differ by an order of magnitude depending on licensing. Organize the options along these axes.

Source or binary (certification and audit need source and design documents), whether runtime licenses are required (this drives the total as production volume grows), license unit (per developer / per product / per site), and support period and renewal terms (for products maintained for ten years, continuity of supply is itself a requirement).

Even with an open-source kernel, you must comply with the license terms and decide who will provide long-term support. These two points, rather than feature differences, are the main reasons for choosing a commercially licensed version.

Being on the list of supported cores does not mean a port exists for your compiler and interrupt-controller configuration. Check the core, compiler, and BSP as a set of three.

Even when the kernel itself runs, sourcing TCP/IP, file system, USB, and GUI from different vendors inflates integration and verification effort. Decide first whether to source from one vendor, choose OS-independent components, or estimate the verification effort of mixing them.