RTC Magazine

Many of today’s embedded applications require the stability and reliability provided by a deterministic hard real-time operating system (RTOS). Simultaneously, the markets these embedded applications serve benefit from the flexibility and extensibility associated with a general-purpose operating system, like Microsoft Windows.

With the undisputed lion’s share of all PC installations, there is no more popular software platform than Microsoft Windows. Windows provides access to third-party applications from specialized communication protocols to database applications and mathematical analysis tools, all of which can easily transform a dedicated data acquisition and control system into a sophisticated analysis and enterprise system resource.

Optimized Solutions

Balancing the flexibility of Windows with the deterministic requirements of embedded applications often results in two distinct computing elements built into one system. One piece of hardware to run Windows for the GUI, third-party applications and enterprise-related functions and a second hardware element to host a dedicated RTOS that controls the time-critical elements of the machine.

The drawbacks to this approach are numerous. A second control computer adds substantial cost of goods and manufacturing complexity. The additional design costs, in terms of time and effort spent on engineering tools and staff, is generally sufficient justification to seek a simpler and more cost-effective solution.

The real-time embedded tasks of a system are generally very well defined. Thus, with the aid of a real-time extension for Windows, it is frequently possible to compress these two dissimilar computing elements (Windows and real-time) into one off-the-shelf computing platform. The solution is a flexible cost-effective alternative to the “dual-computer dual-OS” system.

Efficiency in Hardware and Software

When system requirements surpass the ability of Windows to properly service a task, there are alternative solutions to merely adding hardware and complexity to a system. Before a real-time extension to Windows can be considered as a viable option it must, at the very least, be safe, secure, reliable and extensible. It must be implemented on a platform that supports dependable, hard real-time functionality, and the application must be easy to design, build and integrate using standard tools. Such a real-time extension for Windows implements a virtual dual-computer dual-OS architecture using a single piece of hardware, resulting in a “single-computer dual-OS” solution: One compute platform supports two virtual machines.

Like the dual-computer dual-OS approach, applications built for a single-computer dual-OS system must be divided into two basic parts: deterministic and non-deterministic. The non-deterministic part executes on the Windows virtual machine, and the deterministic part(s) executes on the real-time virtual machine. In order for these two parts to work together as a single application, they must have managed access to a variety of shared objects such as mailboxes, semaphores, mutexes and shared memory.

A significant advantage of the virtual machine approach is that developers can leverage standard development tools for both environments. To ensure efficient implementation of real-time threads, they should be provided with an environment that supports direct access to I/O and memory, a fixed priority scheduling system with priority-inversion protection, and simplified interrupt-handling services. Developers can then create and deploy real-time applications without the need to write complex and cumbersome device drivers for access to real-time hardware.

Real-time processes and threads also need to have access to high-speed interval timers for accurate, low-drift time measurements and for generating accurate periodic events to ensure precise control of real-time systems. The accuracy and drift of these timer elements are strong functions of the specific platform, being optimal on uniprocessor and multiprocessor systems with an advanced programmable interrupt controller (APIC), which represent the vast majority of embedded and desktop Windows platforms built today.

The net result of this virtual dual-computer dual-OS approach is that it avoids redundant computer and communication hardware. The real-time kernel and its processes run on the same hardware as the standard Windows kernel, sharing the CPU, memory and I/O resources.

Architecture is Key to Reliability

The architecture of a real-time Windows extension has a strong bearing on the security of the system. Intel’s 32-bit x86 processors (80386 through modern Pentiums) include unique hardware features that accommodate the ability to simultaneously run multiple operating systems. A real-time extension that takes full advantage of these features to build a secure environment in which real-time and Windows processes are isolated and separate on the same machine will be the optimal solution.

Real-time extensions that utilize these unique x86 features are able to meld deterministic, hard real-time control with standard Windows operating systems without the need for additional hardware. The solution is to create two virtual machines on a single CPU, and provide isolation between the two kernels. This dual kernel approach (Figure 1) provides protection from Windows “blue screen” crashes, which is critical to hard real-time applications. The solution is cost-effective, easy to develop and maintain and delivers microsecond response time.

Encapsulation of Windows

