While the use of Linux continues to sail along at a nice clip, the number of people kicking the tires is shrinking, for all the right reasons.
The Linux operating system (OS) has earned strong interest and adoption from those in the embedded software development community who are looking for cost-effective OS support for their latest embedded devices. In parallel, proprietary real-time OSs (RTOSs) offering robust arrays of services that are comparable to those in Linux have gained attention for safety-critical systems and large-scale telecommunications networks. In such applications, these complex RTOSs provide the capabilities that are needed, often including virtual memory, multiple independent levels of security (MILS), and volumes of middleware for security, communications protocols, and support for an array of development systems.
While Linux and complex RTOS products offer such attractive capabilities, they're also correspondingly difficult to learn and use due to these robust arrays of services. Linux includes hundreds of system services, virtual memory, and tens of millions of lines of open-source code. High-end commercial RTOSs also include many features and lots of code, making them (and Linux) a challenge to master.
Linux's complexity has created an industry dedicated to configuring and supporting it for use in embedded applications. These companies, most notably Wind River Systems and MontaVista, charge for their services, and their fees are well justified. Likewise, complex commercial RTOSs with hundreds of services, are generally expensive to license, often burdened with run-time royalties, and are relatively difficult to learn and use. For many high-end applications in defense and telecommunications, these complex OSs are necessary, and serve those needs well.
But what about the majority of applications where low-cost development and fast time-to-market are the primary goals and the system's technical requirements are relatively modest? Many companies developing electronic devices staff such projects with a few engineers in the hopes of containing cost. In these cases, there may be no room in the budget for commercial Linux support or in-house Linux gurus, nor for expensive proprietary solutions. Achieving fast time-to-market and low-cost development demand a simpler approach. There's little time to sort out configuration complexities, or to learn which of the many services are actually needed.
While Linux and complex RTOSs with similar features deliver abundant capabilities, they also occupy a fair bit of memory. If available memory is limited by physical footprint, cost, or power consumption constraints, or if low overhead and a rapid real-time response are needed, then it may be time to take an alternate approach. In such circumstances, a large Linux image or a complex RTOS might not cut it. What might be better is a smaller, simpler, more efficient solution, one that still meets the needs of the application, but doesn't impose unnecessary complexity on top. For such needs, a small-footprint, low-overhead, simpler RTOS might very well be more suitable.
One of the newer trends in embedded software involves designing simpler solutions for applications that don't need all the features. This concept applies to many embedded systems as they may not require virtual memory or hundreds of system services. Instead, many embedded real-time applications need just a few basic capabilities, such as priority-based preemptive scheduling, dynamic memory allocation and recovery, inter-task message passing, interrupt management, resource-locking semaphores, and timers.
Addressing these basic needs enables a simple RTOS to satisfy a large number of applications in consumer electronics, medical devices, industrial automation, test and measurement equipment, and wireless networking devices. Developers of these systems can minimize development time by choosing an RTOS that addresses their needs without excess complexity. Shortening development time pays additional dividends in lower development costs, faster time to market, and greater market share. For these applications, “less” actually is better, and delivers “more” for the developer.The “less is more” adage is supported by findings in recent survey of embedded developers by Embedded Market Forecasters (EMF). This survey reveals that developers who recently used certain RTOSs tended to complete their projects on time or ahead of schedule more frequently than those who used other OS. This observation indicates that the RTOS used plays a role in the timely completion of embedded development projects.
By limiting the complexity of the RTOS, fewer services have to be learned and used, and this makes them more likely to be used correctly. Certainly, some applications require virtual memory and other complex features, but many don't. It's better to determine the needs of the application, and then use an RTOS that meets those needs without overkill. Several small, simple RTOSs are available commercially, and most offer full source code, royalty-free licensing, and commercial support. These offerings are generally simpler and easier to use than “full-featured” OSs with their large repertoire of services.
Another recent survey of embedded developers, this one by CMP, indicates that developers may already be taking steps away from complex systems. As the figure below indicates, the number of developers not considering Linux for their next project jumped from 34% in 2006 to 48% this year.
(Figure from “Annual study uncovers the embedded market,”Richard Nass, Embedded Systems Design , Sept. 2007.)
While one could conclude that Linux is losing its overall appeal, these results don't necessarily indicate that. The results may imply that Linux is settling into the application areas for which it's the best fit, and not being considered in other areas as much as it used to be. Developers initially caught up with the hype of a “free” OS may have come to realize that the complexity and downstream costs more than offsets the zero initial product cost, and therefore have turned to simpler approaches that ended up successful. Hence, they're not considering Linux for future systems because they've found a better approach. Based on their experience, those developers will have a better knowledge of when and where Linux makes most sense and will be less willing to use Linux in the future unless it's absolutely needed.
Recent comments on this survey data by leading editors who cover the embedded systems space support the conclusion that embedded developers are beginning to consider alternatives to Linux. For example, Rich Nass, editor-in-chief of Embedded Systems Design (ESD), in reflecting on the CMP survey data indicated that the industry has turned the corner on the embedded Linux hype in a report covering the embedded systems market. ESD Editorial board member Bill Gatliff seconded that motion in stating, “We're finally turning the hype corner on Linux and realizing it's not right for all applications.”
Michael Barr, a former ESD editor-in-chief, concurred with Nass and Gatliff, commenting, “There always seem to be some interesting new technologies, but they are not always adopted. But Linux actually succeeded, and a lot of people were using it in telecomm apps and so on, for stuff that looks like a PC. Clearly that trend is continuing, but obviously at a slower pace.”
Matt Assay of C|Net points to the unexpected cost of Linux as being a factor. “When I was involved in embedded Linux, the No. 1 drivers of adoption were cost and flexibility. …embedded developers were adopting Linux because it was perceived to be free. In fact, I can remember more than one occasion when a big OEM opted not to go with Lineo because we charged for commercial support, tried to go it alone, and came back to us to purchase support six to nine months later after they failed. Good service always costs money, whether you do that service yourself or pay someone else to do it. Either you pay in terms of your own time/resources or you pay in terms of someone else's. There really is no free lunch.”
The “less is more” approach attracts developers that otherwise might opt to use Linux or a complex OS solution-not because Linux or large OSs aren't good technology and ideal for many applications, but because they're not the best choice for all applications, and developers are getting wise to this distinction. In many cases, developers realize that such large-scale solutions either can't handle hard real-time, small footprint, low-cost requirements, or they're overkill for those requirements and hinder rapid development. Projects with modest requirements are common, and those projects might be better suited to one of the many small RTOSs on the market.
For fast time to market, truly, less is more.
John A. Carbone is the vice-president of marketing at Express Logic Inc. He can be reached at email@example.com.