Real-time capabilities of CE 3.0

Oliver Grubner and colleagues from Siemens provide an overview of work they have carried out to evaluate the real-time capabilities of the Microsoft Windows CE operating system

Embedded real-time applications are becoming increasingly important for a number of business segments. Various properties of this operating system, like its built-in multimedia capabilities, its optional GUI support, and the availability of the Microsoft Win32 application programming interface, make it a natural choice for Siemens in embedded applications.

Devices like telecommunications switching equipment, medical monitoring equipment, aircraft fly-by-wire controls, space navigation and guidance, laboratory experiment control, automobile engine control, and robotics systems must often manage time-critical responses.

A real-time system is a system in which the correctness of the computations not only depends on the logical correctness of the computation, but also on the time when the result is produced. If timing constraints of the system are not met, system failure is said to have occurred.

It is important for programmers to know - and always to keep in mind - that some of the 'ease of use' real-time programming functionality introduced in earlier versions of the Windows CE operating system has been removed in order to improve the real-time behaviour of Windows CE 3.0. One example is that only one level of priority inversion is supported.

Many Windows CE programmers are not aware of certain real-time related issues and are not careful in regard to real-time programming. Software architects need to check the programming restrictions of Windows CE 3.0 with respect to their real-time requirements.

Because an RTOS is part of a real-time system, it must provide the functionality to enable the overall real-time system to meet its requirements.

Requirements of standard real-time operating systems (RTOS) are:

• The OS (operating system) must be multi-threaded and pre-emptive
• The OS must support thread priority
• The OS must support predictable thread synchronisation mechanisms.

In addition, the OS behaviour must be predictable. This means real-time system developers must have detailed information about the system interrupt levels, system calls, and timing:

• The maximum time during which interrupts are masked by the OS and by device drivers must be known
• The maximum time that device drivers use to process an interrupt, and specific IRQ information relating to those device drivers, must be known
• The interrupt latency (the time from interrupt to task run) must be predictable and compatible with application requirements.

Interrupt processing

A major requirement for an RTOS is to process interrupts in a given range of time. As in most modern real-time operating systems, in Windows CE the processing of interrupts is divided in two steps, the Interrupt Service Routine (ISR) and the Interrupt Service Thread (IST).

The ISR performs minimal processing and returns an interrupt ID to the kernel. The kernel examines the returned interrupt ID and sets the associated event. The interrupt service thread is waiting for that event. When the kernel sets the event, the IST stops waiting and starts performing its additional interrupt processing. Most of the interrupt handling actually occurs within the IST.

In assessing the quality of the real-time behaviour of an operating system, clearly the interrupt latencies of the ISRs and the ISTs under worst-case workload are significant. Also, the behaviour of the scheduler, and in the case of Windows CE, the implemented reaction quality of the memory management unit (MMU) is an important characteristic. However, more important for a complete real-time system is the jitter of ISRs and especially of ISTs running on top of the underlying RTOS. Events with real-time requirements occur asynchronously, but most of the time periodically and predictably. In most real-time designs it is possible to derive characteristic system reaction times from these events. This allows for RT designs with latencies, which do not need to be so small. This is possible if the jitter, the variance of the interrupt latencies, is very small. Think of a band pass filter: the smaller the bandwidth, the better the quality of the filter. Similarly, the smaller the jitter, the better the quality of a real-time operating system.

In automation applications, events from an external technical process, such as the chemical transformation of a material, are usually sent to the controlling system (usually RTOS applications) on a periodic basis. Therefore, the notion of a working period is used to denote the time interval between the instant when an external process generates one of these periodic events (in the form of an interrupt) and the moment it expects a response to this event. The duration of one working period is determined by the requirements of the external technical process. It is valid for the processing of a low priority event to take longer than one working period if the processed result is not needed in the same period that the event occurred in.

High priority Sporadic events, such as alarm events, on the other hand, usually have a high priority and therefore have to be processed at once. Owing to this description we can conclude a general rule for priorities: periodic events determining the working period have a lower priority then sporadic events. INOC

Real-time programming hints The following is a summary of real-time programming do's and don'ts to reach real-time performance. To achieve real-time performance, do not: Spend inordinate amounts of time in ISRs Spin in highest priority thread - this will starve the system Use non-real-time APIs in real-time threads and expect real-time performance (for example SetTimer, file system calls, Process/Thread creation) Allow priority inversion to occur. By using a good system and program architecture, priority inversion is avoidable. But do: Pre-allocate all your resources (memory, threads, processes, mutexes, semaphores, events) Pre-allocate resources in system/application pools to use these resources during runtime without allocation and releasing Set up embedded program structure correctly, especially process communication Buffer data in ISR if passing it directly to IST isn't fast enough Use ISR for all the work if:     a) no system services are required, and     b) no extensive processing (long ISR time) required Set priorities and scheduling quanta correctly Use the function LoadDriver to avoid page faults or turn off the demand-pager Watch out for slow hardware or hardware that utilises the bus for extended periods - a CMOS real-time clock takes 70æs to access; display acceleration hardware steals bus cycles from CPU). These cases block ISR hits and delay ISR calls Watch for exception handling, which is very time consuming. All programming efforts are worthless, if: No structured development process is explicitly declared No test and verification strategy is developed and used during the whole project No real-time requirements and their verification are considered (logic testing is not enough).

• Siemens
  e101@industrialnetworking.co.uk
  
  
• Microsoft
  e102@industrialnetworking.co.uk