Will RTOS Co-exist With GPOS?

Continuous Data Flow
An RTOS at the core of the control software provides immunity from potential Windows crashes and enables extremely fast and deterministic logic solve times.

Coordination between CPU cores is typically handled via built-in interprocessor communication mechanisms—IPI or inter-processor interrupt—avoiding the overhead of the context switch times associated with single-core solutions. Communication between operating systems is managed by a real-time-aware embedded virtual machine manager (VMM) that supports the configuration of multiple operating systems on a single hardware platform.

Kim Hartman, vice president
TenAsys

Kernels Rise to the Top

The Windows operation environment is user friendly for the developer and users. But the real-time performance is not guaranteed. To achieve the real-time motion control, the solution can be running a real-time kernel on top of Windows and then running the motion control in the real-time kernel. Like the Advantech PAC solution, we have a software kernel take care of the IEC-61131 programming interface, as well as the real-time performance. In the mean time, the customer can still enjoy the convenience brought by Windows, like full stack of Ethernet, file system, database and even the multimedia service.

Peishan Juan, production manager
Advantech Industrial Automation Group

Crash Immunity

There are several real-time operating systems on the market today that run seamlessly together with the Windows operating system.

Any automation control software with a dedicated RTOS on the front end, such as Steeplechase VLC, provides unprecedented system stability and reliability.  This is a critical consideration for factory floor applications, especially when used with a Windows-based PC.

An RTOS at the core of the control software provides immunity from potential Windows crashes and enables extremely fast and deterministic logic solve times, down to 200 microseconds.

At the same time, it allows the use of user-friendly Windows interfaces, such as mouse or graphic capabilities while enhancing system stability, increasing performance and improving machine uptime. Unlike real-time drivers that reside within the Windows kernel, a front-end RTOS creates two virtual machines that run side-by-side on a single hardware platform. The RTOS resides on its own protected memory area and takes advantage of the address isolation feature of the CPU itself.

With the help of the dedicated RTOS, the logic execution is kept separate from Windows operations and always has priority over and runs without interference from Windows processes. This ensures 100% priority to run the control of the machine.

Bjoern Falke, product marketing senior specialist
Phoenix Contact Automation Systems

Three Approaches

There are numerous approaches that could be considered for this application. Three that I would recommend looking into would be the following.

1. Use a real-time operating system (RTOS) in place of general-purpose OS (GPOS)
2. Consider a virtualization approach to allow a GPOS and RTOS on same machine
3. Create a custom design with off-the-shelf FPGA technology

First, aside from a completely custom approach, the RTOS approach is perhaps the most traditional and common method to solving this type of application. Simply replace the GPOS on your PC with an RTOS and run your controller in hard real-time. A second PC or HMI could be used as your host and allow visibility and interactions with the controller via a network connection. This allows the high-speed control to run at very high loop rates with minimal jitter. Advantages of the RTOS approach are determinism and reliability. In languages such as C or LabView that are commonly used for control, it's just a matter of compiling your code for your RTOS. The only caveat to look out for is making sure any type of I/O peripherals you are using have the appropriate real-time drivers.

Secondly, many vendors are offering products based on virtualization technologies that allow a GPOS and RTOS to run side by side. This is an innovative approach that truly allows both operating systems to have their own hardware resources. The industry move to multicore processors separate CPU cores on a single chip—has made virtualization very attractive. In this scenario, there is not one OS that is in charge, with the other OS essentially running on top. Rather, the system resources—CPUs, memory—are partitioned according to the desired configuration. Chip vendors such as Intel are investing heavily in R&D to support this technology at the processor level, which in turn is creating an ecosystem of OS vendors and companies that specialize in virtualization to deliver this technology to engineers that need such a configuration. The advantage of this approach is you get the best of both worlds—the utility of a GPOS and the control capabilities of an RTOS.

The third approach would be a custom design using off-the-shelf FPGA technology. This would be the most robust and flexible option of the three, and the control algorithm would run on the gates of the FPGA for determinism in true hardware, no OS layer. PC-based plug-in cards, or alternatively ruggedized stand-alone FPGA systems, are available to create a controller with FPGA technology that can be programmed with high-level languages such as LabView, so you don't need to be a VHDL expert to utilize this technology. This approach is beneficial because you can obtain the performance of a custom design, while still having the flexibility to re-program the FPGA down the road.

