By Mike Bacidore, Managing Editor
Deterministic control and a real-time operating system (RTOS) go hand in hand, or, perhaps more appropriately, arm in arm.
"A machine that does closed-loop control of a motion operation, say a robot arm, must know at all times where the arm is located," explains Kim Hartman, vice president of marketing, TenAsys, www.tenasys.com. "If the control program needs precise position data and it's not immediately available, it might tell the arm to move when it shouldn't. Though the speed of the events being controlled is a critical factor in selecting a real-time solution, speed of the process is not the main factor that drives the need for determinism. The key requirement for determinism is reliability. A machine must respond with absolute bounded response time to events in its environment, or productivity and safety will be compromised.”
The degree of impact also can draw the line between hard and soft real-time necessities.
"In a hard real-time system," explains Andy Gryc, senior product marketing manager, QNX Software Systems (www.qnx.com), "a missed deadline could pose a safety hazard or have serious financial consequences. But in a soft real-time system, late responses still might have some value. Soft real-time systems require accurate timing for best performance but might be able to degrade gracefully if the deadlines aren't met. The boundary between soft real-time and non-real-time isn't precise, because even a non-real-time system has to respond within a certain amount of time. Any system that requires a recognition or response within a specified amount of time is a candidate for an RTOS.”
There is no hard rule for the duration of the response time since the amount of time will vary by the type of system. A shaft encoder system might have a limit of 150 msec but could be tolerant of some variation because of the nature of the encoding.
Hard real-time means you have a hardware-interrupt-driven cycle time with a small jitter, explains Stephan Stricker, product manager, B&R Industrial Automation (www.br-automation.com). "Violating the cycle time will cause system failure or exception fault," he says. "Soft real-time means that you have a preferred cycle time, but violating this cycle is tolerated to a certain point. Typically, you would expect cycle times below 10 msec are most likely RTOS systems.”
Besides the guaranteed cycle time, the equidistance of the cycle time is another important factor on RTOS, adds Strickler. "Here it doesn't matter what the cycle time is provided that it is always constant," he states. "This is important for motion control where a master position is shared over an RTOS to slave drives. The controllers in the slave drives are often synchronized, so besides a fast update cycle it is also important that the update time is equidistant.”
Real-time operating systems are required when a machine must respond to events in a predictable manner, explains Hartman. "For example, a CNC machine tool must get real-time inputs from sensors monitoring the position of a cutting head, and then, based on information about the pattern being cut, it must drive the head to the next position," he says. "In order to precisely follow the pattern, it is common that on-the-fly trajectory calculations must be performed continuously while updating motor position at a 10 kHz rate. To produce the highest quality results and maximize the throughput of the process, an RTOS is an absolute requirement.”
If an RTOS is needed, the question is whether to create it yourself or buy it.
"If you're using a homegrown system, you need to guarantee that your code has the appropriate timing loops," says Gryc. "Insertion of any additional features into such a carefully tweaked system requires thorough testing to prevent existing functionality from being compromised. In comparison, an off-the-shelf RTOS can ensure that the system will behave as designed, without requiring complex testing and validation after each change. The RTOS vendor will have done testing to ensure that a system built using the RTOS behaves deterministically, with measurable guarantees on latency. Also, an RTOS provides standard mechanisms, such as thread scheduling and prioritization, inter-process communication and interrupt control, for enabling deterministic response.”
Hardware also impacts the RTOS. "Typically, when you design with an RTOS, you are looking for three main things—determinism, stability and ruggedness," says Tim Dykes, senior systems engineer, Viewpoint Systems (www.viewpointusa.com) in Rochester, N.Y.. "When selecting hardware to run your RTOS, it is critical to consult with the RTOS company you chose. They will have tested the RTOS with an array of systems and can guide the designer about items to watch for. Little things such as motherboard chip sets can have dramatic impacts on performance. Also, in most cases industrial-hardened components are a must-have.”
A seeming trend in machine building is to place more control functionality in software rather than hardware since the flexibility of software programming enables quicker changeover times and easier maintenance. "FPGAs can be used when a control function can be hardwired—it won't change from time to time," says Hartman. "Hence FPGA controls might be satisfactory for controlling a machine subsystem that does the exact same thing over and over again. If operating parameters change, however, an FPGA-based control system might not be able to adapt."
"As applications get more and more complex, and FPGA technology gets easier and more cost-effective to use, FPGAs have started making inroads," offers Dykes. "Many applications we develop now use FPGA technology. The trend has started to remove traditional hardware for LVDT demodulation, resolver demodulation, system control and high-speed signal analysis. By replacing this hardware with FPGA firmware, the designer can have more flexibility to update, change and better match end systems for testing. FPGAs offer a way to help offload the RTOS with the extreme high-speed tasks. Many systems now use a mix of FPGA for front-end inputs and outputs, coupled with an RTOS for complex floating-point math, data streaming and storage and user interface bridge. In less-complex applications, the RTOS, which is typically a separate item from a user PC, can be replaced with one FPGA. This reduces the system footprint and can reduce cost."
