Real-Time Operating Systems: INtime Architecture

  • Article

 

TenAsys Corporation

September 2003

Applies to:
    Microsoft® Windows® XP
    Microsoft Windows XP Embedded
    Microsoft Windows XP Embedded with Service Pack 1

Contents

Abstract
Introduction
INtime: An Overview
Reliability Features
Scalability Features
Conclusion

Abstract

The Microsoft® Windows® XP and Windows XP Embedded operating systems are increasingly being selected for dedicated applications where some deterministic behavior is required. Windows XP Embedded, based on the same binaries as the Windows XP desktop software, is the best choice of platform in many respects, but Windows XP Embedded and Windows XP alone cannot manage the strict determinism required of such systems and it is necessary to enhance the platform with real-time capabilities. The case for adding real-time extensions to the Windows XP platform has been made many times. Many solutions exist which provide some real-time capability at the Windows XP kernel device driver level, but this class of solution does not allow for a robust applications environment sufficient for ease of applications development and to allow for scaling across a wide spectrum of applications classes. This paper examines how TenAsys Corporation's INtime software not only adds deterministic behavior for applications but also allows those real-time applications to exist in an environment which is robust, reliable, and scalable.

Introduction

As widely discussed, the Windows operating system does not display hard real-time characteristics. It is possible to add such characteristics to the platform, but it is important to remember that it is very often not just device drivers that require these features. However, layers of application software may also need to take advantage of the deterministic environment. In order to support such complex applications, it is desirable to provide them with an environment which is robust and resilient. Gross errors in one application should not bring down the entire system, or even affect other applications except where they explicitly interact. In fact, it should be possible to detect and handle such errors where possible and at least provide some information about how they were able to occur.

The approach taken by TenAsys INtime software is to load a real-time operating system alongside the Windows operating system, so that they share the same CPU and interrupt hardware but are otherwise independent. Each is encapsulated as a virtual machine each with its own descriptor tables, memory management and so on. When real-time activities have to take place, the machine context is switched to the real-time operating system. When those activities are complete, then the context is switched back to the Windows operating system.

Because the real-time operating system is independent of the Windows operating system software, it is possible to enhance the environment in which real-time processes run and to add additional features to add to the robustness of the whole platform.

INtime: An Overview

A typical application for this platform will be partitioned into sections which do not require real-time services, but exploit the wealth of the Windows XP platform, and sections which require the real-time performance of the real-time kernel. Interprocess communication (IPC) services are extended from the real-time kernel so that a Windows application is able to share access to objects created on the real-time kernel.

A simple example might be a data acquisition application, where a real-time process is responsible for driving the hardware interface and processing the data received, while a Windows process provides an operator interface and displays the results.

Both processes may be developed with the Microsoft Visual Studio® tools, with C and C++ being supported by the real-time environment.

INtime System Architecture

INtime is implemented as a real-time operating system which shares the hardware platform with the Windows operating system. Components installed on Windows include a Windows kernel driver and a number of Windows services. The driver manages memory for the kernel and real-time applications to run in, and manages the communications interface between the two systems.

A Windows service loads the real-time kernel into the allocated memory and then causes a context switch from Windows to the INtime kernel. A low-priority thread is created whose function is to switch the machine context back to the Windows system. Because this thread will be preempted by all other real-time threads, as far as the real-time kernel is concerned, the Windows system is the real-time system's idle task.

When in the INtime context, any real-time interrupts are handled directly, and all other interrupts are masked at the interrupt controller. When the context returns to Windows, these interrupts are unmasked to allow normal processing by Windows. When a real-time interrupt occurs in the Windows context, the Windows IDT is patched so as to cause a context switch to the INtime context so the interrupts may be handled.

The system timer is usually shared between Windows and INtime. The hardware timer is reprogrammed to interrupt at a higher rate than Windows requires, and the Windows handler is only invoked as required. Typically, the INtime kernel takes timer interrupts at a much higher rate (a period as low as 100µs is possible) to allow for finer granularity timing services. Optimization of the timer handling avoids unnecessary context switches between Windows and INtime.

