The on-going and polarizing debate between true believers in
In technical discussions, such polarized views have no place becausein hardware and software engineering there are no absolutes. Everythingis situational, conditional and relative to the current application andsystem environment, as well as contingent upon the details of thecurrent design and the cost and performance tradeoffs involved.
Reducing what could be meaningful dialog to a simplistic debatedistracts us from careful consideration of a number of important issuesthat 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 ofan OS – schedulers, ISRs, mutexes, etc. – so that they reflect the newenvironment in which embedded systems operate, especially in relationto multicore?
Since I am a technical journalist and not a practicing engineer, Idon't have the depth of insight into RTOSes that most of you have. Butwith only a few exceptions, RTOSes don't seem to have changed much toaccommodate demands of the new environments, at least in terms of keyfeatures. Most changes appear to be “bells and whistles” bolt-ons tothe basic OS structure, not fundamental changes.
There are exceptions. For example, Express Logic has looked atmodifying the RTOSes used in multicore designs, creating an underlyingdimensionalized data structure in order to keep track of multiple dataarray objects associated with each core. Green Hills is makingsignificant inroads in building rock-solid and secure RTOSes.MontaVista continues to play a role in open source Linux OSes and WindRiver is involved in developing standards for multicore softwaredevelopment.
But there still remains a lot to be re-evaluated and redesigned, orthrown out all together.
Question#2: What is the best way to add virtualization to an embeddedsystem–as an external add-on, or as an integral feature of the RTOS?
Virtualization, especially in the embedded space, is being seen as away to simplify some of the serious programming and security problemsthat multicore designs with multiple OSes present. Some companies aresimply adding an additional virtualization service that operatesoutside the kernel.
Others, particularly those offering message-based microkernels, havefound a way to use the internal interprocess communications (IPC)protocol to implement virtualization. There is also work under waywithin the Multicore Association to develop an industry standardvirtualization mechanism.
Question#3: Do RTOSes need to be modified to reflect the ubiquitously connectedenvironment in which embedded devices and microcontroller-based sensorswill operate?
Anticipating the future evolution of the Internet, in the 90s DARPAsponsored research into “active networks.” This research assumed thatInternet speeds were going to continue to rise and that not onlyservers and people but embedded systems and sensors would interact andcooperate in self-defined deterministic confederations of devices.
The goal was the creation of a network scheme that was faulttolerant and fault resilient enough to recover to its former state ofoperation quickly. One of the key technical discussions relative tothis 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 networkthat would be easily accessible.
Although the nature of the threat they were anticipating – nuclearwar – is not now a clear and imminent danger, the way the Internet hasbecome intertwined in our lives makes me believe it is necessary torethink where to locate services – inside or outside – and do it in away to ensure real-time and deterministic operation.
Question#4: In the era when there will be literally billions ofInternet-connected embedded devices and sensors, are there featuresthat can be integrated into the RTOS kernel that will make it easier tomonitor, debug, replace or remotely upgrade the software resident there?
Many RTOSes have features that allow you to instrument the OS withservices that allow it to be monitored, debugged and even updatedremotely. And there are add-on software packages from a variety ofsoftware vendors that allow you to instrument the application code in asimilar way.
The problem with such instrumentation solutions is that it makes theRTOS and the application fatter and slower, and also makes applicationsmuch more expensive to develop and deploy.
Telecom companies have solved this in their multi-switch andmulti-router configurations by instrumenting only one board orsubsystem for such operations. This is a nice work-around for manyboard-level embedded networking applications.
But in a world with literally millions of connected embedded MCUsand sensors deployed, is there a way to modify the RTOS structure sothat 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 ofmany of the services critical to the operation of an embedded system?
According to builders of network systems and custom networkprocessors, a problem they repeatedly face is the vast difference inperformance between the processors in the management plane and those inthe data plane.
The needs of the first are adequately dealt with by usingtraditional RTOS solutions. But many of the critical operationssupplied by an RTOS were too slow to match the performance of theblazingly fast NPUs in the data plane.
Their solution: either roll their own RTOS or use an open source OSsuch as Linux. This provides access to the code, allowing them toimplement in hardware those OS services necessary to NPU operation andleave the rest in software form.
Similar problems face developers of many high-performance embeddedconsumer applications. In some multicore-based devices, developers areoften forced to use two OSes: Linux or Windows for running applicationsoftware and an RTOS to handle the underlying real-time services.
As a way of reducing the memory footprint some developers, ratherthan a full RTOS, implement just those functions they need in hardwareto provide the necessary real-time background operations.
There are at least two companies offering hardware-implementedRTOSes. And most FPGA and PLD companies offer the embedded developerthe option of incorporating most of an RTOS's functions in hardware.
In the era of Verilog, VHDL, System C and high-level virtualhardware platforms – where even the hardware is as malleable andconfigurable as the software – are the days of a software-basedfull-function RTOS numbered?
Question#6: Do all-of-a-piece commercial RTOSes have a future as technologydrivers?
With a few exceptions, commercial RTOSes have not moved very farforward since the late 90s in terms of significant architecturalenhancements. Is there really a role for commercial RTOSes as thesource for the innovation that will be necessary to meet newchallenges? Ditto for open source Linux.
Most of the innovation I see is coming from the roll-your-ownsegment of the market, even though Embedded Systems Design's mostrecent market reports show that only 19 percent of RTOS users rolltheir own and another 17 percent do not require the use of a full RTOSat all, just critical bits and pieces where they need them.
If the suppliers of the major commercial RTOSes are not to be themajor technology innovators, maybe they can be innovators in the waythey market their RTOSes. Why not make them much more modular – likeLego toys – guaranteeing not only that everything works together as awhole, but also guaranteeing the operation of each critical OS buildingblock in isolation?
And how about providing mechanisms to those who incorporate some OSmechanisms into hardware that allow them to be sure the hardware andsoftware components work together?
In my conversations with software vendors they confidently tell methat the 36 percent or so of embedded design developers which useneithercommercial RTOSes nor Linux will continue to shrink. I doubt that.
If technical innovation and a constant stream of new ideas are validmeasures of future success, I am going to keep my eye on that 36percent. Remember the garage in Silicon Valley that started all this inthe late 1960s?
The questions I have raised may not be the ones we need to drive thedialog forward beyond the present either/or comparisons. So, what isyour opinion about some of the issues I have raised? More importantly,what are the important questions that you think need to be asked anddebated?
Bernard Cole, in addition tobeing site editor of Embedded.com,is a partner in TechriteAssociates, which provides editorial services to high techcompanies. He is also managing editor of