All three of the approaches above offer their own pros and cons, so the first step would be to determine how much of your control system code could be reused when migrating to a new system, or if it makes sense to just start from scratch with a new design. Also, consider how flexible your system needs to be moving forward, and if future design modifications will be added down the road.

Jeff Meisel, LabView real-time product marketing manager
National Instruments

Let the Need Dictate the Solution

The problem here is a simple one: the Microsoft OS and the real-time OS (RTOS) each want total control of the computer hardware. You can still have them work together. Multiple methods exist to do this. The key is understanding the benefits and consequences of each method.

Method 1: Use two different computers. In many ways, this is the ideal solution. Each OS controls its own computer and communicates with the other OS over a LAN, backplane, serial port or other interconnect. Often, a single program will be written on each side to handle communications between the two computers. Other programs feed data to that program, which then forwards the data to the other computer. Because this approach isolates communications, you can easily change the physical connection without modifying every program on both computers. There are downsides to using two computers, however. First and foremost, the approach might simply cost too much or consume too much physical space. The speed of the communications link can also pose an issue—serial, for example, might not satisfy application requirements. Finally, if you use two computer cards that communicate via shared memory on a common bus—CompactPCI, for example—you must take synchronization issues into account. For example, if locks can’t take effect within a single bus cycle, you may need to utilize another mechanism, such as token passing.

Method 2: Use a single multi-core processor. This is really a variation of Method 1. Here, the Microsoft OS runs on one core and the RTOS runs on the other. This is known as an asymmetric multiprocessing (AMP) configuration. This method has all of the benefits and problems of Method 1 with one additional deficit: at boot time, both operating systems will want to take total control of all of the computer hardware. This includes all of the processor cores if the OS is capable of symmetric multiprocessing (SMP); examples of SMP operating systems include Microsoft XP/Vista, Linux and QNX Neutrino. For the RTOS, this usually isn’t a big issue since you typically have access to the OS source code or can configure the RTOS to limit the hardware resources it uses, including the number of cores. The Microsoft OS can pose a greater issue, since source code usually isn’t available. To address the problem, you can use a virtualization layer. This software runs a small control program directly on the hardware, presenting a virtual machine to both operating systems, which fools them into believing they each own the hardware. In reality, the virtualization layer controls the hardware and either grants one OS temporary, exclusive access to the hardware or provides hardware access via queues.  While this approach works well for non-real-time systems, it can fail badly when a system has to meet hard deadlines. Because the virtualization software isn’t aware of the scheduling deadlines within the real-time system, it can potentially allocate a hardware resource to the Windows OS, causing the control software on the RTOS to become delayed and thus non-deterministic. The additional time required to run the virtualization software can also delay a real-time process, potentially making the system miss deadlines.

Method 3: Use virtualization. With this method, the virtualization software runs as an application on a host OS, providing a virtual machine only to the second OS. This approach differs from the virtualization mechanism in Method 2. Under that method, both operating systems run on top of the virtualization software, whereas in this method only one OS runs in a virtual machine while the other OS acts as host. Communication is performed in a similar manner as in the other two methods, typically with some type of real or virtual network. Virtualization software will often create a private virtual Ethernet network to the host. The key here lies in which OS is chosen as the host. If the RTOS runs as the host, then the Microsoft OS, which isn’t real-time anyway, will get machine cycles only when the RTOS permits it, typically enforced by a priority scheduling scheme. This is a proper method of designing the system, but unless it is carefully engineered to leave sufficient time for the Microsoft OS to run properly, the results will be less than satisfactory. For example, if the Microsoft OS handles the user interface, as is often the case, the interface will run very slowly if the Microsoft OS isn’t given sufficient time to execute. Reversing the situation and using the Microsoft OS as the host would be even worse, however, since the Microsoft OS would then schedule the virtual machine and the real-time system, making the chance of deadlines being properly met on the real-time side slim.

