Why RTOS Functional Safety Certification Matters Even If You Don’t Need It

When you evaluate an RTOS, you probably start with its memory footprint, scheduling behavior, and APIs. You want to know whether it fits your processor and works with your tools.

Then you reach the RTOS functional safety certification section and think, “Our product doesn’t need certification.” So you move on.

Certification can sound like something reserved for automotive braking systems, medical devices, and industrial protection equipment. For a general-purpose controller, it may seem unrelated to the problems on your desk.

Early in my career, I was given an RTOS to use on a project. It wasn’t certified, and our application had no certification requirement. Unfortunately, we spent more time fighting RTOS bugs than developing our application code.

We didn’t need certification. We needed an RTOS we could depend on. Looking back, a better understanding of how that RTOS had been developed and tested could have saved us considerable stress and debugging time.

That’s where RTOS functional safety certification becomes useful. The engineering work behind it can benefit your project even when certification isn’t a requirement.

In How to Add an RTOS to a Bare-Metal Embedded Application in 45 Minutes, we added PX5 RTOS to an existing STM32 application using IAR tools. Getting the scheduler running was straightforward. Now, let’s examine the development and testing behind it.

In this post, we’ll explore what RTOS functional safety certification provides, how PX5 supports developers who need it, and why it also matters when your product has no certification requirement.

Let’s dig in!

What Does RTOS Functional Safety Certification Tell You?

Consider an industrial controller that monitors temperature, controls a heater, records events, and communicates with a supervisory system. Suppose its safety requirements specify that it must disable the heater within a defined time after detecting an overtemperature condition.

That requirement interacts with several parts of the design. The sensor must provide usable data. The software must recognize the condition. The shutdown activity must execute within the required response time. The output circuitry must actually remove power.

Functional safety concerns the correct operation of those protective functions. The RTOS is one of the software dependencies involved in making them work.

For a certified RTOS, there is evidence describing how that component was developed and verified. For example, PX5’s functional safety overview discusses the documented lifecycle, testing, and safety manual behind its certification. The manual tells developers how to use the component within the conditions covered by its assessment.

That gives you something concrete to evaluate.

For example, PX5 reports 100% statement and branch-decision test coverage for its RTOS, along with static analysis. Statement coverage indicates which statements executed during testing; branch coverage examines the decision outcomes exercised. Those measurements help expose gaps in the tests. They cannot, by themselves, establish that our controller always shuts down safely.

We still need to verify the complete path from temperature measurement to heater shutdown. The component evidence provides a starting point for that work.

Where PX5 Fits: RTOS, File System, and Networking

Our example controller has more than one software dependency. It schedules activities, stores information, and exchanges messages. Each service introduces code whose behavior the team needs to understand.

PX5 provides those services through separately selectable components: PX5 RTOS, PX5 FILE, and PX5 NET. Its published product information and supplied overview identify certification coverage for all three at the following levels:

Standard	Application area	Level or class
IEC 61508	Electrical/electronic systems	SIL 4
ISO 26262	Automotive	ASIL D
IEC 62304	Medical device software	Class C
EN 50128	Railway software	SW-SIL 4

These are the highest safety integrity levels or software safety classes defined by the respective standards. SIL 4, ASIL D, Class C, and SW-SIL 4 belong to different standards; the applicable certification depends on the product and its requirements.

For our controller, the RTOS might schedule the temperature-monitoring and control activities, while the file system records events and the networking stack handles supervisory communications. We can select the components the design needs, with supporting evidence available for each.

The architecture still determines how those services interact. For example, recording a diagnostic event should not delay a required heater shutdown. That behavior must be established through the application design and verified on the target system.

What Changes When Your Product Needs Certification?

If your product requires RTOS functional safety certification, the immediate value is the ability to reuse applicable component evidence. You can focus more of your effort on the application-specific behavior while building on the supplier’s completed work.

PX5 describes its documentation package as including the certificate, safety manual, technical report, and certification report. Together, these documents explain what was assessed, the conditions for using the software, and the verification results supporting it. Its presentation on PX5 and IAR functional safety also explains an integration detail: the generic RTOS code has certification evidence, while the processor-specific binding still needs to be addressed in the device’s certification work. PX5 supplies supporting documentation and tests for that binding.

That makes the next steps fairly practical.

First, identify the safety requirements your product must meet. For the heater controller, that includes defining the shutdown behavior and response time based on the system’s analysis.

Second, obtain the documentation for the intended component release and confirm its scope. Read the safety manual early enough that its conditions can influence the architecture, configuration, and tool choices.

Third, turn those conditions into integration and verification tasks. Determine what evidence is needed for the processor binding and how the application will demonstrate correct use of the component.

For our controller, we would still examine thread priorities, blocking behavior, error handling, and the hardware response. A shutdown function that waits indefinitely for a logging mutex cannot meet its required response time, even when the underlying RTOS and file system are certified.

