Two Operating Systems, One Processor

By Gerd Lammers

An ability to run both real-time and user-friendly operating systems concurrently on a single CPU can reduce cost, boost performance, and improve user access to the real-time behavior of industrial systems. The challenge has been getting two operating systems to cooperate on the same processor, but that challenge has now been met. Software developers have successfully run the Microsoft Windows CE and the Wind River Systems VxWorks real-time operating systems along with the Microsoft Windows XP desktop operating system on a single x86 CPU, and done it without modifying source code.

Running a desktop operating system together with a real-time operating system on a single CPU is a very attractive solution for industrial systems. Such an arrangement lets the user monitor and interact with the real-time processes via a familiar user interface while guaranteeing real-time performance and determinism. It also provides access to a vast array of tools for handling data and provides a straightforward link between the factory floor and the executive suite.

The traditional approach to simultaneously meeting the needs of real-time control on the factory floor while providing a simple user interface and sophisticated data handling ability has been to use two processors, one running a real-time operating system (RTOS) for control and one running a desktop operating system such as Windows for the user interface and data handling. But running them on separate processors introduces unacceptable overhead for communication as well as added hardware costs. Industrial systems, like many others, face the need to keep system complexity, size and cost to a minimum.

It is now possible, however, to successfully combine the two operating systems on a single CPU. To be labeled “successful” in this context means that the combination must meet a critical requirement: there must be no compromise of the RTOS environment’s real-time performance and stability. The occasional annoying Windows application crash or operating system exception is seldom an actual disaster in the office environment. The same cannot be said of a system that is trying to manage moving robot arms, high-temperature processes and critical sensors. A failure there could lose important data or even endanger human safety. The RTOS cannot afford to be affected by anything happening in the Windows environment.

Fortunately, it is possible to completely isolate the two operating systems (OSes) from each other, allowing non-disruptive communication between the two without compromising real-time performance. The solution, diagrammed in Figure 1, lies in creative application of drivers, in low-level configuration code for interrupts and context switching, in virtual networking, and in strict memory protection. By providing this isolation and by working at the driver level, developers can run both operating systems without needing to modify the source code of either.


Figure 1: Running on a single x86 CPU, Windows XP Embedded and a commercial RTOS occupy separate and protected memory address spaces and communicate through shared memory via networking protocols forming a virtual network. Real-time applications run separately, at a higher priority than and unaffected by the Windows XP operating system.

Separate Memory Areas

The first step in implementing a dual-OS design is to ensure that the two operating systems run in separate memory spaces with no possibility that either one can write into the space of the other. This requires that a developer first configure Windows XP’s awareness of its memory resources, then add the RTOS image and code extensions needed for dual operation as diagrammed in Figure 2. Developers can accomplish this memory separation by modifying the setup of Windows XP’s boot initialization. For instance, if the system has 512 Mbytes of physical memory, configure Windows XP so that it is only aware of 412 Mbytes. On subsequent boots Windows will not be aware that the other 100 Mbytes exist and will have no access to that memory space.


Figure 2: To set the dual operating system, first boot Windows XP and define a separate, protected memory domain for the RTOS. Then load the previously configured RTOS image, in this case Windows CE, from disk into the protected memory area. A �shared� network memory area is set up for inter-OS communication.

The next step is to load Windows XP. The image to be loaded, created using standard tools such as Platform Builder, will include all the components, drivers and board support appropriate to the application along with special elements such as virtual networking that are needed in the dual OS arrangement. For Windows XP, these special elements include custom drivers and some low-level extension code. The extension code looks like a driver to Windows XP but allows low-level configuration and monitoring of CPU interrupts. There is also an uploader that runs as a Win32 application under Windows XP. The uploader copies the RTOS image from disk into the fixed memory area, boots the RTOS, and then terminates. At this point both operating systems are loaded into memory and the RTOS is in a fixed space that the MMU (memory management unit) keeps separated from Windows, leaving the RTOS totally protected and stable. Windows XP is completely unaware of its existence.

Virtual Networking

The two operating systems run separately, but they will need to be able to communicate. In addition, the RTOS needs to be able to respond to priority real-time interrupts with no interference or overhead from Windows XP. One way to establish communications is to set up an area of shared memory in the fixed and protected RTOS space. Because of the MMU protection, Windows cannot directly read and write to this shared memory. Instead, the two OSes communicate over a virtual network using TCP/IP. Windows XP runs the standard Microsoft NDIS network driver dedicated to this virtual network while the RTOS has its own TCP/IP stack.

The virtual network gives the RTOS and XP the ability to notify each other of events that take place on their respective sides. The communication takes place by placing messages in the shared memory, but to the TCP/IP drivers it looks as if they were communicating over a network. This notification method allows the two OSes to coordinate tasks. For example, Windows XP might signal the RTOS that some user input had occurred that requires action on the part of the RTOS.

On (hopefully rare) occasions, Windows XP might signal the RTOS that it has crashed. Because of the MMU’s strict separation of the memory domains, a “blue screen” on the Windows XP side will simply generate a message to the RTOS side notifying it of the crash. The RTOS will receive this event like any other; otherwise it is completely unaffected by the Windows XP crash. The RTOS is free to implement an appropriate response to the crash.