Which method should you use? All of these methods have their benefits and all have their drawbacks. Ultimately, your choice depends on which RTOS you use, since each RTOS brings different advantages to the table.  For example, scheduling methods available within some real-time operating systems can make Method 3 very attractive if the RTOS runs as the host. The RTOS will always guarantee that the virtual machine running the Microsoft OS receives some amount of CPU time. If the RTOS is also multicore (SMP) capable and can lock specific processes to each core, then methods 2 and 3 can merge. The RTOS can act as the virtualization software host and lock the virtual machine running the Microsoft OS to one of the cores while locking real-time processes to any core except the one allocated to the virtual machine. This approach guarantees that the Microsoft OS has its own processor; yet it doesn’t interfere with the real-time processes. Since the RTOS is in full control of the hardware resources and has knowledge of system priorities, if contention between the operating systems does occur, the RTOS can resolve the contention in favor of the real-time processes. You can choose the best method for your application once you examine the capabilities of the RTOS, whether virtualization is a reasonable solution, what the deadline requirements for your system are, cost factors, and so on. There is no single solution that satisfies every need.

Jeffrey Schaffer, senior applications engineer
QNX Software Systems

PLC on Steroids

Microsoft’s Windows operating system is a powerful and well-known software package that can run many popular applications, tools and drivers. Its widespread acceptance and user familiarity make it a great user interface in the automation industry. Machine builders can select from many different SCADA and visualization packages that run on Windows. However, a Windows OS alone is not the optimum solution for high-performance, deterministic machine control. For this, machine builders need a real-time operating system (RTOS). Traditionally, this has been handled by a separate controller such as a PLC. This typically requires additional hardware, software, communication and wiring, all of which mean additional time and cost.

Non-proprietary extensions allow a real-time, multitasking OS to be seamlessly integrated together with a Windows operating system on the same PC while keeping its full real-time capabilities. In this way, a machine builder is capable of achieving high-performance logic and motion control, as well as visualization and communication on a single standard PC platform. A single piece of hardware replaces a PLC, motion controller and PC from a traditional system. These real-time extensions allow machine programming according to the IEC 61131 standard, including ladder diagram and structured text as well as open standards such as ANSI C. Advanced programming, debugging and diagnostic tools are built in to the real-time system along with remote maintenance capabilities. It is also possible to incorporate soft CNC functionality into the real-time control.

The advantages of this real-time PC-based control include reduced hardware cost, increased mean time between failures (MTBF) due to fewer system components, smaller cabinet size and the reuse of existing Windows-based drivers, visualization and SCADA packages. These PC-based controllers can take advantage of today’s fastest processors and can even run on multi-core processors such that one core is dedicated to the real-time OS while the Microsoft OS runs on a separate core. This results in guaranteed, deterministic response times within microseconds. Communication between the real-time and Windows world is easily realized. Power fail logic and buffered static RAM ensure critical data can be stored in case of a power failure. And the real-time OS can continue to run even if the Microsoft OS crashes—Windows Blue Screen—allowing the system to shut down safely.

Finally, the real-time OS and Microsoft OS must be paired with a robust, reliable hardware solution. This means a true industrial PC. Many of these industrial PCs are built to the same industrial standards as PLCs. Unlike standard desktop PCs, industrial PCs are designed to run in harsh production settings and have superior shock and vibration performance and extended temperature ratings that allow fan-free operation even in extreme environments. They have specially constructed PC boards that eliminate the need for internal cables that can vibrate loose. Maximum PC temperatures are often specified at 100% CPU load since the fast cycle times of the real-time OS will take full advantage of the CPU’s capabilities. Media options such as extended temperature range, 24/7 hard drives and redundant array of independent disks (RAID) drives help to improve the reliability of the system, but solid-state media such as industrial compact flash cards eliminate rotating parts, have a much longer lifespan than standard compact flash cards and provide a true industrial system.

Nathan Massey, sales engineer
B&R Industrial Automation

October’s Problem

Our control panels include five panel meters that receive from the PLC and display analog parameters like machine speed and temperature to machine operators. Our panel meter manufacturer is going out of business, and we’re wondering if we should just switch to another manufacturer or go to a solid-state graphics display. We know the graphics display could show lots of information besides just five meter readings, but we’re concerned about up-front hardware costs and about controlling software development costs. What's the best way to go?

Send us your comments, suggestions or solutions for this problem. We’ll include it in the October ’08 issue and post it on ControlDesign.com. Email us at [email protected]. Please include your company, location and title.

Have a problem you’d like to pose to the readers? Send it along, too.