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.
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.
Embedded System: Control and operating system software stored in nonvolatile memory; operates in a diskless environment.
Diskless Environment: No rotating disk is used. Instead, FLASH devices (DiskOnChip, memory sticks, etc.) serve the same function as a hard disk. A diskless system can gain access to remote file systems through CIFS (Common Internet File System) or NFS (Network File System).
Kernel: The small "core" of an RTOS. It handles I/O in real time, manages multitasking operations, and isolates real-time functions from bloatware operations.
Bloatware: OS software that supports non-real-time functions, such as networking, .Net architectures, web servers, Internet communications, etc. An embedded RTOS cuts these back to the absolute minimum needed to fit into memory, and typically loses some high-level functionality in the process.
Interrupt: A hardware or timed function that forces the RTOS to stop whatever it is doing and go to a program that "services" the interrupt.
Latency: The time delay from an interrupt to the start of processing that interrupt. An RTOS typically responds to an interrupt in 1-10 Î¼sec., including jitter.
Jitter: Variations in timing.
Soft Real Time: Applications such as process control, where the latency time and jitter can be tens or hundreds of milliseconds, and the application can tolerate missed I/O scans.
Hard Real Time: Applications such as machine control that require latency times of less than 1 msec and cannot tolerate missing an I/O scan.
For real-time applications, embedded RTOSes strip down the code to a central "kernel," the primary function of which is to support real-time operations. The bloatware remains--it can support non-real-time functions such as .Net or TCP/IP--but it runs as a low-priority user task.
In an RTOS, the kernel handles critical I/O in one of two ways: via hard interrupts or timed interrupts. An emergency-stop pushbutton can be wired to a hard interrupt so it will be serviced immediately. Timed interrupts are similar, in that a clock interrupt going off at specified intervals--say, every 10 msec--causes the RTOS to call a routine to perform a specific action such as scanning all, or part of the I/O.
Most modern RTOSs support multitasking; that is, more than one software task can be going on at a time. In a machine, control programs that work in real time and keep the machine running have the highest priority.
For years, custom RTOSs performed these functions admirably. When we add the task of dealing with the enterprise, things get complicated. Not only does the RTOS have to work in real time, it has to carry around all the software to handle Windows-related baggage such as web servers, XML languages, .Net architectures and so on. This posed a problem a few years ago because it was almost impossible to combine the two in an embedded, diskless system. Fortunately, several modern embedded RTOSs can do it all.
Plenty of RTOS to Choose
Embedded RTOSes are now available for Unix, Linux and Windows-based systems. An example of a really-mission-critical application outside our machine builder nation makes a point about reliability: "We use several kinds of embedded RTOSs in our flight display and avionics systems," reveals Jonathan Wieman, embedded RTOS Software Engineer at Rockwell Collins, a manufacturer of avionics equipment for military and commercial aircraft. "We use an eclectic mix of embedded operating systems: LynxOS, Greenhills Integrity, and Windows XP Embedded. Each OS has unique advantages and disadvantages, and as such, thorough consideration is given to align every product with the OS most beneficial to the customer's needs."
Like some machine builders, Rockwell Collins also developed its own RTOS to meet its specific needs. "We developed a Virtual Machine Operating System (VMOS) in house to meet FAA requirements for flight-critical systems," Wieman adds."
Figure 2: Control to Die For
Die-sinking machine builder exeron relies on Windows CE
to provide hard real-time control and a dependable user interface
for its PC-based EDM Controller. The control handles
up to six axes and can be integrated into a network because of its
standard PC architecture. Source: Kuka
Rockwell Automation also uses multiple systems. "We have experience with Linux, VxWorks, Windows CE and Windows XP Embedded," says John Baier, director of software architecture, Rockwell Automation (www.ra.rockwell.com). "All are suitable for diskless operation, but each has its own issues with real-time operations. All embedded OSs must be tailored to operate properly with the hardware chosen and must be tuned to respond properly to the real-time constraints of the system being deployed."
Baier won't recommend any specific system, but he says, "the most important features for machine control are true real-time interrupt and task scheduling. A good TCP/IP stack implementation is also important."
The Windows World
For years, software companies have taken advantage of Microsoft bloatware, and written RTOSs that replace Windows or work with it to provide real-time control. Microsoft must have become tired losing industrial OEM and machine builder business to such upstarts, because it now has three embedded RTOSs in Windows CE, NT Embedded, and XP Embedded.
Beckhoff (www.beckhoff.com) uses CE.Net in its CX1000 modular industrial PC. "The real-time computing enabled by CE.Net ensures a deterministic response time between input and output signals in manufacturing processes," says Andreas Thome, product manager at Beckhoff. "Axes can move with a speed of 10 m/sec, so controlling this type of motion with a frequency of 1 kHz requires a deterministic, hard, real-time control cycle of 1 msec. Beckhoff's research and testing led to the conclusion that CE.Net on the CX1000 hardware platform meets the requirements: the fastest possible control cycle of 1 msec with a maximum jitter of 50 ?sec."
Siemens Energy and Automation (www.sea.siemens.com) uses CE in its line of Panel PCs, which are used in discrete automation. Intelligent Instrumentation (www.instrument.com) uses CE in its line of EDAS data acquisition and LANpoint data-collection systems, which are used with PLCs on machines. The core architecture is the same for EDAS and LANpoint: a 66-MHz CPU, 8-MB of RAM and an 8-MB compact flash memory.
"Even though these products sell to different markets, their common theme is to put your factory floor on line in real time," says Paul Liska, LANpoint product manager.
Advanced Engine Technologies, San Leandro, Calif., uses Windows XP Embedded in its Internet-enabled monitoring products. "We use XP Embedded because it supports .Net platform, which offers huge advantages in terms of connectivity, security and time-to-market," says Justin Stimson, principal software engineer. "Dot-Net offers ready-made, tested solutions to most of the problems we encounter when we develop complex, mission-critical, distributed systems. Open-source operating systems such as Linux and Unix give you the flexibility to re-invent the wheel, but that's not our core business."
Questions to Ask an RTOS Vendor
Whether you buy an RTOS or a machine controller that contains an RTOS, here are a few questions you might want to ask the vendor:
1. How much memory does the embedded RTOS require?
2. Can unneeded OS functions be removed to free up memory?
3. How much memory is available for application programming and data storage?
4. Does the RTOS have a flash driver with support for wear/leveling and spare blocks to protect the FLASH memory from wearing out?
5. Does the RTOS run on the processor you are using for machine control?
6. Can it run your legacy controller code?
7. Does it support the IEC 61131-3 programming standard?
8. What is its average latency/jitter? Maximum latency/jitter? Is this fast enough for your machine?
9. Does it support a Web Server?
10. Will it run application software written for the Microsoft platform? Does it support Microsoft's .Net architecture?
11. Does it support remote diagnostics?
12. Does it have the device drivers you need?
13. If not a Windows OS, can it support embedded Windows?