<typically employed in, e.g.,fuel injection systems constantly monitoring gas/oxygen ratios, heat, etc., then reporting the data to a digital system>
JMD You've hit a good point, in that the real value of an RTOS is not so well defined. What you've described above is in the application domain. Even today, most Automotive companies will accomplish the above without using an RTOS. In other words, they will write a simple scheduler and will run gas/oxygen routines on this scheduler.
What you're asking me, in essence, is "what is the true value of an RTOS?", and this is a tough one to answer because today's RTOS are so many things to so many people.
An automotive company may use an RTOS because of it's determinism and the tools which allow their developpers to make sure that the aplication is written as tightly and safely as possible.
A set top box compnay may use an RTOS more because it has good tools and has the verticallly integrated layers (GUI, Browser).
Defense contractors, Aerospace firms, and NASA may want source-code and reliability.
Internet Appliance companies may want time-to-market and small code size as key capabilities.
Telecomm vendors may want Protocol stacks and robust networking choices, and compliance to standards.
Office Automation companies may want small code size and support for multiple CPU architectures.
The point is, the pressure is on, on all fronts from the users to RTOS vendors. Some of the RTOS vendors have picked their niche, and will succeed/dissapear depending on the future of their particular niche.
The beauty of WindRiver, in my opinion, is that they haven't had to succumb to being a "niche player" making a relatively easy sell in a non-competitive market. Rather they've competed with niche players on all fronts and come out stronger player with every new design win.
And with the deliniation between many different embedded applications blurring, this is an envious position to be in....
Cheers!
|