Certain hardware abstraction layer (HAL) entry points are intercepted and monitored in order to prevent the Windows kernel from performing unwanted actions such as masking a real-time interrupt, or changing the hardware system timer frequency. The HAL file is not modified or replaced by the software.

The INtime kernel provides operating system services for the real-time virtual machine. It provides the real-time services expected of such a kernel, consisting of a priority-based preemptive scheduler with priority-based interrupt handling. Thread priorities range from 0 (highest priority) to 255 (lowest priority) and threads below a configurable priority threshold can time-slice with threads of equal priority. The kernel scheduler has been optimized for maximum interrupt performance.

The resulting platform exhibits good performance, and above all its behavior is predictable.

The Application Environment

The INtime applications environment was designed with the following features:

  1. Each process is a container for other objects, including threads and physical memory. Each object created by a thread belonging to that process is owned by that process and ceases to exist when the process is terminated.
  2. Each process has a flat, virtual address space which is isolated from other processes' address space. The code in a process is executed in user mode (IA privilege level 3), so that accidental access to system objects and data is prevented.
  3. Each process has direct access to the processor's input/output (I/O) space, and it is possible to gain direct access to physical memory.
  4. Interrupts may be handled directly in any process, by means of system calls and user-written code for the interrupt handler and thread.
  5. Faults are handled on a per-process basis. The faulting thread is suspended by default, and a record is written to a global mailbox. The default action may be changed so that either the static system debugger or the application debugger can be entered at the faulting address. Processes may also choose to be notified of faults in that process.
  6. Multiple APIs are provided to make system services available to processes. These are described in detail in the following sections.
  7. Windows services (access to the registry, event log, and file system) are provided to real-time applications by forwarding the requests to a Windows service to perform the requested action.

Real-Time API

The standard API provided by the INtime kernel provides objects suitable for synchronization and communication, along with the means to share memory between processes, including between INtime and Windows processes. All objects are referenced by a handle, and all handles are global to the real-time system. Objects include:

  • Processes
    Processes own other objects (including other processes) and physical memory. A memory pool is assigned to the process on creation, which limits the amount of physical memory it is possible to assign to the process. Although the INtime kernel uses the paging hardware for memory management, it does not employ demand paging. Therefore, the process is limited to the amount of physical memory it can allocate.
    Processes also have an object catalog where objects may be named. Catalogs may be searched by name.
  • Threads
    Threads are always owned by a process and objects created by a thread are owned by its process. A thread has a priority assigned to it in the range 0 to 254, where 0 is the highest priority.
  • Semaphores
    These synchronization objects consist of a thread queue and a counter, and are analogous to Microsoft Win32® semaphores. On object creation, all INtime thread queues can be designated as first in, first out (FIFO) or Priority. In the FIFO case, threads are queued in the order of waiting; in the Priority case, threads are queued so that higher priority threads appear at the head of the queue.
  • Regions
    These objects are single unit semaphores with protection against priority inversion. They employ the standard priority elevation technique to avoid this condition. In addition, a thread which holds a region cannot be deleted until it gives up the region. They are analogous to Win32-critical sections.
  • Mailboxes
    These objects consist of a thread queue and a message queue. There are two types of messages that a mailbox can queue. Messages can either be handles of other objects, or data messages contain up to 128 bytes. There is no direct equivalent in Win32.
  • Heaps
    A heap object is analogous to a Windows heap. It provides a dynamic memory source for applications.
  • Other memory objects
    A handle may be created for a memory area, and then passed to another process for mapping. This memory may then be accessed from both processes.

The real-time API provides parameter checking and in-line status reporting.

Win32 API

