Embed with machines

n embedded real-time operating system (RTOS) operates as a standalone entity. It has no rotating disk from which it downloads files, so everything it needs must be stored in some kind of nonvolatile memory, immune from power losses. This is not a new concept. PLCs have had embedded RTOSs for 40 years, microprocessor-based controls have had them for 30 years, and PC-based control have used a RTOS for 10 years or so.

Machine builders have gotten along for years with small, dedicated, sometimes custom-written RTOSs. In the old days, embedded RTOSs supported standalone machines whose only link to the outside world probably was an operator display, an RS-232 port for downloading parts or programming information, and perhaps a network port for communicating with other machines in a manufacturing cell. All that has changed.

Today, even the simplest machines might have to hook up with enterprise-level software, support HMI/SCADA systems, connect to the Internet, and become part of an enterprise-wide network of linked machines. This enterprise world speaks in mysterious terms such as .Net, XML, OPC and Ethernet.

Although modern operating systems speak those languages and protocols, they don't fit into the embedded machine control world of limited memory and diskless operations. It's just not the place for big, memory-gulping bloatware operating systems such as Windows NT, which often require vast megabytes of memory and disk space.

What's a machine builder to do? Customers are demanding that machines talk to the enterprise, and that requires an RTOS compatible with the Microsoft world. Old reliable RTOSs can't deal with the Enterprise. Even an RTOS from two years ago might not be able to cope.

Figure 1: Certain Seat Security

Occubot, a robot-based automobile seat-wear testing application

uses a VxWorks/Windows XP Embedded extension for robot control,

data acquisition, robot path offset calculations, and test monitoring

 to be performed using a single CPU. Source Kuka Controls

Machine builders are making the transition. "All our machines use Windows," says Travis Rogers, control engineer at Controlled Automation (www.controlledautomation.com), manufacturer of steel-fabricating machinery and controls in Bauxite, Ark. Controlled Automation converted its machines to Windows-based systems several years ago and is now going to embedded RTOSs. "We run beam lines, detail lines, flange lines, angle lines, drills, and shape-cutting machines," he says. "The shape-cutting machines are [still] running on Windows NT and 2000 with a third-party real-time extension. We are about to change them over to Windows CE."

Enter the world of the embedded RTOS that can combine the best of both worlds: real-time response and Microsoft compatibility.

Inside RTOS

A RTOS provides the interface between the outside world and the machine control program. The outside world has devices and controls that move quickly, such as stamping presses, end-of-travel limit switches, motion controllers, vision systems and so on. The RTOS has to ensure that the control program is able to act on external events such as a limit switch closure in microseconds.

Ordinary Windows operating systems are not suitable for machine control because they are not deterministic; that is, there is no guarantee when the Windows OS will get around to looking at critical I/O. If an operator hits an emergency-stop pushbutton because a pallet fell off the conveyor, but Windows is performing one of its many interminable housekeeping procedures at the time, a problem may occur. Tooling can crash into hard stops while Windows updates a meaningless internal disk file.