A real-time extension, isolation is implemented by creating a separate “hardware task environment” to contain the real-time kernel and all of its processes, including real-time code, variables, I/O and interrupts. This hardware task environment is constructed by building completely separate global and interrupt descriptor tables (GDT and IDT), page tables and other data structures, which are specific to the operating system and independent of those maintained by Windows. Finally, the Windows operating system, its drivers and all its applications are “encapsulated” by the real-time kernel and set to run as the lowest-priority task in the real-time environment.

Isolation between the real-time environment and Windows is significant, because it ensures a secure operating environment for real-time threads in a Windows environment; the only “hooks” into Windows required are located in the Windows hardware abstraction layer (HAL). The HAL must be “hooked” to ensure that shared hardware is properly managed between the two operating systems. Specifically to:

• Manage hardware resources exclusive to real-time processes or shared with Windows.

• Ensure that interrupts reserved for real-time use are never masked or assigned for use by any Windows software.

• Intercept attempts to modify the system clock rate, ensuring that the real-time kernel controls the system time base.

Maximizing Security

Just as the occurrence of a Windows “blue screen” will not result in stopping a properly isolated real-time environment, a misbehaved real-time thread should not crash Windows. If real-time processes operate as user-level (ring 3) threads, exactly like standard Windows applications, they can be stopped or restarted without destabilizing the rest of the system. Executing real-time threads at user level (ring 3) also noticeably simplifies the debugging process.

The CPU hardware protection mechanisms can be utilized to maintain isolation between individual applications and between applications and the kernel without severely restricting direct access to I/O devices. Unlike Windows threads, user-level real-time threads can be configured to perform direct I/O using the CPU’s IN and OUT instructions and can map physical addresses into their virtual address space. Likewise, real-time ring 3 threads need not be restricted from manipulating the interrupt flag via the set and clear interrupt (STI and CLI) instructions. These differences between the two virtual machines make it is possible to build a flexible, secure and controlled runtime environment where problems within either of the two environments can be easily isolated and are not liable to result in latent problems elsewhere in the system.

There is no performance penalty for executing real-time applications at the more reliable and protected ring 3 operating level. Software executes at exactly the same speed in ring 3 as it does in ring 0. The differences between these two operating levels have to do with the execution of certain privileged instructions, fault (trap) handling, memory protection and the use of debugging tools, not performance.

Because the real-time extension divides the processor into separate virtual machines, real-time applications are able to take advantage of the address isolation features built into the CPU, to “lock-out” memory between all processes in the system. If any thread attempts to access an address outside of its virtual address space, a fault is generated that can be handled without affecting other processes (Figure 2).

Simplification of Development Using Standard Tools

The very mechanisms that must be in place to transfer data between the Windows environment and the real-time environment (mailboxes, semaphores, mutexes, shared-memory, etc.) can also be used to support the development and debugging process. Since both environments run on a single piece of hardware, it is very easy to develop, debug and test in place on a single machine. The optimum solution takes advantage of standard Windows development tools (compilers, editors, linkers and debuggers) by placing helper threads on the real-time kernel to provide low-level runtime access to real-time processes and threads, reformatting that information for use by the high-level tools.

No intermediate simulation step is required to debug real-time code that runs in a ring 3 environment. User-level real-time threads should always be able to execute on the real-time kernel and always run in real-time. Further, the debugger in Microsoft Visual Studio .NET is extensible so that a real-time specific extension can be built to support debugging real-time threads directly from within the .NET debugger, making development of applications for these two environments a seamless process.

Using a single development tool, Microsoft’s Visual Studio platform, a software engineer can simultaneously write and debug real-time and Windows code (Figure 3). If all Windows threads and real-time threads run only in user mode (ring 3), the protection model of the x86 can be used to gracefully trap programming and memory errors, numeric exceptions and hardware faults that would normally crash a device driver solution. Working in a protected operating environment also facilitates rapid and more complete testing than can be accomplished by a kernel mode (ring 0) approach, adding assurance to the fact that you are delivering safe and reliable code with your system.

When looking to Windows as a platform for embedded real-time systems, it is critical to ensure that the real-time extension provides the necessary level of reliability and determinism, both now and in the future. With the proper tools, corporations can utilize Windows for a variety of real-time embedded applications, from data communication equipment and medical imaging applications to factory floor automation. Windows-based embedded real-time applications are able to take full advantage of the standard Windows user interface, its powerful network capabilities, rich development tools and off-the-shelf software, and still deliver the rock-solid, reliable performance required of hard real-time systems.

TenAsys
Beaverton. OR.
(503) 748-4720.
www.tenasys.com].