Selecting the right RTOS for a project can be tricky business. Engineers often come to the table with predisposed opinions that can cloud their judgment and pull them in a direction that isn’t optimal. Let’s face it, many of us have been involved in an engineering decision where the choice was dictated by the loudest and most aggressive team member. Back when I was just a green, entry level engineer, one of my mentors, a now long retired project manager, taught me a technique for decision making that if done properly creates an unbiased result. Let’s examine this decision making technique and how it can apply to selecting the right RTOS for the job. (A ready-to-use template can be downloaded here)
Step #1 – Identify the selection criteria
In order to make an unbiased RTOS selection, development teams need to first identify important selection criteria that can be used to evaluate the RTOS. A detailed look at such criteria is beyond this articles scope but readers can learn more about the criteria by reading “7 Critical characteristics to consider when selecting an RTOS”. In summary, the seven key characteristics that need to be considered when selecting an RTOS are performance, features, cost, ecosystem, middleware, supplier/vendor and the engineers in the development team. Each characteristic can be broken down into sub characteristics that will be evaluated by each team members. For example, the performance characteristic might include RAM footprint, ROM footprint, context switch times, interrupt latency and low power capabilities.
Step #2 – Determine criteria importance
Not every criterion for RTOS selection is going to be equal to every other. For example, the fact that an RTOS conforms to the POSIX interface standard may be much less important than the RTOS having the smallest ROM footprint. Since all criterion are not created equal, the development team needs to go through each and rank them in importance. The ranking process essentially provides a statistical weight that provides more importance to one criterion over another. A typical ranking system example is to evaluate the criteria on a scale from one to five can be seen in Figure 1. Having the smallest footprint might be ranked five, while conforming to the POSIX interface may receive a three. The ranking helps the most important criteria hold more weight in the decision making process.
Figure 1 – Criteria ranking system
Step #3 – Select the RTOSes to compare
A quick internet search reveals that there are over 100 different RTOS offerings available which is far too many for any team to evaluate. Instead, development teams should identify no more than three to five RTOSes to evaluate. Development teams should identify RTOSes that are commonly used in their industry, are familiar to their developers and meet their system requirements. A good sampling will include both commercially available and open source solutions.
Step #4 – Identify the decision makers
In order to achieve an unbiased decision based on the criteria, developers need to identify teammates with the skills and experience to be involved in the decision making process. In most cases, the RTOS selection should include the teams’ software engineer and the software engineering manager. The project manager could be included but only if they are qualified to evaluate the RTOS specific criteria. The RTOS criterion and cost will most likely have the highest weight associated with them so if a decision maker can’t accurately gauge the RTOS the results could be skewed.
Step #5 – Create a KT decision matrix
With the important criteria and the decision makers selected, it is now time to create a form that can be used to evaluate the criteria for each RTOS that results in the selection of an RTOS. One of the methods that can be used is the KT decision matrix. The KT decision matrix allows us to evaluate our criteria against each of the RTOSes. For this example, the criteria are categorized and listed along left side of the matrix with the RTOSes along the top. Each RTOS has multiple rows so that each decision maker can evaluate each criterion. An example can be seen in Figure 2 and the template can be downloaded here.
Figure 2 – RTOS selection matrix
Step #6 – Evaluate the criteria
Each decision maker can now start out evaluation each of the criterion. In the example, there are three different RTOSes that are being evaluated. Each criterion is rated for each RTOS from best, three, to worst, one. No number should be reused. For example, the smallest RAM footprint is rated one, worst, for RTOS #3, rated two for RTOS#1 and finally three, the best for RTOS #2. If there were four RTOSes under evaluation, then the values would rate from one to four.
Each developer fills out their own column until the entire matrix is completed. In some teams that are highly opinionated it may be necessary to have each team member secretly fill out their ranking and submit it for compilation by a secretary or other non-interested party. A filled out matrix is ready for analysis and more importantly, the unbiased team decision.
Step #7 – Analyze the results
There are many ways in which the matrix can be analyzed for a decision but the easiest is to simply add up the total score for each RTOSes criterion and multiply it by the criterion weight. Each of these totals is then summed amongst all of the criterion. At this point, we have arrived at a decision. The RTOS with the highest score is the RTOS that best fits the needs of the project. Odds are, the decision is not going to make a lot of people happy. That usually happens when the cold hard facts are examined. The question really becomes, can we accept the right decision and are we able to pay for not (not are we willing to pay for it).
Selecting an RTOS without examining the facts, requirements and concerns is dangerous business. Many teams rush to procure “free” software only to discover that the total cost of ownership is higher than expected due to factors never considered. Teams should expect to pay for a commercial RTOS for the best balance of cost, quality and support. Determining just the right balance though is impossible to decide in any team meeting. Using the presented decision matrix is just an example of how teams can generate an unbiased opinion while still maintaining an eye on the most critical factors.