Microsoft officially entered the embedded marketplace with Windows CE 1.0, which was built from scratch to extend the Windows environment into the embedded world. While subsequent versions of this operating system improved, it was not until Windows CE 3.0 that CE was truly accepted by the industry. After all, CE 3.0 was the first release that could be considered real time, often a requirement in embedded systems applications.
At the same time, Microsoft was convinced that there were many developers building a range of nonPC applications that are not resource constrained, and that could benefit from an enhanced set of features and more functionality than Windows CE provides (or provided in its early days). Consequently, Microsoft decided to "componentize" its Windows NT OS and call it "Windows NT Embedded." In the meantime, Windows XP Embedded was also released. Bear in mind that both of these products are targeted towards embedded systems without real-time requirements, because neither Windows NT (embedded) nor Windows XP can be considered an RTOS. Together with the Server Appliance Kit, which is designed to build dedicated servers based on Windows 2000, these tools comprise the Windows embedded family.
When it is all said and done, Microsoft appears to have established a foothold in the embedded OS market. In fact, according to market research firm Venture Development Corp. (http:/www.vdc.com/), Microsoft nearly doubled its market share in 2001 to 18.7 percent of the market.
Measuring Real-Time Performance
In general, our examination of RTOSs aims to assess the real-time performance and robustness of a system such as CE .NET. While the nomenclature "embedded versus real time" appears to be confusing to many engineers, it is crucial to understand that embedded systems are not necessarily real-time systems, and vice versa. Real time refers to the performance characteristics of the system, and is all about predictability. A real-time system is expected to respond in a predictable way to external events; for instance, within a predefined maximum time limit. While quite many embedded applications require different degrees of real-time behavior (printer, fly-by-wire system, and so on), others do not.
We submitted Windows CE .NET to our standard test suite, and performed all tests on the same 200-MHz Pentium-based platform. This high degree of consistency lets us make product comparisons that make sense. Here, I compare Windows CE .NET results with some of its competitors. For detailed information on all the tests performed during an evaluation, see the document "Report Definition and Test Plan" (http://www.dedicated-systems.com/), which describes how our measuring method (making use of external devices such as PCI bus stimulators and analyzers) lets us get accurate and reliable results.
I'll start with some basic test results, and see how Windows CE .NET responds to external events or interrupts. I'll then compare the test results with those of some competitors. From Figure 1, you can see that we measured a maximum interrupt latency of 5.6
s for Windows CE .NET.
Obviously, real-time system designers are interested in the worst-case latency. But when you run simple tests like that in Figure 1, how can you be sure that the maximum latency you measured is truly the worst-case latency? You can't. That's why we created a stress test that exposes the system to 1 billion periodical interrupts, while we measure how many of those interrupts were serviced and how many of them were lost. We consider the test successful only if every single interrupt was serviced. What does "losing an interrupt" mean in this context? Well, imagine we generate the same interrupt every 20s. If for some reason the RTOS on one instance takes longer than those 20s to service this interrupt, our PCI exerciser would try to generate the next interrupt while the previous one would still be active. So that interrupt would effectively be "lost." That is what makes this test so interesting—if the test succeeds, then we can be sure that every single interrupt was serviced within said 20s. If you execute this test with enough periodical interrupts being generated (1 billion, for example), you get a more reliable result with regards to the system's worst-case interrupt latency. As you can see from Table 1, the results for Windows CE .NET are very good. The test already succeeded at 11s. QNX RTOS 6.1 is the only commercial RTOS we tested that managed to (barely) top this performance, with 10s as the worst-case interrupt latency. VxWorks AE 1.1, on the other hand, required 25s to complete the test successfully! This gives you an idea of how Windows CE .NET compares to its closest competitors.
We executed various other tests during our evaluation, from which the thread switch latency is one of the most fundamental ones. Real-time applications are usually multithreaded, and as such the RTOS should be capable of managing and switching from one thread to the other swiftly.
Figure 2 shows the results of a test with 10 threads of equal priority, each of which yields the processor as soon as they become active. You may have noticed that the Windows CE's maximum latency is higher than those of competitors. Just like the previous version (Windows CE 3.0), the .NET version does not create all the necessary resources when the CreateThread call is issued. The consequence is that the system needs to perform some additional work when the thread becomes active for the very first time. While this is not a big problem, Microsoft told us that they will correct this in the next version, nevertheless.
Conclusion
This evaluation suggests that Microsoft has been successful in producing an operating system with genuine real-time capabilities (don't forget to include aforementioned QFE in the system). The more than sufficient technical qualities further suggest that Windows CE .NET will indeed find its way into a variety of dedicated systems.
DDJ