Selecting the right RTOS is a critical step in any embedded software development project. Selecting the wrong RTOS could affect project costs, time to market and have real-time implications on the behavior of the system. When selecting an RTOS, teams usually focus just on cost but there are seven characteristics that should be considered. Let’s examine each one.
Characteristic #1 – Performance
RTOS performance is a critical factor to consider when selecting an RTOS. All RTOSes are NOT created equal and an attempt to save a few dollars can cost orders of magnitude more. When it comes to performance, developers have a variety of factors that need to be considered. First, memory requirements such as ROM, flash and RAM footprints need to be considered. RTOSes are powerful and with that power comes additional code and data needs. Second, processing speed such as interrupt latency and context switch times should be reviewed. A high quality RTOS will document these parameters for a variety of architectures and clock speeds.
Characteristic #2 – Features
Every RTOS doesn’t have the exact same features or the features implemented in the most optimal manner. Developers need to evaluate which features are the most critical to the systems success and select an RTOS that has those features. Developers may want to consider scalability, safety certifications or even the efficiency of memory protection schemes. A little thought about feature is whether the RTOS conforms to standard interfaces such as POSIX. Even the way in which RTOS tasks and objects are allocated could be an important feature. Many RTOSes use dynamic memory allocation for tasks which for resource constrained embedded system could be dangerous due to heap fragmentation and other issues. An RTOS that can statically allocate tasks might be the better choice.
Characteristic #3 – Cost
Undoubtedly one of the largest, if not only thought about RTOS characteristic is cost. Despite the huge efforts required in labor to develop robust software, no one wants to pay for it! Developers need to get over it and probably evaluate what an RTOS may really cost. A few considerations for commercial RTOSes are the upfront costs for licensing and any recurring licenses such as royalties. In additional to these obvious costs, developers need to also consider the total cost of ownership for the RTOS. That is, the cost to learn, setup, integrate and debug the selected operating system. Total cost of ownership for an open source RTOS can potentially exceed that of a commercially purchased RTOS due to lack of support, poor code quality and so forth.
Characteristic #4 – Ecosystem
Having the best performance, features and cost doesn’t mean a thing if there isn’t a large and vibrant community to support the RTOS. A software products ecosystem is a critical piece of the selection process in order to ensure ease of integration, support and product lifetime. When developers investigate an RTOS ecosystem, they should determine whether the RTOS is supported and adopted by their industry and the embedded software industry as a whole. They should determine whether there is support for a variety of architectures and processors or whether the RTOS is just a one trick pony. The availability of numerous examples and ports is also an important indicator that the RTOS is supported and has a strong community of users around it.
Characteristic #5 – Middleware
Many RTOSes come with middleware components or have third parties who have developed components that integrate into the RTOS. Developers should evaluate their RTOSes middleware and determine what the integration effort might be. Sometimes the integration is seamless while other times it is an obvious nightmare. Some RTOSes lack support for middleware and open source components need to be integrated which can lead to a variety of time consuming integration issues. Verify that the middleware has common components such as USB, TCP/IP, file systems and graphics generators before jumping in with both feet.
Characteristic #6 – Vendor
Take a good hard look at the vendor who developed, maintains and distributes the RTOS. Do they have a good track record dating back at least five, ten or fifteen years? Examine their source code and documentation. A good supplier with have meticulous documentation that answers many of the questions that would arise while integrating the RTOS into the system. No matter how good documentation gets, it will never be perfect. Testing how fast the vendor is to respond to question and support issues could be critical and save precious time and money getting the product out the door. Don’t just blindly trust. Be an engineer and put the vendor to the test and see if they squirm or roll up their sleeves.
Characteristic #7 – Engineering Team
The characteristic of RTOS selection that is probably the most common to overlook is the engineering team. The RTOS that is selected should minimize the labor intensity for the team and allow them to focus on product differentiators rather than increase it as they learn how to integrate and setup an RTOS. As much as we like to grow professionally as engineers, we should attempt to select an RTOS we are familiar with and can work most efficiently with. Sometimes development doesn’t work out that way but we should at least try.
Performance, features, cost, ecosystem, middleware, vendor and the engineering team are just examples of characteristics that should be evaluated when a development team is ready to select an RTOS for their product. As engineers we need to make sure we set aside our own biases and make decisions based on the facts. For developers interested in a method to perform an unbiased selection of an RTOS, download my RTOS Selection Matrix and read my DesignNews article “7 Steps to select the right RTOS”.