Next-generation, real-time devices used in factory automation applications typically place two types of requirements on the device operating system: the traditional requirement for real-time response capabilities and new requirements for advanced OS features such as a rich graphical user interface and extended network support. To efficiently meet these needs, there are a number of companies now marketing a new generation of touch-screen operator terminals that offer a universal graphic solution as well as a complex network system, all with the ability of real-time performance control built into one device.

The software backbone, which supports some of these devices, is Microsoft’s Windows CE .NET. Windows CE is well known for its strong graphical user interface capabilities and its networking features. Less well known, is that with insight into the workings of the OS, Microsoft’s development tools and the selected CPU architecture, engineers can design their own robust real-time devices, as demonstrated with the new generation of CE-driven human-machine interfaces (HMIs).

To demonstrate this ability, we will use a hypothetical x86-based HMI/ Control Panel that’s used for an automatic chlorine feed system, and follow Bsquare’s Four Point Methodology of Scope, Develop, Test and Support to help define and engineer the solution.

Scope the Real-Time Requirements

The first step in defining the solution, is to scope out the particular process at hand, and define the areas that require real-time performance. The real-time response of the CE .NET-based HMI panel is conceptually scoped in two different ways. First, for time-sensitive activities, we need to define the operations that require a deterministic response time between a given interrupt to the system and the system’s reaction to this interrupt. For a deterministic result, the interrupt response time must be less than a defined upper bound. Secondly, we must ensure that this does not interfere with other time-critical operations.

To first illustrate this upper bound concept for Windows CE .NET, we will choose an interrupt on our HMI panel and describe its implementation. Let’s assume that our HMI panel supports a discrete input from an analyzer that monitors the amount of residual chlorine in our hypothetical feed system. If the measured residual chlorine on the process output drops below a predetermined level set within the analyzer, then a signal alerts the HMI/Control panel to take action and supply more liquid chlorine to the system through a modulating control valve (Figure 1).

This part of the process is extremely time-sensitive. If the response time to feed additional chlorine to the system is too long, the residual level on the process output may continue to fall below an acceptable level and cause the process response to fail. We will assume that the time between when the operating system receives an interrupt that the residual chlorine is low, and the operating system modulates the control valve towards open, must be less than a time we will call t.

Our second consideration must be to ensure that the operating system threads’ underlying critical applications are on a deterministic schedule as well. The Windows CE .NET scheduler maintains a priority list of each process and thread within the OS. Each process can contain multiple threads, and each of these threads composes a path of execution. The scheduling system controls the order in which these different paths are sequenced and allows them to interact with each other predictably. An application developer can create a miniature custom scheduling system internally within a thread through the use of “fibers” in that thread. Fibers are units of execution that are scheduled by the application.

To illustrate this concept, given the same hypothetical chlorine feed process, we will use the example of a second operation that measures the chorine feed tank level. This particular application is not as time-sensitive as the feed application, but needs to be monitored on a deterministic schedule nonetheless. To illustrate this concept for Windows CE .NET, we will assume that our HMI panel is connected to a level sensor through a second GPIO interface.