One bus for all?

When it comes to applications that allow our basic controls to function, system lock-ups are intolerable, so it pays to examine the heritage of fieldbus and carefully analyze the market that shaped it.

By John Rezabek

Share Print Related RSS


By John Rezabek, Contributing Editor

Inside FieldbusToday, 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 (often?) painfully brought to light. In recent weeks, threads on many list serves and blogs lamented the failure of IT/IS professionals to grasp why operators have a problem with graphics call-ups 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 their operator and engineering interface. Typically, they’re many times more powerful than the demands we place on them, and shelling out less than $2,000 U.S. for an updated workstation sure beats the old paradigm, where just a card upgrade would likely be an order of magnitude (literally!) 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 have had even proprietary operator stations become unresponsive, and the real heart of the automation systems kept chugging along, so a rare Ctrl-Alt-Delete to revive a frozen HMI is usually 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 was an existing 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 and 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, sprinkler heads, etc.). 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. That we were “out of our element” became even more apparent when we called for tech support. After waiting for the system to boot for many hours (maybe OK for a building?) 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 of which routinely shut down at shift change or for the weekend. The assembly-line paradigm haunted us in the early PLC days, as 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 still sells 1,000 I/O devices to the Ford engine plant up the road for every 10 he sells me, which shapes his priorities when it comes to 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 ±10ms determinism needed to control a printing machine, for example. And, when DuPont or Shell demand action on an issue, they will likely get attention quicker 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 may have an undesirable impact on your process.


  About the Author

John RezabekJohn Rezabek is a process control specialist for ISP Corp., Lima, Ohio. Email him at jrezabek@ispcorp.com.

Share Print Reprints Permissions

What are your comments?

You cannot post comments until you have logged in. Login Here.

Comments

No one has commented on this page yet.

RSS feed for comments on this page | RSS feed for all comments