The on-going and polarizing debate between true believers in open source Linux on the one hand and real-time OSes on the other seems to me to be pointless and unproductive. The assumptions behind the debate seem to be that chosing an appropriate embedded OS is an either/or choice.

In technical discussions, such polarized views have no place because in hardware and software engineering there are no absolutes. Everything is situational, conditional and relative to the current application and system environment, as well as contingent upon the details of the current design and the cost and performance tradeoffs involved.

Reducing what could be meaningful dialog to a simplistic debate distracts us from careful consideration of a number of important issues that will dictate the future direction of embedded operating systems. Some of the questions I would like to see discussed include:

Question #1: Do we need to rethink the basic structure of the building blocks of an OS - schedulers, ISRs, mutexes, etc. - so that they reflect the new environment in which embedded systems operate, especially in relation to multicore?

Since I am a technical journalist and not a practicing engineer, I don't have the depth of insight into RTOSes that most of you have. But with only a few exceptions, RTOSes don't seem to have changed much to accommodate demands of the new environments, at least in terms of key features. Most changes appear to be "bells and whistles" bolt-ons to the basic OS structure, not fundamental changes.

There are exceptions. For example, Express Logic has looked at modifying the RTOSes used in multicore designs, creating an underlying dimensionalized data structure in order to keep track of multiple data array objects associated with each core. Green Hills is making significant inroads in building rock-solid and secure RTOSes. MontaVista continues to play a role in open source Linux OSes and Wind River is involved in developing standards for multicore software development.

But there still remains a lot to be re-evaluated and redesigned, or thrown out all together.

Question #2: What is the best way to add virtualization to an embedded system--as an external add-on, or as an integral feature of the RTOS?

Virtualization, especially in the embedded space, is being seen as a way to simplify some of the serious programming and security problems that multicore designs with multiple OSes present. Some companies are simply adding an additional virtualization service that operates outside the kernel.

Others, particularly those offering message-based microkernels, have found a way to use the internal interprocess communications (IPC) protocol to implement virtualization. There is also work under way within the Multicore Association to develop an industry standard virtualization mechanism.

Question #3: Do RTOSes need to be modified to reflect the ubiquitously connected environment in which embedded devices and microcontroller-based sensors will operate?

Anticipating the future evolution of the Internet, in the 90s DARPA sponsored research into "active networks." This research assumed that Internet speeds were going to continue to rise and that not only servers and people but embedded systems and sensors would interact and cooperate in self-defined deterministic confederations of devices.

The goal was the creation of a network scheme that was fault tolerant and fault resilient enough to recover to its former state of operation quickly. One of the key technical discussions relative to this research was about rethinking the nature of the role of an OS, especially about what to include "inside", i.e. within the OS kernel, and what to put "outside," either locally or somewhere on the network that would be easily accessible.

Although the nature of the threat they were anticipating - nuclear war - is not now a clear and imminent danger, the way the Internet has become intertwined in our lives makes me believe it is necessary to rethink where to locate services - inside or outside - and do it in a way to ensure real-time and deterministic operation.

Question #4: In the era when there will be literally billions of Internet-connected embedded devices and sensors, are there features that can be integrated into the RTOS kernel that will make it easier to monitor, debug, replace or remotely upgrade the software resident there?

Many RTOSes have features that allow you to instrument the OS with services that allow it to be monitored, debugged and even updated remotely. And there are add-on software packages from a variety of software vendors that allow you to instrument the application code in a similar way.

The problem with such instrumentation solutions is that it makes the RTOS and the application fatter and slower, and also makes applications much more expensive to develop and deploy.

Telecom companies have solved this in their multi-switch and multi-router configurations by instrumenting only one board or subsystem for such operations. This is a nice work-around for many board-level embedded networking applications.

But in a world with literally millions of connected embedded MCUs and sensors deployed, is there a way to modify the RTOS structure so that it is less costly to add such kernel and application services?

Question #5: Will the role of a software-based RTOS diminish as the supplier of many of the services critical to the operation of an embedded system?

According to builders of network systems and custom network processors, a problem they repeatedly face is the vast difference in performance between the processors in the management plane and those in the data plane.

The needs of the first are adequately dealt with by using traditional RTOS solutions. But many of the critical operations supplied by an RTOS were too slow to match the performance of the blazingly fast NPUs in the data plane.

Their solution: either roll their own RTOS or use an open source OS such as Linux. This provides access to the code, allowing them to implement in hardware those OS services necessary to NPU operation and leave the rest in software form.

Similar problems face developers of many high-performance embedded consumer applications. In some multicore-based devices, developers are often forced to use two OSes: Linux or Windows for running application software and an RTOS to handle the underlying real-time services.

As a way of reducing the memory footprint some developers, rather than a full RTOS, implement just those functions they need in hardware to provide the necessary real-time background operations.

There are at least two companies offering hardware-implemented RTOSes. And most FPGA and PLD companies offer the embedded developer the option of incorporating most of an RTOS's functions in hardware.

In the era of Verilog, VHDL, System C and high-level virtual hardware platforms - where even the hardware is as malleable and configurable as the software - are the days of a software-based full-function RTOS numbered?

Question #6: Do all-of-a-piece commercial RTOSes have a future as technology drivers?

With a few exceptions, commercial RTOSes have not moved very far forward since the late 90s in terms of significant architectural enhancements. Is there really a role for commercial RTOSes as the source for the innovation that will be necessary to meet new challenges? Ditto for open source Linux.

Most of the innovation I see is coming from the roll-your-own segment of the market, even though Embedded Systems Design's most recent market reports show that only 19 percent of RTOS users roll their own and another 17 percent do not require the use of a full RTOS at all, just critical bits and pieces where they need them.

If the suppliers of the major commercial RTOSes are not to be the major technology innovators, maybe they can be innovators in the way they market their RTOSes. Why not make them much more modular - like Lego toys - guaranteeing not only that everything works together as a whole, but also guaranteeing the operation of each critical OS building block in isolation?

And how about providing mechanisms to those who incorporate some OS mechanisms into hardware that allow them to be sure the hardware and software components work together?

In my conversations with software vendors they confidently tell me that the 36 percent or so of embedded design developers which use neither commercial RTOSes nor Linux will continue to shrink. I doubt that.

If technical innovation and a constant stream of new ideas are valid measures of future success, I am going to keep my eye on that 36 percent. Remember the garage in Silicon Valley that started all this in the late 1960s?

The questions I have raised may not be the ones we need to drive the dialog forward beyond the present either/or comparisons. So, what is your opinion about some of the issues I have raised? More importantly, what are the important questions that you think need to be asked and debated?

Bernard Cole, in addition to being site editor of Embedded.com, is a partner in Techrite Associates, which provides editorial services to high tech companies. He is also managing editor of iApplianceWeb. He can be reached at bccole@acm.org or 602-288-7257.