Embedded development: how to choose the right RTOS for the project?

　　 Choose the right one for a project RTOS It may be a thorny thing . Embedded developers often come to the negotiating table with preset views , These views may affect their judgment , And lead them in a non optimal direction . Many people have participated in engineering decisions , One of the choices is made by the loudest 、 Determined by the most active team members . Let's take a look at this decision-making technique , And how it chooses the right one for the job RTOS.

　　 step # 1– Determine selection criteria

　　 In order to make a just RTOS choice , The development team needs to first identify what can be evaluated RTOS Important selection criteria . choice RTOS The seven key characteristics to consider are performance 、 characteristic 、 cost 、 The ecological system 、 middleware 、 supplier / Engineers in vendors and development teams . Each feature can be decomposed into sub features , Assessment by each team member . for example , Performance characteristics can include RAM Occupied area 、ROM Occupied area 、 Context switching time 、 Interrupt latency and low power capability .

　　 The first 2 Step - Determine the importance of Standards

　　 Not at all RTOS Every criterion in the selection is equal . for example ,RTOS accord with POSIX The fact that interface standards may not have minimal ROM It takes up space RTOS important . Because all standards are not born equal , The development team needs to carefully examine every standard , And rank their importance . The ranking process essentially provides a statistical weight , This weight makes one criterion more important than another , Ranking helps the most important criteria take a greater weight in the decision-making process .

　　

 

　　 The first 3 Step – Choose what you want to compare RTOS

　　 Fast Internet search shows , There are more than 100 Different species RTOS Products to choose from , This is too much for any embedded development team , It's hard to assess . contrary , The development team should identify no more than three to five RTOS To assess the . Development teams should identify those commonly used in their industry 、 Their developers are familiar with and meet their system requirements RTOS. A good sample will include commercially available and open source solutions .

　　 The first 4 Step – Identify decision makers

　　 In order to achieve fair decision-making based on standards , Developers need to identify team members with the skills and experience to participate in the decision-making process . in the majority of cases ,RTOS Your choice should include the team's software engineer and software engineering manager . Project managers can be included , But only if they are qualified to evaluate RTOS The specific standard of .RTOS Standards and costs are likely to have the highest weight , therefore , If the decision-maker cannot accurately measure RTOS, The results may be biased .

　　 step # 5– establish KT Decision matrix

　　 After selecting important criteria and decision makers , Now it's time to create a table , Used to evaluate each RTOS Standards for , So as to choose one RTOS. One of the methods that can be used is KT Decision matrix .KT The decision matrix allows us to target each RTOS Evaluate our standards . In this case , The criteria are listed on the left side of the matrix ,RTOS At the top . Every RTOS There are many lines , So that every decision maker can evaluate every criterion . An example can be seen in the figure below .

　　

 

　　 The first 6 Step - Evaluation criteria

　　 Every decision-maker can now start evaluating every criterion . In this case , There are three different RTOSes Being evaluated . Each criterion ranges from the best three levels to the worst one for each RTOS Rate . No number should be reused . for example , about RTOS #3, The smallest RAM The occupancy is rated as 1, The worst ; about RTOS#1, The smallest RAM The occupancy is rated as 2; about RTOS #2, The smallest RAM The occupancy is rated as 3, first-class RAM The occupancy is rated as 3. If there are four RTOS Needs assessment , Then these values will change from 1 To 4 Rate .

　　 Each embedded developer fills in their own column , Until the whole matrix is completed . In some very opinionated teams , You may need to ask each team member to fill in their ranking secretly . A completed matrix is ready for analysis , what's more , Impartial team decision .

　　 The first 7 Step - The results of the analysis

　　 There are many ways to analyze matrices to make decisions , But the simplest way is to simply put each RTOSes Add the standard total scores , Then multiply by the standard weight . Then add all these totals to all the criteria . here , We have made a decision . The one with the highest score RTOS It is the one that best meets the needs of the project RTOS. Probably , This decision will not make many people happy . This usually happens when examining cold facts . The real problem is , Can we accept the right decision ? Can we not pay for it ?

　　 Conclusion

　　 Don't check the facts 、 Requirements and concerns on the choice RTOS It's a dangerous thing . Many teams rush to purchase “ free ” Software , But found that due to factors never considered , The total cost of ownership is higher than expected . In order to reduce the cost 、 Achieve the best balance between quality and support , The team should be business RTOS pay . However , It is impossible to determine the right balance at any team meeting . Using the given decision matrix is just an example , It shows how the embedded development team can generate impartial opinions while maintaining attention to the most critical factors .