That is where the engineering benefit becomes tangible: there is a defined body of component evidence to build on, and a clearer boundary around the work the application team must complete.

Why You Benefit Even Without a Certification Requirement

Now, let’s return to the team that skipped the certification section. Its controller has no formal RTOS functional safety certification requirement. What does it gain?

One useful detail appears in the PX5 RTOS FAQ: the standard RTOS code base is certified. Developers do not need a separate safety version to benefit from that work. The same RTOS code undergoes the verification and certification process, whether or not the application using it requires certification.

Think about how you investigate an intermittent failure. You examine recent changes, inspect thread interactions, check memory usage, and try to reproduce the problem. Every software dependency is another place you may need to look.

Knowing what verification has been performed on a dependency helps you evaluate it before integration. You can ask informed questions about testing, supported usage, and known limitations. You also have a documented basis for selecting it during a design review.

Those benefits matter on ordinary development projects too. An unexplained lockup in a data logger still consumes engineering time and frustrates customers, regardless of whether anyone plans to certify it.

There is also a potential benefit when product requirements evolve. Suppose a later controller variant needs formal safety assessment. Starting with a component that already has supporting evidence can reduce the component evaluation work needed for that transition.

You would still check the applicable release, configuration, and conditions of use. But the original selection gives the team something useful to build on as the product grows.

Why the Development Tools Matter Too

The previous blog used IAR tools to build and debug the STM32 application. That connection becomes useful here because IAR offers certified functional safety toolchains with supporting safety documentation.

The relationship is easiest to understand by looking at what each part contributes to the safety narrative.

During build time, the development tools compile, assemble, and link the firmware image. During runtime, the device executes that image, including the application and its PX5 components. Evidence for the tools and evidence for the runtime software address different parts of the development process.

For a safety project, you would select the appropriate IAR functional safety edition and version, follow its Safety Guide, and consider those conditions alongside the PX5 documentation.

There is also a direct engineering connection. Bill Lamie’s article on RTOS certification describes PX5’s use of IAR code coverage tools in its verification work. This connects the toolchain discussion directly to the verification evidence behind the RTOS.

Together, the runtime components and development tools provide evidence the team can incorporate into its own process. Figure 3 shows where each fits.

Final Thoughts

When you compare RTOS options, performance, memory usage, and API familiarity will always matter. RTOS functional safety certification adds another useful question: what evidence supports trusting this component in the application you are building?

PX5 makes the RTOS functional safety certification question relevant to both certified and everyday products. Its standard RTOS code base carries the underlying verification work, while its RTOS, file system, and networking components provide certification evidence for projects that need it. IAR’s functional safety tools complement that work during development.

As you evaluate your next RTOS, ask which release the certificate covers, what safety documentation is available, and what integration work remains for your team. The answers can influence your architecture as much as a benchmark or memory-footprint table.

To explore the documentation available for your project, review PX5’s functional safety information.

You may never need to certify your product. But you still need an RTOS you can depend on. Understanding how it was developed and tested belongs in your selection process.

---

Want embedded engineering insights like this delivered to your inbox? Sign up for my Embedded Bytes newsletter to get the latest posts, insights, and hands-on tips delivered straight to your inbox.

Frequently Asked Questions

What is RTOS functional safety certification?

RTOS functional safety certification is independent, third-party evidence that an RTOS was developed, tested, and documented to a recognized safety standard such as IEC 61508, ISO 26262, IEC 62304, or EN 50128. The evidence typically includes a certificate, safety manual, technical report, and certification report. Together, these define how the component was verified and the conditions under which it can be used safely.

Do I need a certified RTOS if my product doesn’t require certification?

No, most products do not need a certified RTOS. However, the engineering work behind certification, including a documented development lifecycle, high test coverage, static analysis, and a defined body of verification evidence, still benefits ordinary projects by reducing risk during component selection, integration, and debugging.

What functional safety standards does PX5 RTOS cover?

PX5 RTOS, PX5 FILE, and PX5 NET are certified to IEC 61508 SIL 4, ISO 26262 ASIL D, IEC 62304 Class C, and EN 50128 SW-SIL 4. These are the highest safety integrity levels or software safety classes defined by each of those standards. The applicable certification depends on the product and its safety requirements.

What is the difference between generic RTOS code and the processor-specific binding for certification?

The generic RTOS source code carries the vendor’s certification evidence and is portable across supported processors. The processor-specific binding, which is the small layer that adapts the RTOS to a particular MCU, still needs to be addressed in the device’s own certification work. PX5 supplies supporting documentation and tests to help teams cover that binding.

Do I need a separate safety version of PX5 RTOS?

No, PX5’s standard RTOS code base is the certified code base. Developers do not need a different safety variant to benefit from the underlying verification work, which also makes it easier to move a project into a formal safety assessment later if requirements evolve.