By John Rezabek, contributing editor to ControlGlobal.com
[This article first appeared in Control in May 2007.]
Today, most automation professionals have experienced the joys of using hardware and software designed for office environments. When applied to process control, the vagaries of operating systems and hardware designed for web browsing and word processing are sometimes painfully brought to light. Threads on list servers and blogs lament the failure of IT/IS professionals to grasp why operators have a problem with graphics callups that are slowed by virus-scanning software or commands to update passwords every six weeks with—ahem—a “strong” one that includes numbers, letters and symbols.
The cheapness and ubiquity of the personal computer and Windows OS have driven nearly every major automation supplier to adopt them for operator and engineering interfaces. Typically, theyÂ’re many times more powerful than the demands we place on them, and shelling out less than $2,000 for an updated workstation sure beats the old paradigm, where just a card upgrade would likely be an order of magnitude higher.
We also tolerate PCs in our control systems because their defects rarely encroach on the truly high availability part of our control system. Most of us even have had proprietary operator stations become unresponsive, and the real heart of the automation systems kept chugging along, so a rare Control-Alt-Delete to revive a frozen HMI usually is tolerated.
But when it comes to applications that allow our basic controls to function, system lock-ups are intolerable. In this class of applications, it pays to examine the heritage of said infrastructure (i.e., fieldbus) and carefully analyze the market that shaped it.
I had a colleague who believed Lonworks was the device network of the future. Employed largely for building automation systems, Lonworks is a standard that appeared to have a physical layer (twisted pair), processing power and bandwidth suited for process control. But once implemented on a real process, we became painfully aware of our place in the Lonworks pecking order.
We were pioneering this bus for process control, but were only a tiny fraction of Lonworks users. Node counts for a typical building might number in the thousands—mostly a relatively generic class of devices with low diversity (e.g., light switches, smoke detectors, and sprinkler heads). But our process application had low-node count with very specialized and diverse devices, distantly related at best to the relatively cheap and mass-produced devices in an office building. It became even more apparent that we were out of our element when, after waiting for the system to boot for many hours, we called for technical support, which charged $1,000 per call after the first one. We were a tiny market for Lonworks, so why invest a lot of resources to help us?
Each of the buses available to us has its own heritage. Some evolved to serve discrete parts manufacturing.
Shutting down a network briefly to add a node may be a trivial occurrence on an assembly line—many routinely shut down at shift change or for the weekend. The assembly-line paradigm haunted us in the early PLC days, particularly when we had to pull an entire I/O card to change a fuse.
After sufficient outcry, this issue was resolved. Similarly, we no longer have to shut down the bus to add a device on a number of platforms. Still, the PLC guy sells 1,000 I/O devices to the Ford engine plant up the road for every 10 he sells me, and that shapes his priorities about accommodating the features I want.
Foundation fieldbus and its competitors are designed to have the bulletproof integrity and availability demanded by the large process industries. But the design choices made will result in limited salability to an automation engineer interconnecting CNC machines or robots on an assembly line. While macrocycle times are adequate for continuous process control and equal or better than what has been available in a DCS, one will not achieve the ±10 msec determinism needed to control a printing machine, for example. And, when DuPont or Shell demand action on an issue, they will likely get attention more quickly than the robot/CNC application.
Like host systems, bus technologies are shaped by the users and markets they serve. When deviating from the products that evolved to serve your particular manufacturing community, be prepared for some discoveries that might have an undesirable impact on your process.
