This issue marks the second installment of our large-scale survey of embedded systems developers from around the world. In May we examined the ways in which embedded microprocessors are evaluated and selected. This month we do the same for operating systems.
Note: Ranking every operating system is a tricky business because there are so many good choices available. Although we tried to list every significant embedded operating system in our survey, it's still possible we've omitted somebody's favorite. There's also one accidental omission: due to an editing error Micrium's uCOS was accidentally left off the survey. Had it been included, we feel it would have scored well. Our apologies to Micrium's customers and supporters.
We've already seen that a developer's loyalty to his operating system outweighs any loyalty to the microprocessor it runs on. How, then, does that operating system get chosen? We started by looking at who influences the choice of embedded operating system. As Figure 1 shows, responsibility is spread broadly across the organization, from software managers all the way to the purchasing department. The statistical “roll off” from the strongly influential positions to the less-influential ones is more gradual than it was for microprocessors. In the CPU survey, a few key positions influenced the choice of chip. With operating systems, the decision is much less centralized.
Figure 1: Who influenced the choice of OS?
For example, outside influences (such as customer requests or regulatory requirements) affected CPU choice in only 9% of cases, whereas more than 15% of operating systems decisions were strongly influenced in this way. Outside bodies had “some influence” in another one-third (33%) of cases. The marketing department also had a bigger say in choosing the operating system than they did in choosing the processor, say our respondents.
What type of operating system did these people pick? In close to half the cases (44%), developers chose one of the many commercial operating systems or RTOS products for their current project. The remainder were about equally divided among internally developed operating systems, open-source operating systems, and no operating system at all. Figure 2 shows the results.
Figure 2: What type of OS?
This data adds another point to the trend line we've been plotting for many years as developers move away from internal/proprietary operating systems and toward commercial alternatives. A few years ago, the split was about 50/50. Before that, it was slightly weighted toward in-house operating systems. The number of developers who choose to “roll their own” has steadily declined over time as they either retire or die—or simply succumb to the financial logic of buying versus building an operating system. To be sure, a commercial OS isn't right for every developer or every project (more on that later), but the trend is clear: in-house OS projects are becoming few and far between.
Part of the movement toward commercial operating systems is fueled by the rise of 32-bit microprocessors. Not surprisingly, 32-bit users are much more likely to run a commercial operating system on their processor than 16-bit or 8-bit users are. The ratio drops from 55% for 32-bit users to just 19% in the 8-bit camp.
Conversely, the number of 8-bit developers running no operating system at all approaches 50% while barely 8% of developers using a 32-bit processor run it “naked.” The number of 8-bit users who use a commercial OS is much higher than the number of 32-bit users who don't. The 16-bit contingent is about evenly split: 31% use a commercial OS while 26% use none at all.
Reasons behind the decision
Zeroing in on the sizeable fraction of developers who don't use a commercial operating system, we asked them why. As you might expect, there were a number of explanations and some respondents gave several reasons. Nevertheless, we found some clear commonality and some food for OS vendors' thought.
Figure 3: Reasons for not choosing a commercial OS
The predominant reason for avoiding commercial operating systems was simply because there was no need. As Figure 3 shows, more than half of the noncommercial contingent simply doesn't see a need to buy or license an operating system. Whatever they've got now is working for them. Beyond that, almost half (48%) cited cost as a barrier. The third most commonly cited reason was to avoid reliance on a commercial supplier. That's a peculiar attitude, given that none of these people voiced a similar concern about their microprocessor supplier. On the other hand, you have to buy a microprocessor from someone; there is no open-source alternative for hardware.
Following these top three concerns, the responses fell off to just 20% or less. Some said commercial operating systems use too much memory or lack some important technical feature. Incompatibility with existing code was a common complaint, which makes sense for the developers who already use something else and don't want to change their OS calls.
Figure 4: Commercial OS factors
On the opposite side of the coin, we asked the commercial operating system users how they made their specific decision. What factors influenced their choice of operating system and what was significant? Cost ranked first and second, with overall cost edging out royalty payments in importance (see Figure 4). Embedded systems developers can be almost pathological about avoiding royalties; programmers despise them and ASIC designers hate them. The thought of sharing revenue long after the product has shipped rubs many engineering managers the wrong way. The situation is made worse because the very products that ship in the greatest volumes are generally those with the thinnest profit margins. The licensee and the vendor feel like they're at cross purposes: the products that hold the promise of the greatest royalties are the same products where the developer wants to cut costs to the bone.
Good software tools ranked a strong fourth among developers, echoing the sentiment from last month's installment regarding processor selection. Interestingly, networking support ranked fairly highly among the criteria used to evaluate commercial operating systems, suggesting that network protocol stacks are one thing many programmers don't feel comfortable writing themselves. That's reasonable, given that network stacks are complicated, regulated, and totally unglamorous. They're pass/fail coding projects: either they meet specification or they don't. Quality is seldom an issue, so there's little room for improvement or creativity. Finally, the trio of documentation, technical support, and vendor reputation all made the top 10, again reinforcing the important roles that trust and reliability play among developers.
Your next operating system
Looking ahead, we asked developers what general class of operating system they'd likely use on their next project. Regardless of what they're using now (if anything), what do they plan to use next? Here the data took an interesting turn.
Reinforcing our earlier trend, the no-OS category scored badly, dropping by almost 5%. In other words, some 4.6% of developers who aren't using any operating system now said they were likely to use some form of OS in their next project. Likewise, the in-house OS camp lost adherents, with about 4% of them switching to something else, as Figure 5 shows. Even the ranks of commercial OS customers thinned a bit.
Figure 5: OS for next project
The winner in all this? The open-source operating systems, namely Linux. Of all four categories, only open-source gained believers, and it did so at the expense of all the others. Broadly speaking, developers from all categories are now looking at open-source operating systems for their next project, regardless of what they're using now.
Rather than beat around the bush, we came right out and asked developers whether they'd consider adopting Linus Torvalds' offspring and why. Nearly 75% said they'd either use Linux in the future or were already using it now. Figure 6 displays the breakdown.
Figure 6: Interest in Linux
About 40% have Linux in the bag. They're either using it now or plan to use it soon. Another one-third are leaning that way but aren't ready to make the jump right away. Among the Linux advocates, most cited low cost as the primary attraction, with adaptability and/or extensibility a close second (see Figure 7). Combined with the 43% who identified “personal control of features” and the 39% who said it “avoids commercial alternatives,” Linux appeals on an almost philosophical level. None of the top four answers were even technical in nature; they were all intangibles. Ironically, the two responses that were technical showed up as reasons for not using Linux.
Reasons not to use Linux
In the opposing camp, performance and memory usage ranked second and fourth, respectively, for reasons to avoid Linux even though they ranked fifth and sixth on the list of reasons to use it. Linux has become a kind of programmer's Rorschach test. Developers can see anything they want in its convoluted features. See Figure 8.
Figure 7: Reasons for considering Linux
Figure 8: Reasons for not considering Linux
Most anti-Linux developers said they wouldn't consider it simply because it was incompatible with their existing code. In other words, they've already adopted another operating system, RTOS, or kernel and don't want to port their drivers and applications to Linux. A good number also dinged Linux on its performance; more than 28% felt that it just wasn't up to the task. “Legal ambiguity” got only 14% of the vote, so it's become less of a concern than in past years.
Interestingly enough the issue of cost, which ranked seventh among reasons not to use Linux, was also the very first reason given for its appeal among supporters. Obviously there's no consensus on what it really costs to adopt Linux. Commercial OS suppliers claim (predictably enough) that Linux is a potential drain on precious developers' time and that the hidden cost of self-support outweighs the up-front cost of licensing a commercial operating system. As our results show, at least some of our respondents believe that to be the case.
A sizeable portion (18%) gave “other” as their reason for not evaluating Linux. The most common among those was the absence of any requirement for an operating system at all, or that it was overkill for their application. Several developers also commented that the learning curve was too steep; their schedule wouldn't allow them to learn an entirely new operating system and take on its configuration and management tasks.
“Real time” is in the eye of the beholder, and when we asked developers if their current project included real-time requirements nearly 90% responded in the affirmative. In quantifying their real-time deadlines, the results were spread over times that cover a few orders of magnitude. The mean time was about 400μs, but the nature of the survey forced the answers into specific brackets. Overall, about 75% chose deadlines of under 1ms with the remainder over 1ms. A significant portion (10%) said they had real-time deadlines of under 1μs.
Commercial vendor survey
Figure 9 details operating system market share among our survey takers. To no one's great surprise, Wind River's VxWorks comes out the clear leader, ahead by one-third over the next-closest competitor (Windows CE), which is itself well ahead of the third-place product. Indeed, VxWorks has twice the market share of any other commercial OS save Windows CE.
Figure 9: Current commercial OS
Having said that, no single product garnered more than 19% of the results. The market is clearly fragmented and except for the first few products, the differences among them are slight. The number of responses tapers off gradually between the range of 9% and 1%, for example. A few companies offer multiple products. For example, Software Components Group's pSOS operating system is now part of Wind River, so that company collected 25% of the responses.
Under a cross-licensing arrangement, ThreadX is available through both Express Logic and Green Hills Software, so we deliberately listed it twice in our survey. Interestingly, the Green Hills distribution got a 50% stronger response (3.2% versus 2.2%) compared with Express Logic, the original source of ThreadX. Microsoft products came in second and fourth, with a combined 22.2% share of responses, destroying the stereotype about embedded programmers' antipathy toward Microsoft.
Symbian's EPOC (which stands for electronic piece of cheese) got a few dozen responses, mostly from developers of handheld devices. Wind River's Platform NE Linux drew the fewest responses, due in part because the product (and its name) is so new. Any product with Linux in its name (there are six) drew a combined 19.3% of the responses, making the open-source operating system the nominal winner in our survey.
Past, present, future
Before looking ahead, let's take a quick look back to see whether developers are still using the same operating system they used in their previous project. About half said they'd switched operating systems (44% versus 56% who remained loyal). Among the slight majority who remained with their previous OS, the most popular reason was essentially inertia: they were happy with their current operating system and saw no compelling reason to switch (57%). The second-most popular reason given was to maintain compatibility with their existing software (54%), followed by a desire to maintain their existing software tools (46%) or their existing expertise with that operating system (45%). Experience definitely counts for something.
Among those who did switch operating systems, a hefty 40% explained that their microprocessor or other underlying hardware had changed from the previous project, precipitating the change in OS. The next three responses, however, all indicated the effects of good old-fashioned competition. Hundreds of our respondents switched operating systems because the new one had better features (32%), better development tools (24%), or a better growth path (23%). A significant percentage of developers (20%) switched because the new operating system was cheaper, although few of them gave that as their primary reason for switching—it was simply a bonus. On the flip side, exactly the same number of developers said the change was forced upon them; they would not have changed operating systems, given the choice.
That covers yesterday and today—what about tomorrow? Using the same list of commercial operating systems, we asked respondents which ones they'd consider using in the future and how seriously they'd consider them. The results are summarized in Figure 10 and appear in the same order as in the previous chart.
Figure 10: Commercial OS respondents would consider
What's immediately apparent is that anything with Linux in its name will make it onto the short list of potential operating systems for the next project. If developers were planning simply to stick with their current OS the graph would be neatly sorted in a gradual, almost monotonic, ranking from top to bottom. The fact that the responses on the chart are somewhat ragged says that many developers are about to stray.
We can create a loose “affinity rating” by combining the highly-likely and somewhat-likely responses for each commercial operating system to see which ones people are most inclined to consider. Wind River's VxWorks gets the highest affinity rating, at 20.5, meaning one-fifth of respondents would consider using VxWorks at some point. Given that just over 18% use it now, that's good news for Wind River's salespeople. Paradoxically, the news is ever better for last-place Kadak and its AMX product. Since just 0.7% of our survey takers use AMX now but 2.2% are likely to consider it, there's some real upside awaiting the smaller RTOS companies.
There's clearly much more information to be gleaned here. In a future issue we'll look at the delta between current RTOS usage and planned usage. For example, does experience with a given operating system breed familiarity or contempt? Do users of a particular OS tend to be more loyal than others, and if so, who's losing business to whom?
If we combine the somewhat-unlikely and very-unlikely-to-consider responses we see that every operating system in our survey scored between 60% and 80% on the “apathy scale.” This is a small spread compared with the 10:1 difference between the high and low ends of our affinity ranking that I previously mentioned. Red Hat Linux garnered the lowest apathy rating, suggesting that relatively few developers are predisposed to dislike that operating system. VxWorks, Windows CE, and MontaVista Linux all ranked close behind. These results probably represent simple brand-name recognition. Developers aren't likely to say they'll use an operating system they've never heard of, but they might give a well-known operating system some consideration.
Still, even the lowest “apathy rating” is well above 50%, meaning none of the operating systems appealed to even half of our survey-takers. In fact, many products held no attraction for three-quarters of the group. It seems there will never be unity in the embedded operating system market, and that no single vendor can ever dominate this area. There's no shakeout in sight, and the variety and selection of embedded operating systems just keeps getting better.
Jim Turley is the editor in chief of Embedded Systems Programming. You can reach him at .
How come there is no mention of NET-BSD or Free-BSD in this article? I have been in embedded system design for the past 15 years and NET-BSD is a viable choice for any embedded system design as long as the BSP for the hardware is available.
– Hamid Marshall