In many cases, a hard real-time solution is required. Know the factors that'll affect your system.
In recent years, the explosion of embedded devices has blurred the line between a genuine real-time operating system (RTOS) and an operating system that can serve an embedded system. Generally speaking, RTOSs are a subset of embedded operating systems. While you can solve many application challenges with an embedded operating system, some challenges can only be solved with the determinism afforded by a hard RTOS.
One of the most important applications that falls in this category is high-speed control. High-speed control is found in a host of devices and systems ranging from medical instruments and packaging machines to vehicle engine simulations.
The most common type of control that requires real-time execution is a closed-loop control system. Closed-loop control systems normally perform three fundamental actions:
• Acquire feedback signals from the system being controlled, often called the plant.
• Perform logic and/or signal processing on the input signals based on a desired behavior.
• Generate output signals that affect the plant, as shown in Figure 1.
To separate high-speed control systems from all other control applications, consider that high-speed control systems need to operate at loop rates of 1 ms or less, or perform the aforementioned three actions deterministically at a rate of at least 1 kHz. Moreover, these systems must achieve the control-loop rate to avoid mission-critical system failure.
High-speed control systems, therefore, require a hard real-time solution. While performance is absolutely important, high-speed control systems have other requirements. To find the right RTOS for your control applications, you must consider the following factors:
• Software development tools
• Control algorithm integration
• Hardware and I/O support
• Code footprint
The most important consideration when choosing an RTOS is reliable performance. The operating system must meet basic horsepower requirements to enable the control software to do its task. One of the most important requirements is low interrupt latency, which is shown in Figure 2. The system must be able to respond quickly and predictably to events such as a new input signal. The terms for gauging this performance are maximum interrupt service routine (ISR) latency and maximum interrupt service thread (IST) latency. High-speed control applications, such as hardware-in-the-loop simulations and motion control systems, typically require ISR and IST times to be less than 10 µs.
Most true RTOSs, such as Wind River's VxWorks, QNX's Neutrino, and Green Hills' Integrity, can meet these requirements. In addition, various amalgamations of Linux and real-time schedulers, such as RTLinux and RTAI, can solve high-speed control application challenges. On the other hand, operating systems that weren't designed for real time from the ground up, such as Windows XP Embedded and general distributions of Linux, don't meet the interrupt latency requirements.
Software development tools
Next, consider the software development environment you need to program a particular RTOS. Just as performance is similar to the horsepower of an RTOS, the development environment is similar to the suspension and “ride” that make it comfortable to use. While the RTOS may have all the right specifications, the development environment has an enormous impact on the quality and speed of development as well as the project's overall success. These features can be as simple as syntax highlighting and function completion or as powerful as code-generation wizards and source-code control compatibility. Effective code-generation tools for common functions can save days of development time for new and experienced developers. Another factor to consider is the availability of add-on tools for development environments. Eclipse-based environments such as Wind River Workbench and QNX Momentics offer a wide array of third-party plug-ins.
It's one thing to know a system is capable of high-speed control, but it's another to achieve it consistently. The debugging capabilities of your real-time software development tools can mean the difference between creating a successful control system and spiraling into an endless search for elusive bugs. Standard features such as single-stepping, printf() , and syslog() methods are necessary, but optimizing a real-time application is difficult without advanced debugging tools. These include application profiling, memory analysis, and execution tracing tools.
Application and memory profilers offer insight into the processor and memory usage of each task running on the system. By identifying which tasks are using the most CPU and memory resources, you can quickly find areas that need optimization. Keep in mind that the level of technical support an RTOS vendor provides can be critical in the development and debugging stages.
Execution tracing tools reach another level of debugging by offering a visible representation of thread execution, interrupts, preemption, and other events. You can spot troublesome scheduling issues and identify timing problems in your application that cause control instability using these tools. Examples of advanced debugging tools include Green Hills' EventAnalyzer for Integrity OS, National Instruments' LabVIEW Execution Trace Toolkit, QNX's Momentics system profiler for Neutrino, and Wind River's ScopeTools for VxWorks and Linux.
The “high-speed” designation not only indicates fast control processing, but also implies advanced control strategies. In fact, the heart of a control system is the algorithm or logic that processes the input signals to produce the appropriate outputs. Depending on the application, the control algorithm can range from simple discrete logic that drives valves and relays to a complex differential equation that determines a motion profile. As the algorithm becomes more complex, it may be necessary to have access to high-level complex math functions such as fast Fourier transforms (FFTs) and proportional-integral-derivative (PID) algorithms.
Because most RTOS integrated development environments don't contain such libraries, you must explore several options. You can develop algorithms yourself; however, that can take significant development time and require expertise not readily available. You can find these algorithms as part of an open source library, or you can purchase them from IP vendors. Alternatively, code generation may be an option if you created the control algorithm using a modeling tool that has code generation such as I-Logix's Statemate or Dynasim's Dymola. Finally, you may consider high-level development tools that include analysis functions and can target embedded controllers directly, forgoing the need for code generation.
A conversation about high-speed control systems wouldn't be complete without a discussion of the appropriate hardware processing targets. Often, the available software options are gated by a predetermined hardware platform, or the hardware is limited by the support of a particular software tool chain. You must consider processor performance, cost, and environmental specifications, to name a few important factors. For example, hardware-in-the-loop simulation systems that run intensive control models require high-performance processors and are usually best served by multicore processors. Not all RTOSs have equal support for multicore processors, so the depth of support is an important consideration during your selection process.
Industrial machine control systems or field control devices may require processors that can handle extreme temperatures ranging from -40° to +70°C or more in some cases. Battery-powered control devices, of course, require low-power processors. The top performance of processors that meet rough environmental and power restrictions is, by nature, lower than that of general-purpose processors. This means the RTOS has less horsepower to work with, making the performance and footprint even more important.
A control system's connection to the plant is the I/O hardware that interfaces with the physical signals of the system that's being controlled. The I/O may include any combination of analog voltages, currents, digital signals, pulse-width modulated signals, radio frequency signals, and so on. Look for an RTOS that has wide support for the required I/O types. Whether you're selecting individual I/O components such as ADCs and DACs or multifunction PCI data acquisition boards with a large number of I/O channels, consider the software development. Expect to develop more low-level code when dealing with single components, as opposed to off-the-shelf hardware for buses such as PCI, PCI Express, CompactPCI, PXI, PXI Express, and VME.
Off-the-shelf devices usually have higher-level drivers, but these can vary between vendors. Some offer only board support packages (BSPs) with peek and poke interfaces, while others have full-fledged application programming interfaces (APIs) that include advanced features such as direct memory access (DMA) transfers. I/O boards also vary in critical specs for control systems such as accuracy, isolation, and connectivity to signal conditioning.
While the control system connects to the plant through I/O, it corresponds with the operator through communication protocols and graphical user interfaces. Because Ethernet is ubiquitous, TCP communication is one of the most important protocols. The RTOS used for the control software must have a robust TCP stack to interface with the outside world.
There are many other general embedded interfaces such as USB, Bluetooth, I2C, and SPI that are useful for control systems, but there are also industry-specific interfaces that control systems may need. For example, the aerospace market uses protocols such as ARINC 429 and AFDX; the automotive market uses CAN, LIN, and FlexRay; and the industrial automation market uses DeviceNet, PROFIBUS, and Modbus. Once again, you must be aware of available BSPs and APIs for your RTOS and the amount of development it will take to integrate the specific protocols into your application.
Avoid reinventing the wheel
While this article examines how to develop a control system by selecting an RTOS and development tools to create control software from scratch, there's also an alternative approach. For years, industrial automation engineers have been creating control systems using off-the-shelf programmable logic controllers (PLCs) and modular I/O. Historically, PLCs have been limited to lower-performance control applications with mostly discrete logic and simple control algorithms.
However, in recent years, a new breed of embedded systems called programmable automation controllers (PACs) has combined the features of embedded computing with the rugged reliability of PLCs. From a software perspective, PACs feature real-time platforms with high-level programming environments that can venture into lower-level coding for more advanced applications. The PACs' hardware cost is higher per unit than barebones embedded hardware, but the development cost is typically lower and therefore, the time to market is shorter. For high volumes, the custom embedded route is usually the most effective one. When implementing low-volume deployments, however, consider whether a deployable PAC may be a better solution.
Gerardo Garcia is the National Instruments product manager for LabVIEW Real-Time. Garcia started his career at NI in 2002 as an applications engineer. Garcia holds a bachelor of science in electrical engineering from Texas A&M University. He can be reached at .