Real-time operating systems (RTOS) are finding their way into nearly two-thirds of all applications. The timing requirements for a modern embedded system have become so complex that attempting to build a system without an RTOS, while possible, is just fraught with additional complexities that can sink a product before it ever launches.

While RTOS’s have become very popular, I’m often concerned with the way in which teams go about selecting their RTOS. For most teams I talk to, when they consider an RTOS, the one criterion they look at is cost. But as engineers we should be evaluating several different criteria, and not just using data but also following a process to ensure success and repeatability.

In this post, we are going to examine the eight criteria that I consider when selecting an RTOS for an application.

1.) Security

For any device that is going to be connected to the internet, selecting an RTOS that has gone through security certifications and was built for security is a must. Security certifications for an RTOS are relatively new but will be an important criterion for any team that wants to make sure every component in their system is designed with security in mind. One immediate example is verifying that the RTOS has Arm’s Platform Security Architecture (PSA) certification at least to level one.

2.) Ecosystem

Having a strong ecosystem around an RTOS is critical to ensuring success. For example, developers should be looking at and asking questions such as:

A strong ecosystem will ensure that the RTOS is not only used and supported far into the future, but may also determine whether the team can get fast support for the community.

3.) Features

The feature that are available on the RTOS can make a big difference, not only on the amount of time spent debugging, but can also impact the software architecture. Developers need to look at the features that are available in their RTOS and verify that it:

These are just a few RTOS features that can dramatically improve the application robustness that I rarely see teams give full consideration to.

4.) Vendor

The vendor, the company that created and maintains the RTOS, should be carefully considered as well. A quick web search will reveal that there are over 100 RTOS’s in existence, many of which are no longer supported or used. Teams need to carefully look at the RTOS vendor and ask themselves:

There is nothing worse than selecting an RTOS and then being left to your own devices to work through problems or issues. The RTOS vendor should be looked at as a strategic partner that is critical to the products success.

5.) Middleware

An RTOS to some degree provides a foundation for the application software. That foundation is one piece of the product development puzzle. That puzzle also includes other components such as low-level drivers, file systems, graphical user interfaces, TCP/IP stacks, encryption engines, and much more. Developers should evaluate the middleware that is directly compatible with their RTOS.

Now, you might be thinking that you can use any middleware with any RTOS and compatibility is not an issue. This is true, but if you select an RTOS that has proven and supported middleware that has examples already available – development will go much faster and smoother. You may even get lucky and find that the RTOS and the middleware are written using the same coding standards and have a consistent look and feel.

6.) Performance

I rank performance a little bit lower on the list because I think this is one of the obvious criteria that developers will look at. Performance includes criteria like:

To some degree, performance between RTOS’s is starting to become a moot point. If you are running a modern processor at 200 MHz and up, losing a few clock cycles here or there is not going to be critical. However, if you are working with a more traditional microcontroller running below 100 MHz, every clock cycle will count. It’s important to take your application into account and determine if performance is even a concern.

7.) Cost

Yes, cost! The one factor that is at the top of every manager and bean counters list! As I mentioned earlier, the cost for an RTOS is important, but when you compare it to the labor for development and maintenance, even most commercial RTOS’s that require a royalty barely make the decimal point.

I don’t want to undervalue cost, but I’ve noticed we give this one criterion far too much weight when making engineering decisions. (Yes, software and tool vendors are probably dancing and giving a loud amen to that sentence).

8.) Engineering team

The last criterion that I often consider, although it does not necessarily hold a large weight in the decision is the engineering team. There are factors to consider about the engineer when selecting an RTOS such as:

The engineers' backgrounds, skillsets, and years of experience can all come into play when selecting the RTOS. Sometimes I’ve seen teams select a particular RTOS simply because the engineers were interested in using that RTOS. The choice was made purely on personal preference and not on any metric or application requirement. I think the engineers are important to consider and that they should not be overlooked.

Conclusions

As we have seen in today’s post, there is a lot more to consider when selecting an RTOS than just cost. Cost is certainly an important factor, but when considering the overall costs for developing and manufacturing a product, even a commercial RTOS would be less than a percent.

What’s more important is evaluating all these criteria and selecting an RTOS that best meets the application and development team’s needs. It may be that the cost for the RTOS is free, but then again it may not be. Only by carefully evaluating all the criteria can a development team make the right choice.

RELATED ARTICLES:

Jacob Beningo is an embedded software consultant who currently works with clients in more than a dozen countries to dramatically transform their businesses by improving product quality, cost and time to market. He has published more than 200 articles on embedded software development techniques, is a sought-after speaker and technical trainer, and holds three degrees which include a Masters of Engineering from the University of Michigan. Feel free to contact him at [email protected], at his website, and sign-up for his monthly Embedded Bytes Newsletter.