Going Commercial
Proprietary vs. Open Source RTOS Considerations

Perhaps the most important decision we make in designing a new electronic product with embedded computing is our choice of operating system (OS). As your product ages in the market, it is often the case that more and more embedded software will be developed for it. As the insulating layer between all that software and the underlying hardware, a good OS choice will allow you to evolve the hardware platform as technology advances, while protecting the compatibility of your (and third-parties') investment in software development. For many systems companies, the price of all that programming far exceeds the cost of development of the hardware platform, and the software components have a much longer life in the field, especially considering the evolutionary nature of software applications.

Your choice of OS can also have a profound effect on the acceptance of the product in the market, particularly for consumer applications, as the visibility of the OS and its limitations makes it a potential decision factor for the end customer. If a customer has previous experience with a particular embedded/device OS, or if they have mission-critical applications that are already supported on a particular OS, your product will probably get the nod, even over a more robust competitor.

Today, we have basically three options in choosing embedded or device operating systems. The first, which is gaining momentum daily, is open source embedded Linux (along with all of the commercially supported versions and variants.) Our second choice is one of the many commercial, small-footprint, hard-real-time operating systems. Our final option is one of the heavyweight commercial operating systems modified for embedded use. Each option has its advantages and applications, so despite anyone's claims of RTOS world dominance, we're not likely to see any of these disappear anytime soon.

By now, everyone developing device software has experienced the extolment of embedded Linux. It has it all, right? It's free, feature-laden, extensible, ubiquitous, and supported by practically the entire universe. Now, with companies like Wind River offering commercially-supported versions with a robust development ecosystem, you can have the best of both worlds using embedded Linux. When a new capability hits the scene, some of the thousands of developers worldwide will probably jump on the task of supporting it before you even hear the rumor. Because open-source development is unencumbered by the marketing and quality-assurance red-tape typical of commercial products, that Bluetooth stack (or whatever your system craves) is probably ready to go for Linux before any commercial vendor hits the streets with support from their proprietary OS. At the same time, reputable companies are standing by to support your development efforts with real, proven products that complement the open source offering.

What's not to like? Well, if you're really a hard-core open source devotee, and you choose to "roll your own," your time to market will probably be significantly increased while you finish the work required to port the system to your particular hardware configuration and customize it for your application. Depending on what changes you need to make and how your product is distributed, you may also have to be mindful of GPL license issues. If your device requires a small memory footprint or is cost-sensitive, the price of the extra memory you need may outstrip any savings you have on RTOS royalties.

Performance-critical applications may also need something a little more predictable than the typical Linux variant, which brings us to our second option - proprietary, hard-real-time operating systems. There are a number of these, and they've been successful in the market for years. Wind River's VxWorks and Mentor/Accelerated Technology's Nucleus RTOS are two very popular examples. While extensions for embedded Linux can improve its real-time performance, only a true hard-RTOS can give you absolutely predictable fixed latency. In addition, these operating systems have a much smaller footprint, allowing for both lower-cost and higher quality-of-service system design.

Aerospace, defense, and other high-reliability system designers may face additional standards and requirements that make open source OS unusable. In those cases, a properly certified version of a commercial RTOS may be the only viable option. One vendor that challenges this notion, however, is Lynuxworks, who points out that neither open source nor proprietary software is immune to security breaches, and that the hundreds of thousands of engineers scrutinizing open source can provide an effective screen for malicious code. Lynuxworks BlueCat Linux is designed for (nearly-hard) real-time systems with an easy migration path to their hard-RTOS (LynxOS, and DO-178B certifiable LynxOS-178), which are designed specifically for such applications.

While much is made of the royalty savings available with the open source option, some of the available hard-RTOS options are royalty free as well. Mentor's Nucleus, for example, is sold in source code form without royalties. A royalty-free, small-footprint, hard RTOS is the ideal combination for many systems that want the performance, footprint, and support of a commercial RTOS, but don't want to engage in royalty agreements and tracking overhead.

For RTOSs that require a royalty, the cost equation can still come out in favor of the commercial option. "We see a lot of use of VxWorks in very low-cost consumer devices with low margins," explains Glenn Seiler, product line manager for Linux platforms at Wind River. "Consumer devices at high volumes typically have a very small royalty, but the cost of the additional flash they would need to support embedded Linux can run $4 to $8 per device. It's a big decision point for them."

There are many potential hidden costs to the open source route, and it pays to be aware of them when making a critical design decision. As an example, in one design team's recent experience, they were initially ecstatic to find almost a dozen pre-developed implementations of a critical component of their system available in open-source. After several weeks of investigation, however, none of these proved to implement exactly the functionality they required, and all of them had code quality and reliability issues. By the time they investigated the options, chose a likely candidate, and implemented their changes, they admit it probably took longer, cost more, and gave them a worse solution than if they'd developed from scratch. They also were then required to deal with the licensing issues of the open source code they had modified.

Our third option usually ends up being an obvious choice for design teams that fit its profile. If you're designing a device that has direct interaction with Windows-based applications or even applications that need to run in both the desktop and embedded environments, you probably have few realistic options. You can't push your customer base to another, non-Windows desktop platform, and you will incur significant development overhead creating applications in two different development environments targeting two different OS types. You probably should seriously consider Microsoft's XP embedded, or one of their other device-targeted OS variants.

The good news here is that Microsoft provides a robust, well-supported development environment that makes moving applications between desktop and device easier than you'd fear, and almost as good as you'd hope. If you stick to some pretty straightforward development practices, you can use the same source code, IDE, and so forth for both your desktop and embedded development. XP embedded is a componentized version of the highly ubiquitous Windows XP, so you can select the parts of the OS that your device needs and save space by cutting the fat. You can also take advantage of the rich set of software IP available from the legacy of thousands of devices using the OS, and if you're still in hiring mode, you'll find more qualified windows developers in the world than just about any other type of software engineer.

Obviously, there's no universal, one-system-fits-all answer to the device OS question. For the foreseeable future, we'll be choosing from a menu of well-tuned choices that cater to our various tastes and needs. While open source is gaining momentum, it isn't likely to take over the embedded world just yet, as there are compelling reasons for the existence and use of the many available commercial solutions.

Kevin Morris, Embedded Technology Journal

February 14, 2006

[back to top]

Comments on this article? Send them to comments@embeddedtechjournal.com