One possible strategy would have the RTOS move all the machinery, such as robot arms, into safe positions and perform an orderly shutdown of operations so that the system can be rebooted. In another scenario, one that requires little or no user interaction, the system might continue to operate until the end of a shift or some other convenient point where maintenance can be performed. Whatever strategy is created to respond to the crash, it is incorporated as a part of the RTOS’s application and is triggered by the crash event notification from Windows XP.

While the network over which the two OSes communicate is virtual, each OS can also connect to other networks. For example, XP could be connected to the enterprise network or to the Internet, while the RTOS could be connected to a field bus such as Profibus or CAN. The only restriction on these additional networks is that they cannot share the same network interface card (NIC). As with the memory domains, network interfaces are assigned to each OS and are protected from the other.

Handling Large Data Files

Employing an additional communication mechanism in the dual-OS configuration can help speed the exchange of information when large amounts of data are involved. Many industrial systems gather data from their real-time operations for analysis or use away from the factory floor. Transferring a large block of data generated by the real-time processes, such as a graphics frame, could be tedious using only TCP/IP. An alternative for sharing large data blocks uses an additional area of memory that can be shared but is separated from both the RTOS and Windows direct memory spaces. This shared memory can be arbitrarily large in size.

Instead of working directly with this shared space, the OSes read from and write to the shared memory via pointers. The exchange of data blocks then becomes a matter or writing to the shared memory and sending a message to trigger the other OS to retrieve the data. Thus, the RTOS can deposit factory data as it is generated and Windows XP can retrieve it and store it to disk where it becomes accessible to such desktop tools such as Excel or more specialized data analysis applications. That data also becomes available to and can be formatted for all the needs of the enterprise.

Contexts, Priorities and Interrupts

Even though the two OSes run in separate, protected memory spaces, they still share the CPU’s hardware, including its interrupt system. The RTOS needs to have priority for handling interrupts, but because Windows is loaded first, its interrupt handler is already in that position. In order to ensure that the RTOS maintains its real-time response, then, the interrupt handler for Windows needs a certain amount of “real-time extension” code implemented at the hardware abstraction layer (HAL) to modify the handler’s behavior. The modified interrupt handler reconfigures the CPU’s response to interrupts, placing the Windows XP tasks as the lowest priority. This extension code behaves like a driver that loads when Windows XP boots up.

The real-time extension code has two major responsibilities. First, it monitors all interrupts before either OS responds to determine if an interrupt is meant for Windows XP or for the RTOS, then invokes the appropriate interrupt handler. If Windows XP is running and a real-time interrupt occurs, this extension code performs a context switch to run the RTOS and immediately sends the interrupt to the RTOS. There is some slight overhead associated with this initial context switch -- approximately 5 microseconds on an 800 MHz Intel® Pentium® processor. After that, all real-time interrupt service routines execute exactly as they would if the RTOS were running standalone.

The second responsibility of the real-time extension code is to provide a gateway that permits developers to alter hardware assignments and interrupt tables. When Windows XP boots, it does so as it would do normally; it detects all the hardware installations and assigns them interrupts. After the RTOS image loads, developers can use the access that the real-time extension code provides to reassign slots and interrupt lines to the RTOS. At the same time, developers need to install a dummy driver to “keep XP happy” when it no longer has access to the resource.

The execution of the two OSes and the interrupt handling will then follow the flow shown in Figure 3. Windows XP only runs when all RTOS tasks are idle. When any real-time task is running and a Windows interrupt occurs, the interrupt is queued according to priority until the last real-time task has completed and the RTOS is idle. At that point a context switch lets Windows XP start running. Any real-time interrupt that occurs while Windows XP is running will cause a context switch to the RTOS and all real-time tasks will execute before any Windows XP task. All interrupts that are enabled for the RTOS have a higher priority than anything in Windows XP including Windows interrupts.


Figure 3: The RTOS, in this case VxWorks, is invoked when a real-time interrupt occurs. As long as any RTOS task is active, control of the CPU remains with the RTOS. Only when all real-time tasks have completed does Windows XP run again, allowing it to service any Windows interrupts that occurred during the time the RTOS was active.

This dual-OS technique represents a total software solution for running Windows XP Embedded along with a commercial RTOS on a single x86 CPU without modifying the code of either operating system. Instead, all the programming needed to allow concurrent operation comes in the form of add-on code. In the case of the RTOS, additional code is incorporated as operating system library components or drivers at the time the RTOS image is built, or as parts of the real-time application. In the case of Windows XP, code is included as drivers that boot with the OS and provide the ability to configure lower-level code at the hardware abstraction layer. The result is a real-time system that runs without compromise and also connects to all the networking and management needs of the enterprise without the cost and overhead of additional hardware.


Gerd Lammers is the director of worldwide sales and marketing for Real Time Operating Systems at KUKA Controls GmbH (www.kuka-controls.com). A Microsoft Gold Level partner, KUKA Controls is a subsidiary of KUKA Roboter GmbH, the largest European industrial robot manufacturer and a part of IWKA AG Group. gerdlammers@kuka-controls.com