Choosing an embedded operating system
I was recently approached for help by a Mentor Graphics customer, who was planning a new project and needed to select an operating system. They wanted guidance with that choice. Of course, one is tempted to say that it does not matter which of our products they chose [as, between them, Nucleus RTOS and Mentor Embedded Linux do cover most possibilities], but I felt they needed something more objective.
There is actually a huge choice. Given that it is decided to purchase an OS, instead of developing something in-house [an expensive option which rarely makes sense], there is the choice between the “heavyweight” OSes, like Windows CE and various flavors of Linux, and around 200 other, mostly real time [RTOS], products. What the customer was after was a simple decision driven process, like a flowchart …
I did not know of the existence of such a tool and thought about whether I could create one. However, I quickly realized that too many of the parameters were inter-connected for a straightforward flow-chart to handle. Instead, I thought it would be better to formulate a concise list of key questions, the aggregate answers to which would lead to a decision. A comprehensive guide is now being developed and this will be the topic of papers, web seminars, conference papers etc. in the months to come – watch this space. Here, I can only give a taste of the kinds of questions to be asked:
Is your application real time? In other words, does it need to respond to external events in a very predictable fashion? If the answer is yes, then looking at a true RTOS may be your best option. Although real-time extensions may be available for other OSes, I might question the benefits of making such a choice.
Is memory size an issue? All embedded systems have some kind of limit to how much memory they can have, but if this is quite stringent, the choice of one of the heavyweight OSes may not be wise.
Do you have plenty of CPU power? Or is the processor you have only just about powerful enough for the application. Efficient CPU usage – low overhead, if you like – is a trademark of most RTOSes, which make them a good choice if you do not have power to spare.
Does your device have power consumption issues? Particularly, but not exclusively, with portable devices, power consumption is a key factor. The previous two parameters – memory and CPU power – are both significant here. You may also be looking for power management facilities within the OS.
Do you have a requirement to support obscure devices or unusual communications protocols? Although most RTOS products tend to have a wide range of middleware and drivers, Linux is likely to trump them when it comes to anything out of the ordinary. The validation of protocols should be checked, of course.
Does [or could] your target system have a memory management unit [MMU]? If not, the heavyweight OSes are unlikely to be an option, as they do require an MMU. Typically, RTOSes [with a few exceptions] are thread based [not process], so an MMU is not mandatory. However, in many cases, an available MMU can be used to provide inter-task protection.
What kind of security does your device need? How important is it to protect tasks from one another? If this is a requirement, then a process model OS may be a good choice. This includes all the heavyweights and a few RTOS products. Other RTOSes may, as I mentioned above, use an MMU to facilitate “thread protected mode”, which offers some security, with a lower overhead than process model.
Do you need to apply for certification for your application? This is mandatory for certain types of product in particular industries, like aerospace and medical. The certification process tends to be complex and expensive. It requires the availability of source code. The cost is also very sensitive to the volume of code to be processed, which mitigates in favor of the leaner RTOS products.
Do you require interoperability with enterprise software systems? If so, this may imply that one of the Microsoft products may be a good choice, as they are strong in this area.
What is the sale price of your product and what volumes do you anticipate shipping? Cost models for OSes vary. They may be royalty based, perhaps with a sliding scale on volume. They may be royalty free, with just an up-front charge per device/project. They may be “free”, requiring up-front tooling expenditure and perhaps an ongoing service/support charge. The OS cost must be factored into the overall cost of development and production. Furthermore, if the OS reduces memory and CPU power requirements, it helps minimize the bill of materials [BOM] of the product.
What is your past experience of embedded OSes? Do you have in-house expertise with specific APIs, like POSIX? If so, this can effect your choice. Linux uses POSIX, but this API is also available with many RTOSes. Your past experience with an OS company with support, documentation etc. is also well worth factoring in; I know that this is a strong driver for repeat business at Mentor Embedded.
This is a very broad guide, but I believe that if you methodically address the above questions, your OS choice will become, at least, clearer.
Any comments or suggestions for other selection parameters, by comment or email, would be very welcome.