Although the Win32 API lacks some useful features for real-time programming, INtime provides a Win32 API for ease of transporting code from Windows applications. This implementation is a rich subset of the Windows CE Win32 implementation, including a useful subset of Win32 objects, WaitForMultipleObjects, and with extensions to manage interrupts and Peripheral Component Interconnect (PCI) bus configuration.

Windows APIs

APIs are provided for Windows applications to allow them to share objects created on the real-time kernel. Both standard real-time objects and Win32 objects are shareable so that Windows and real-time applications may synchronize and share data. Blocking calls are handled by a pool of proxy threads on the real-time kernel.

C Library and C++ Support

INtime provides an American National Standard Institute (ANSI-compatible) C library, and support for the EC++ (Embedded C++) ANSI standard, with the Standard Template Library (STL).

Other Services

A Transmission Control Protocol/Internet Protocol (TCP/IP) stack is provided which is derived from the BSD Net3 architecture. Ethernet drivers are provided for Intel, 3Com, and Realtek interface adapters, as well as for NE2000-compatible ISA interfaces. Serial links are supported through Serial Line Internet Protocol (SLIP).

USB support is provided as a development kit for developing USB client software. Standard drivers are provided for Universal Host Controller (UHCI), Open Host Controller (OHCI), and Enhanced Host Controller (EHCI) interfaces.

Other drivers are provided for a range of standard and industrial interfaces.

Reliability Features

INtime features that enhance reliability include exception handling for non-catastrophic system faults, and the Distributed System Manager (DSM) which can can monitor both INtime and Windows process, and detect and assist when the Windows operating system fails.

Exception Handling

One of the primary concerns with the design of the INtime kernel was to provide a non-catastrophic means of handling system exception faults (general protection fault, page fault, stack fault, and so on) and cause as little harm as possible to the real-time kernel and to the Windows system. Accordingly the real-time system has a default exception handler which writes a record to a global mailbox detailing the faulting thread and its circumstances, and then suspends the faulting thread. The mailbox may be monitored from the INtime or the Windows systems, and there are tools for extracting information from the fault record, including register dump, stack tracing, and relevant debug information.

Distributed System Manager

The Distributed System Manager ("DSM") is a co-operative multi-process application which manages an entire INtime system. Any process (Windows or INtime) may choose to monitor any other participating process or be monitored by other participating processes. Notification messages are sent to a monitoring process when a monitored process is deleted, or the communications path to that process is disrupted, or if the Windows system or INtime system is disrupted. This service may be used to provide system-level integrity.

Windows Stop Processing

An important benefit of the DSM is that it can detect when the Windows platform fails. In this case, the DSM software in the INtime kernel notifies all participating processes of the failure of Windows, and additionally suspends the thread responsible for scheduling Windows. At this point the INtime kernel can continue to execute its processes indefinitely and those processes can choose to take special action in this case, such as bringing peripherals to a known state. At some later point, a real-time process could choose to resume the Windows thread and allow Windows to continue to shut down and reset the machine.

Scalability Features

The INtime operating system is capable of supporting large, complex applications. On the shared architecture as described, it has been found that a typical platform will allow the INtime kernel to consume 50 percent to 60 percent of the CPU bandwidth before the Windows graphical user interface (GUI) and other services begin to be affected adversely. An advantage of the independent kernel in INtime is that it can be relocated to another CPU or another platform, allowing the application to scale as its demands on the platform increase. The interface paradigm changes from the virtual machine architecture to shared memory and then physical communications links such as Ethernet or serial line, but the software interface between the Windows and real-time applications does not change. This allows the same binaries to be used no matter what the hardware architecture chosen.

Conclusion

TenAsys Corporation's INtime software has been designed not only to add real-time capabilities to the Windows platform, but to add these capabilities in such a way as to provide a reliable and scalable platform for real-time applications. When paired with Windows XP Embedded, this solution provides you with a robust, scalable, and deterministic operating system for your embedded devices.

© Microsoft Corporation. All rights reserved.