Implementing Windows as a real-time system presents challenges. An elegant and scalable approach is to extend Windows with a real-time scheduler as a single integrated platform.
BY DARON UNDERWOOD, INTERVALZERO
Page 1 of 1
Real-time operating system (RTOS) vendors and SoC vendors are racing toward the same destination. That is the next-generation platform for embedded systems that can handle both general-purpose demands like sleek human machine interface with multi-touch support, and the determinism and performance demands fulfilled by an RTOS, FPGA or DSP. And they want to do it from a single, integrated platform.
RTOS and SoC architectures vary widely depending on application requirements, and there are strengths and weaknesses for each. For instance, SoC solutions with FPGAs are prominent in systems requiring low power and small-footprint features like smart cameras used for manufacturing inspection.
On the other hand, for embedded systems that have plug-in power and an operator console requirement, the Windows PC has emerged as a formidable converged platform that supports both general-purpose operating system (GPOS) tasks and RTOS tasks from a single Windows PC. Applications demanding concurrent handling of GPOS and RTOS tasks on a Windows PC include PLC, Soft Motion, Semiconductor & PCB equipment, Inspection, Test and Measurement, Medical, Simulation, Pro Audio, Pro video and others.
We will look at why the Windows RTOS platform has become so powerful, and examine two different approaches to adding real-time functionality to a Windows PC to transform Windows into an RTOS Platform.
Cost Is Driving Convergence; Platform Creates New Innovations
Before recent innovations—real-time field buses, virtualization and 64-bit x86 SMP chips—a typical real-time architecture for many an embedded system was broken into two computing components. A Windows PC presented the front-end HMI, and a second PC or real-time computer would handle all the real-time tasks (Figure 1a).
Figure 1: Before convergence became technically possible, having a Windows HMI controlling real-time tasks required two systems (a). Now it is possible to converge the Windows and real-time functionality of a single system, reducing cost and complexity while enhancing flexibility and scalability (b).
Having two computers adds cost, so in the same way FPGAs and ARM have been married into a single silicon die, the goal of the convergence for powered embedded systems is to build a platform that allows the Windows HMI and the real-time functionality on the same Windows PC. Doing so eliminates the cost of the second PC and utilizes the power of the PC that typically sat idle while the real-time work was done (Figure 1b).
The cost savings go far beyond the elimination of one PC. Meaningful costs savings are possible when real-time hardware such as DAQ or motion card or other FPGA-enabled cards are replaced by a real-time, software-only application that runs directly on the Windows PC processing core.
To reiterate, success depends on executing the real-time motion algorithms directly on the Windows PC CPU/Cores rather than on a card. Examples of these solutions are commonly referred to as Soft PLC, or Soft Motion, in cases where PLC or motion control algorithms are run directly on the PC.
To achieve its full potential, a Windows RTOS Platform must offer a preemptive scheduler with a large number of thread priorities and predictable thread synchronization mechanisms. It requires a system of priority inheritance with very precise clocks and timers and highly optimized inter-process communications. It must have the ability to access hardware resources with little or no software latency and the ability to do it all in software.
The challenge for Windows is that it is a general-purpose operating system suitable for desktop and server applications, but not for real-time applications. GPOS Windows has too few thread priorities, an opaque and nondeterministic scheduling process, and a high degree of priority inversion, which negatively impacts determinism. In order for any Windows-based system to be considered a real-time embedded system, it must meet the challenge of all of the deterministic requirements found in an RTOS.
The Siemens SIMATIC WinAC RTX F is an excellent example of a Windows-based product that has achieved just such an astounding breakthrough. According to Siemens, its “SIMATIC WinAC RTX F permits simple implementation of safety systems on PC-based solutions, and satisfies maximum safety requirements and compliance with relevant standards: EN 954-1 up to Cat. 4, IEC 62061 up to SIL 3, and EN ISO 13849-1 up to PL e.
The fail-safe software controller is particularly suitable for automation tasks in which, in addition to standard and fail-safe control functions, parallel data processing and the integration of the user’s own technological functions are to be implemented on one platform and the openness of Windows is to be exploited. Siemens was the first to deliver an all-software, no-special-hardware Windows RTOS Platform solution in an off-the-shelf Windows PC, and proved the Windows RTOS Platform was real and viable.
The major hurdle that limited the Windows PC from achieving an all-software RTOS Platform capability was its lack of real-time I/O capability that could deliver the determinism required by industrial equipment or machine controllers. That hurdle has now been overcome.
The recent evolution of deterministic protocols that run on Ethernet is creating new options for devising real-time solutions on commodity equipment. Standards like Profinet and EtherCAT for machine control, GigEVision for Vision and other real-time protocols allow the use of commodity equipment like NIC cards and CAT5 cables to further lower costs. This eliminates the DAQ card, proprietary cables and associated costs.
With real-time Ethernet protocols, the real-time processing moves from an FPGA-based endpoint to the COTS Industrial PC, dramatically reducing costs for machine builders. For instance, an expensive smart camera with frame grabber and image library technology can be replaced with a less expensive camera and image processing that runs on the Windows PC in real time. The cost savings are significant because the entire solution is assembled from COTS parts.
Basic Architectural Elements of a Windows-Based RTOS Platform
Before examining the different approaches to how Windows can be transformed into an RTOS platform, it’s valuable to understand the RTOS platform’s key elements. To begin, let’s define real time. Real-time isn’t necessarily about speed, but rather about the deterministic response. The important measure is not the average response time, but the worst-case response time that you can count on in order to optimize your system. The deterministic nature of a real-time system allows the developer to understand and count on when things will happen in response to other events that do happen.
A successful Windows RTOS Platform, therefore, will deliver all the capabilities found in Windows, provide determinism equal to competing standalone RTOS, and do this on native hardware.
Architecturally, a successful solution for a Windows RTOS has two subsystems—the Windows subsystem and the real-time/RTOS subsystem—symbiotically sharing the resources of the system. The word symbiotically is used here specifically to demonstrate that there are two distinct systems, however, they share resources in such a way that they are uniquely aware of each other and each knows how the other is using those resources.
For instance, Windows provides the hardware abstraction layer (HAL) to interface the operating system with the hardware. The real-time subsystem needs to be aware of the way Windows interacts with this hardware abstraction layer and provide its own means of interfacing with it so that both Windows and the real-time subsystem are aware of each other’s needs and exclusive resources.
Once there is a stable implementation of how the two subsystems work together with the system hardware, then the real-time subsystem must provide appropriate elements. The main element is the real-time scheduler. This scheduler must provide strict thread priority just as any standalone RTOS would, as well as the ability for threads to run to completion if there is no higher priority thread waiting that could preempt it. With this, it is imperative to note that only threads compiled for real-time processing are run on the real-time scheduler. Normal Windows-based threads, including system threads, continue to be scheduled on the Windows scheduler.
The next step is the ability to program or develop against this architecture. A key component is providing a programming interface that not only allows development of real-time threads and processes, but also allows for Windows user applications to interface and interact with real-time processes. This allows the Windows developer and the real-time developer to share data and synchronization mechanisms between the two subsystems in order to present a complete product solution. This complete solution is done from a single tool chain, in this case Visual Studio.
The final element is the inclusion of drivers for key components such as network interface adapters that allow common networking components to replace traditional custom I/O and motion hardware. This is extremely important today as we see a shift toward the use of general-purpose networking interfaces as a means of machine control and data acquisition
Two Architectures for a Windows RTOS Platform
Now that the critical RTOS features have been identified, it is possible to define and examine the strengths of various approaches. The two principle architectures used for creating a Windows RTOS Platform are 1) Real-Time Virtualization, which implements co-resident Windows and RTOS, and 2) Windows with an RTOS Extension, which directly interfaces Windows with an RTOS Scheduler.
Real-Time Virtualization is an approach that is easily understood (Figure 2). The concept is not unlike server virtualization, where a hypervisor supports multiple virtual machines (VMs) and any number of guest OSs can reside in the VM. However, in this case, Windows runs in one VM and the RTOS runs in another VM. Of course, an RTOS will suffer latency and not be deterministic if it truly runs in a traditional VM, so the RTOS vendor must create a very thin layer to allow the RTOS to get in direct control of the hardware—or at least as much as possible. x86 vendors like Intel have created hardware-assisted virtualization technologies that make it easier for the cooperative coexistence of completely different systems. This is a best-of-breed approach.
Figure 2: A hypervisor-based system requires a separate operating system for each core or virtual machine adding to complexity and making it more difficult to synchronize and share resources.
The strength of this approach is that it isolates applications in secure partitions thus increasing system reliability and stability. It also eases software migration and consolidation. Running the RTOS on a dedicated processor core reduces jitter if hardware virtualization is enabled. Performing virtualization tasks in hardware to minimize latency decreases hypervisor load on the processor and also reduces context switching time between VM to VM. The challenge of this approach is that it is not truly integrated and requires the addition of further design elements to broker information and for synchronization between isolated silos.
The Windows RTOS Extension is designed from the ground up to maximize the use of existing Windows resources while only adding a second scheduler. As described in above, Windows provides the hardware abstraction layer (HAL) to interface the operating system with the hardware.
The real-time subsystem is designed from the ground up to be aware of the way Windows interacts with this hardware abstraction layer and provide its own means of interfacing with this layer in such a way that both Windows and the real-time subsystem are aware of each other’s needs and exclusive ownership of resources (Figure 3).
Figure 3: Windows extended with a real-time subsystem provides an architecture that takes advantage of the advancing technologies—specifically, high-speed, multicore x64—that can outperform and outscale the traditional embedded environment that relies on DSPs, FPGAs and microcontrollers or multiple cores using a hypervisor.
In sum, here is a list of some mission-critical features that can serve as a yardstick to measure the value of different approaches to building a Windows RTOS Platform on 64-bit systems. The real strength of this approach is Integration, which means single integrated development and deployment.
• Real-time scheduler
• Native 64-bit SMP scalability and visibility
• Direct memory addressing
– Non-Page Pool – up to 512 Gbyte on a 64-bit system
• Direct access to hardware (NIC, Serial Port…)
• Single installation when one real-time core is required
• Single installations when multiple cores are required
• Single integrated development environment – Visual Studio
– Single repository
– Managed code and C++ support
• Key Drivers
IntervalZero RTX 64 and RTX hard real-time software are prime examples of a Windows RTOS extension.
It is true that best-of-breed virtualization adds benefit. It provides a means of providing a platform that supports Windows and RTOS functionality, but duplicates resources, adds some jitter and cannot match the performance or versatility of a single integrated native environment.
Virtualization protects the past, but truly next-generation systems are possible only with integration on a single Windows RTOS platform. For example, GigEVision will be available due to low price, but only a single system running on multiple cores can take advantage of it. Virtualization will have too many standalone components that will need to communicate, and the communication will have too many instances (installations). Too much jitter. Too much latency.
A single integrated Windows RTOS Platform is the future. It is good to know there is a native, larger memory, 64-bit Windows RTOS platform solution available today. This is becoming the true platform for embedded systems innovation.