Design Considerations for the Development of Real-Time Windows Systems

With the Microsoft Windows operating systems capturing the PC desktop market, a large majority of developers (and users) are demanding consistency and portability of their development tools, utilities and applications between the embedded and desktop spaces. This promotes a higher degree of productivity by leveraging a well-accepted suite of development software, a vast knowledge base of Windows OS technologies, a large selection of COTS software applications, and the extensive experience and breadth of Windows developers. The term “Windows form-factor” is regularly appearing in many design specifications.

Driven by customer and market pressure, designs now need to take advantage of COTS products to reduce the time-to-market and total cost of ownership. Using proper design principles is mandatory, and the benefits of the Microsoft Framework technologies offer unparalleled productivity. Despite these advantages, there is still a critical issue that is left unresolved by the Windows form-factor—real-time performance.

The Need for Real-Time Windows

While Windows provides a rich graphical environment for a sophisticated industrial automation programmable logic controller (PLC), it does not ensure that the control application developed for the PLC will have the ability to run at the necessary priority in the Windows environment.

Windows has 32 levels of priority, of which 7 levels are accessible by Win32 API macros. The device in the Windows system with the highest priority is the mouse. So, imagine that a PLC is running a critical control application and the mouse is moved. Windows will immediately stop processing the control application to service the mouse interrupt.

Of course, this model also applies to other Windows internal functions, such as flushing memory caches, etc. In applications with critical, time-sensitive requirements, this is unacceptable behavior. To address this situation, third-party real-time extensions have been developed to provide the necessary control, determinism and survivability to ensure that system performance goals are met.

In designing a Windows-based system to ensure that control, determinism and survivability goals are attained and control of system resources is absolute, the designer should consider the capabilities when selecting Windows real-time extensions. At a minimum, developers should not have to compromise on any of these requirements to meet their system goals.

The extensions should offer predictability—where events happen when they are scheduled—and performance that offers the ability to support consistent interrupt rates of 30 KHz without degradation of either Windows or real-time performance. In addition, the real-time application must be safe from crashing; it must have “blue screen of death” survivability. Shut down protection and early boot capabilities must be available.

One major reason to develop for Windows in the first place is the ability to leverage the tool environment. Comprehensive, Microsoft-compatible development tools should be usable for the real-time aspects as well, as should a standardized design approach for device drivers. In addition, there should be support for real-time dynamic linked libraries and WIN32-compatible SDK APIs.

Developers need the availability of unlimited threads with priority inversion avoidance and promotion. They require comprehensive HAL support with no modification to the supported HALs, and they need direct Port I/O and physical memory access. Shared memory utilization should be flexible with support for high-speed data transfers, and there should be real-time TCP and USB support.

Design Flexibility

The third-party extensions must have sufficient power and flexibility to allow developers the ability to design, develop and validate the system to attain maximum efficiency. For instance, multi-threaded applications can very easily cause memory corruption when multiple tasks access the same memory at the same time. Therefore, it is critical to have the ability to develop in the protected memory space of Ring 3, for memory validation, in order to ensure that arrays and pointers within stacks are valid.

However, once memory-related processes are tested and validated, why should the real-time application be forced to compromise on performance penalties associated with Ring 3? This space is usually reserved for applications such as virus protection or office productivity suites, where neither performance nor application survivability is required. Therefore, there are two different perspectives of third-party architectures:

In a Ring 3 architecture, the application is developed and deployed in Ring 3 (Figure 1). As mentioned above, this is the correct approach for “Windows applications,” but is not optimal to meet the performance demands of current products. The real-time developer, however, needs the ability to develop real-time Windows applications in Ring 3 and, having fully tested and validated them, to simply recompile them for Ring 0 to attain immediate performance (Figure 2).

In the end, the designers of the products must decide whether memory protection and its associated performance penalties can achieve their design goals, or if they need a higher-performing, more flexible approach to validating proper memory management by using Ring 3 during the development and immediately recompiling into Ring 0 for deployment.

Microsoft Operating System Considerations

