1. Do you think there are any risks associated with the "Cirrus", "Stratus" and "Cumulus" transitions?
Of course there are execution risks, but they are probably an order of magnitude less than the execution risks associated with continuing indefinitely with more platforms than needed.
The Holy Grail of operating systems is a single system that efficiently spans all applications and scales. Solving this problem is about as difficult and elusive as trying to account for gravity and the other three fundamental forces of nature in a single unified theory. We know WIND must provide and support a number of application-specific operating systems. Besides the standard OS, these include and OSEK OS for auto ECNs and an IO-centric OS in IxWorks. At issue is how many variations of the OS will be needed to span the gamut going from very high-end, multiprocessor systems to low-end, thin clients like connected sensor-managers. However many might be desired, it is critical that the number be kept to a bare bones minimum. The roadmap presented, while possibly a concern downstream for some pSOS+ users, meets the criteria I would impose.
A sign that smaller RTOS companies are pandering to pSOS+ customers through advertising, not only is not a concern to me, but it is a badge of honor. When competitors are reduced to living off the crumbs, you know you are the 800-pound gorilla. Just as Alcatel reportedly switched to VxWorks immediately upon hearing of the merger, I would expect all large customers to relish the roadmap. I doubt there is even one significant company that cares a hoot about any embedded OS. What they do care about is robustness, design stability, vertical add-ons, support, availability of experienced software engineers and certain checklist items. The roadmap appears to head in this direction.
2. What is the real significance of the enhancements like domain technology for memory protection, application isolation and high availability. Is WIND targeting new areas/devices with these enhancements?
First and foremost, these are necessary check-list items, whether or not they are actually always needed. For example, high availability is needed only where failure is unacceptable, like in a highly automated airplane (think of the Boeing 777 for example), or in telephony. Lucent and other traditional telephone equipment suppliers' claim that their five 9's availability (99.999% available) is a difference in kind that separates them from corporate enterprise suppliers like Cisco. Cisco can only counter by developing high-end equipment with operating systems that meet HA specs. If WIND intends to be a major player in the high-end telephony, aerospace and other markets, VxWorks must satisfy HA specifications. Once VxWorks is HA qualified, it becomes attractive to lots of other customers simply because the HA box gets checked.
Like HA, memory protection and application isolation are important checklist items. However, protection is mainly important in a general-purpose setting, where the application may vary and not be that well-behaved. For example, no one would argue that a telephone switch should suffer the possibility of a memory fault due to a lack of separation between the application code and the kernel. But the application may be essentially fixed and thoroughly checked out, arguing that the need for protection is NOT worth the penalty of slower execution caused by constantly checking for pointer violations. This same tradeoff favoring no protection applies to the lion's share of embedded systems.
As WIND encroaches on the consumer space, with its irrepressible attraction for varying applications, like the ideal QCOM phone, protection becomes more important, as might HA. However, don't jump to false conclusions about its requirement even in that space, as amply proved by Microsoft. The consumer is probably the only customer willing forever to forgive repetitive memory faults. Manufacturers facing the tradeoff of increased MIPS with its power requirements needed to provide protection in a consumer device may skip protection.
Since protection generally takes a huge byte out of the processor availability, WIND's patented approach may provide the best possible solution. The WIND OS team reportedly has developed an extremely benign method for separating applications from the kernel and each other, which minimizes the cost and alters the optimal tradeoff dictating when protection should be used.
3. Is it correct to say that IxWorks is outside and separate to the VxWorks/pSOS Cirrus, Stratus, Cumulus convergence?
No. I think IxWorks will remain IO-centric, specifically adept at implementing the I2O software standard for message-based, split-driver IO, but I believe it will feed off of the regular OS roadmap. We already know that the beta version of the latest IxWorks incorporates the full VxWorks API. I would expect that kind of compatibility to follow the evolution of VxWorks. It is even conceivable that all IO will gravitate toward the I2O standard, enabling a complete convergence of VxWorks and IxWorks far in the future. Perhaps when physicists have completed development of a Theory of Everything (TOE), WIND will have a unified theory of IO, including protection and HA, incorporated in a unified OS for Everything (OSFE).
Allen |
