Great questions, each of which I will try to answer in turn, and invite others to add their two cents also.
< (1) The embedded microprocessor market is growing rapidly. But how many of these embedded systems are complicated enough that they actually need a RTOS?
The projections I posted were only for a portion of the microprocessor market - the 32-bit market, which is small but is expected to grow rapidly. The 4-bit market no doubt does not use an OS. The 8-bit embedded market probably does some or even most of the time, but the OS would be crude, offering few services, and as far as I know strictly home-grown. The 16-bit embedded market can be nearly as demanding as the 32-bit market, and require a full-scale RTOS. An example here is the 16-bit family of Siemens processors that are a favorite of the automobile community. A slimmed-down version of VxWorks was ported to the 16-bit Siemens chip for GM, with special services built around the need to sync with revolutions, not just time. Subsequently, Siemens has contracted with WIND to port the full-scale VxWorks to their 16-bit line of processors. Remember, the 8086 and the 80286 Intel microprocessors used complicated OS’s, although they were only 16-bits. Remember also, that until recently, the 80386 and 80486 32-bit processors were made to act like 16-bit processor under MSDOS.
But with rare exception, by the time an application needs a 32-bit processor, it will virtually always require the services of a separate, operating system layer. To do otherwise simply would be too complicated. This is why only 32-bit processor growth was projected in my prior post.
A related question is how many 16- and 32-bit embedded applications will use so-called roll-your-own operating systems? I have the sense that most sizable commercial RTOS vendors are porting only to 32-bit microprocessors (with the Siemens exception). That’s probably because of their Unix, VME-bus and real-time systems background, i.e., historical reasons. There is no fundamental reason why commercial RTOS begin only at the 32-bit processor point. Nevertheless, for projection purposes, I assume all microprocessors less than 32-bits use only roll-your-own’s or nothing. I assume that only 30% of 1994 32-bit applications were deployed on commercial OS’s. Based on info I read somewhere about this ratio, I conservatively assume only 50% are commercial by 1997, with 65% commercial by the turn of the century.
If the intent of your question is to ask how many applications require "real-time" vs. just needing an OS, then I’m not sure. It seems to me that once you decide to go commercial, you get real-time for free. Why take less, since all the contenders offer it and you may want real-time in future. No doubt "fast" is good enough for many applications, but in multi-media, telecommunications, data communications, I2O, etc. hard (i.e. guaranteed) real-time is necessary as well. I also suspect that functional design requirements elevate to the functionality available (sort of a Murfy’s Law), so probably most 32-bit designs specify real-time.
Why is the commercial portion of embedded OS expected to increase? Because of complexity, desired flexibility and time-to-market. All analysts seem to agree that organizations will recognize more and more that they are in the application business, not the operating system business. GM really scratched their heads before they could consider not owning a vital part of their fuel injector control system. They concluded that their application algorithms contained their intellectual property, not the operating system controlling the applications. Notice that Intel out-sourced the OS for the I2O chip, i960 RP, rather than using their own in-house RTOS. Notice HP using VxWorks in all matter of products, and pSOS in their set-top box, rather than use their own in-house RTOS. If these companies choose to out-source RTOS for their products, how long will a company that makes a telecommunications switch continue to invest in an in-house OS?
Hope this helps. Maybe others help elaborate helpfully about roll-your-owns.
Allen, |