The Windows form-factor offers both the end-user and developer many advantages. End-users, for example, are very comfortable with the Windows desktop environment and set of applications and tools available to them. Software developers can likewise take advantage of widely available and accepted sets of development and debugging tools to reduce development time. Optimized libraries for performance, COTS drivers and utilities and a platform framework are just a few.

Although many of these tools are essential for large system and desktop development in Windows, the usefulness in the embedded system environment can be questioned. Technologies such as Common Language Runtime (CLR) environment, .NET Framework and Microsoft Foundation Class (MFC) interfere with many real-time aspects. For example, the goal of the CLR was to provide simpler, faster development and scalability along with automatic handling of system services such as memory management and inter-process communication.

The CLR accomplishes this by providing a rich set of underlying services and functionality to the developer. Applications access these services and functionalities in a standard and consistent manner. Much of the typical program framework, such as garbage collection, memory management or object creation, is handled automatically by the CLR—but at what cost to the embedded performance requirements?

“Total ownership of system control” is paramount in the set of deterministic requirements for embedded systems. The designer must be on guard to ensure that control and priority of execution is never unintentionally passed to the Windows operating system.

The Microsoft operating systems available to the embedded programmer offer a rich and comprehensive set of features. Windows 2000 Pro for Embedded Licensing, Windows NT 4.0 Embedded and Windows XP Embedded provide a wide range of choices to fit all design criteria. Windows CE .NET extends the selection by offering a small-footprint, feature-rich embedded operating system. It is not, however, a real-time operating system.

CE .NET is focused on a marketplace that may not provide the robustness and flexibility needed by many products. It is less compatible with the Windows APIs of the other operating systems and it requires its own set of development tools. The availability of COTS hardware, drivers and applications may not satisfy your target’s configuration, and the development cycle may not fit the “time-to-market” constraints.

Design Tradeoffs

Several factors must be assessed when designing a system to provide the best possible fit for the overall performance and market objectives of the product. These factors would include aspects such as development tools, determinism requirements and scalability. Also to consider are the performance and throughput demands as well as the response time requirements. Should they be < 5μS or <10 μS or <50μS?

Today, real-time developers do not need to compromise on performance or functionality! There is a selection of products to choose from. It is important to understand how the solutions affect your design from the point of view of the technology implementation and the development effort.

That said, it is sometimes necessary to make design tradeoffs when finding the best product for your embedded solution. There may be features that appear attractive at first glance, but upon further study they may require you to make a design tradeoff. However, remember: When poor performance is built into the design, no additional features will make up for it.

Consider, for example, memory protection verses determinism. Any application that runs in the user space (also referred to as Ring 3) will be afforded a memory protection capability, which is inherently part of the Intel architecture. This is a wonderful asset to all Win32 application developers. They can know that the system will layer and protect their software, even with the most poorly designed and improperly tested application-level code.

The down side is that any application that runs in the user space will suffer the latencies that are inherently part of this architecture. In addition, the expected capabilities that are considered as a standard feature in most Windows extension software, such as direct I/O port access and direct physical memory access, will be denied to the developer.

This will not have a noticeable impact upon typical user space software, such as office automation processes, user interface tasks or any other applications that have no real-time requirement. They depend upon the lower-level Windows services to perform many of those actions. However, it will present a serious setback to the real-time developer trying to deal with tight time constraints and narrow data acquisition windows. In addition, this architecture will still suffer from all the same issues if any poorly written, improperly tested, kernel space driver goes awry on the system. Look at the architecture and understand it before beginning.

In many cases, the use of a third-party real-time extension technology for Windows can provide the control required for applications with time constraints and task priorities. A designer will need to examine all third-party choices carefully before making a final decision. Software engineers strive to develop clean code with as few bugs as possible.

By developing in the Windows application space, known as Ring 3, developers can benefit from, and take advantage of, several features of the Windows environment, such as memory protection and comprehensive debugging tools. If the application was developed in accordance with sound coding practices, and all memory-related bugs have been resolved, the benefits of memory protection leveraged by running in Ring 3 in the development stage are no longer required for deployment.

Waltham, MA.
(781) 647-3000.