RTC Group, Inc.

Windows CE .NET Combines Real-Time Control, HMI and Networking

By: Ronald Dicklin, Bsquare

Microsoft Windows CE .NET is not only an appropriate solution for hard, real-time requirements in specific situations, but also provides the framework for a rich graphical user interface and advanced network support.

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.

Windows CE .NET additionally has the built-in ability to display the actual tank level on the HMI by using browser-based technologies such as HTML, ActiveX and scripting. A predetermined low-level set point can be entered through the HMI, and depending upon the actual tank level, a warning alarm will be displayed on the HMI panel should this level drop below the set point. This information can also be sent via an XML packet across a local area network to a data management system to alert appropriate personnel of a low chlorine tank alarm. This underlying tank level measurement task must be scheduled in a timely manner with no worries that the operating system might be busy saving files or flushing registers, thus possibly missing a low tank level warning. It will, however, be at a lower priority than the valve operation. We will assume that the required scheduling period for the level measurement operation is time r.

Develop the Solution

Now that the process has been defined, and all real time components identified, we need to develop a solution to address these time-sensitive operations. We will first focus on how to implement an interrupt that will feed more chlorine into the system when required. This implementation consists of two steps: initializing a Windows CE .NET interrupt service thread (IST) and then writing a routine to service that interrupt.

Key steps to initialize the interrupt in our Windows CE .NET software are to:

Thus, when the residual chlorine falls below a predetermined level, the system hardware will generate an exception causing the Windows CE .NET ISR vector to be loaded into the HMI’s x86 processor. The kernel ISR interacts with the hardware and disables all equal and lower priority interrupts. The kernel then vectors to the OEM Adaptation Layer (OAL) or OAL ISR that has been registered for that particular interrupt and returns the mapped interrupt called SYSINTR. An OAL is a layer of code that logically resides between the Windows CE .NET kernel and the device hardware.

Upon completion of the ISR, the kernel re-enables all interrupts on the processor except for the identified interrupt. The kernel then signals the event that has been associated with the SYSINTR value.

The interrupt service thread operation then runs, assuming that it is the highest priority thread that is ready to run. The IST sets the appropriate “open valve process” in action. The IST then signals its completion with a call to InterruptDone( ) with the associated SYSINTR value. The kernel, upon receiving the InterruptDone for the SYSINTR value, then re-enables the designated interrupt. This is the first point at which another interrupt for this “open valve” requirement can be received.

During development, it is recommended to start out leaving all the work in the IST. If testing indicates results in an acceptable value of t then development is finished. If the value of t is too large, i.e., there is time left over in t, then more processing can be moved into the ISR.

In addition to having the ability to call the appropriate valve action in real time, this same interrupt from the chlorine analyzer could also indicate on the HMI screen that the process is opening the valve and feeding more chlorine into the system. The design could also incorporate the actual analog residual level into the HMI panel for monitoring and recording purposes, both locally and via the supported network

Next, we need to ensure that the application that monitors the tank level is scheduled to run on a determined basis. As a preemptive multitasking operating system, Windows CE .NET bases preemption solely on the priority of the thread; that is, it schedules threads with a higher priority to run first. Threads at the same priority level run in a round-robin fashion with each thread receiving a slice of execution time.

At this point, you can use CeSetThreadPrioity to increase the priority of a thread. You can also use CeSetThreadQuantum to adjust the length of time available for the tank level monitoring thread.

As a side note, in some corner case, you may want to consider modifying the default quantum value for all threads. This should be set during the OEMinit phase of OAL initialization and must be greater than zero. Otherwise, it is ignored. Setting this value too low or too high can have dramatic effects on OS performance. When the system starts, dwDefaultThreadQuantum is set to a default value of 100 milliseconds.

Testing the System

With the solution now defined and developed, the next stage in Bsquare’s Four Point Methodology is to test the design. Windows CE offers two tools to help you measure the real-time performance of the kernel: interrupt latency timing analysis (ILTiming.exe) and operation system benchmark analysis (OSBench.exe).

ILTiming.exe determines the ISR and IST latencies. To determine the latencies, ILTiming.exe directs the time (system tick interrupt) to return SYSINTR_TIMING at specified tick intervals. ILTiming.exe waits on the SYSINTR_TIMING interrupt event, thus becoming the IST. ILTiming.exe gets the current time each time it receives the SYSTINT_TIMING message.

To gauge the response time between when the system receives a GPIO interrupt indicating low chlorine residual and when the control valve is modulated, ILTiming.exe could be implemented to estimate t.

We could also use the OSBench.exe tool to collect timing samples to conduct performance-timing tests on the scheduler. We could measure the rough scheduling frequency of the thread that monitors the tank level to ensure it is less than or equal to r.

Support the Solution

Windows CE .NET can be used to support the HMI functions and real-time process control. In addition, with its built-in networking provisions, this architecture provides the ability to remotely manage the system. Process changes and system support, which normally require local interaction with the HMI panel, can be now done over the Ethernet. Items such as set point changes, process tuning, application modification and even full OS updates are possible if designed into the system.

In many situations, developers will need to use eMbedded Visual C++ to write native code for Windows CE in order to achieve the deterministic behavior required. For the HMI functions that do not require true real-time performance, this can be supported through managed code and the Windows.NET framework.

Bellevue, WA.
(888) 820-4500.

© 2009 RTC Group, Inc., 905 Calle Amanecer, Suite 250, San Clemente, CA 92673