Open architecture: Hype and fiction

By Joe Campbell, Adept Technology

Open Architecture is one of the most misunderstood, ill-defined, and over-hyped concepts in factory automation today. Nowhere is it more confusing than the industrial robot market. Manufacturers choosing a robot vendor need to understand what open architecture really means and be aware of the more common misconceptions surrounding this often overused term.

On one hand, nothing’s wrong with open architecture. Responsible robot vendors are delivering products that give customers the open functionality and benefits they want. However, the PC architecture is fundamentally at odds with the safety standards and support realities of the robot market. Fringe players, including open-architecture software vendors, quasi-government standards organizations, and some academics are ignoring these issues. The poor customer—the manufacturing manager who is responsible for real production—is caught in the crossfire of buzzwords and acronyms.

What customers really want out of open Architecture is:

• To use the PC as the HMI for their robot and automation cells, and leverage the common look, feel, and interaction the PC offers.
• To run third-party software as part of the robot cell. Typical examples include the HMI, cell control, and SPC.
• To give the robot access to corporate networks
• To host third-party boards to extend the capabilities of the robot.
• To use the PC as a management tool to maintain and control the applications software on an individual robot or network, and as a service and troubleshooting tool.

I don’t know of a robot vendor that would take issue with any of these requirements. So what’s the problem? Well, let’s talk about the misconceptions surrounding open architecture.

The PC makes robots cheap. Well, not really. To operate a robot with a PC and still meet safety standards, you minimally have to add motion control, an interface panel, safety logic and hardwired circuits, hardwired emergency stop and control interfaces, I/O, and pendant and industrial packaging.

Because of volume production, the PC is more reliable than any controller made by a robot vendor. Not really. Manufacturing discipline, the design, and test processes drive hardware reliability, not volume.

Open architecture controllers mean no more high prices for spare parts, because robot vendors gouge customers. Not so, and I resent the implication. Spare parts cost a lot because customers demand 24/7 access and support, next-day shipping, and seven-year support for discontinued product. Call your PC vendor and tell them you want a power-supply connector for a laptop purchased in 1993.

Open Architecture means third-party boards and software can be added at will. Nope. Most open-architecture robot vendors say no, because adding hardware or software violates safety guidelines and certification.

Open architecture means leveraging the Wintel platform. All standard components, right? Well, not exactly. The most common configuration is a PC running the HMI, a high-level programming language, and application layer. The motion functions are typically run on a motion board with its own CPU and a dedicated high-performance OS. The other option that has been successfully used is a single Intel CPU running two partitioned operating systems—Windows for the HMI and PC functions, and a real-time multi-tasking OS for the motion and safety functions. In either case, additional hardware is added for the safety functions and I/O.

With a clear understanding of what to expect from open architecture and the real benefits that might accrue, customers can get the facts about open-architecture by asking questions beforehand.

• How many CPUs are in the system? Is there a dedicated CPU for the motion-control function? How many operating systems are in the system? Have they been modified, or extended in any way? Is Windows the sole OS running the motion-control functions?
• Can a different I/O board be added to the system? How about vision and/or motion control? If so, will the system retain CE/RIA safety certification? Will the vendor continue to warranty, service, and support the system?
• What’s the difference between a robot controller connected to a PC via Ethernet, and a robot motion-control board installed in a PC?
• Is access to the servo code made available?
• If the PC dies, what happens to the robot? Is there a safety issue? Is there a separate hardware interface for the critical safety functions?