As the Digital World Turns

Dan Hebert’s cover story starting on page 16 reports on the differences, similarities, and likely futures of safety networks for discrete factory and process plant applications. He also takes some time to explore how these connectivity issues might evolve over the next several years.

This continues a theme we began discussing earlier about the possible, maybe probable is a better word, convergence of various types of networked functions—control, safety, building environment, physical security—all on the same network backbone. That’s certainly been a steady drumbeat of interest on two fronts. The user community needs to keep simplifying its network infrastructures, and the various high-visibility protocol camps, with few exceptions, want all your functionality on their particular “cable flavor.”

Our automation and technology industries tend to define themselves by the biggest and the best—and most visible—companies and manufacturing facilities. It’s usually where the most-complex problems and solutions can be found. It’s also where individual engineering functions first became specializations over the years as this complexity began to grow. That specialization trickled, some would say bled, into companies of all shapes and sizes. It can be a little problematic within mid- to small-size manufacturing companies.

Some of you know I spent quite a few years as an engineer or manufacturing guy for specialty-batch chemical manufacturers, and I’m reminded that there often was a time (less than 100 years ago, honest) when the same personnel handled the engineering needs for batch processing back-end, as well as the filling, packaging, labeling ,and boxing at the front-end. The “process” engineer, the “project” engineer, and the “discrete” engineer hadn’t yet evolved into individual species in many companies.

The system requirements became more complicated, but more importantly, when we started to go digital, the process stuff went toward what we call fieldbus, and the discrete stuff headed toward device networks. They necessarily evolved at the time with inherent differences that began to require full-time specialization. Batch plants decided they’d better hire engineers with discrete manufacturing backgrounds to handle the motion requirements outside of the batching area. The specialists at both ends of the plant got really busy. They had less and less time to keep up with news from the other end of the plant. Best practice exchange transformed into forced, formalized meetings instead of random, frequent, spur of the moment conversations.

Until recently it was a good bet they’d never swing back towards each other. To which you might say, “So what?”

Well, what I know is this divergence meant the collective understanding of a facility’s overall engineering framework was weakened, even if individual segments grew stronger. There are plenty of people besides me who know you can’t optimize parts of an entity unless you really get how the parts work together. All the automation, instrumentation, and controls can’t overcome that.

So, the possible convergence (re-convergence to us old guys) of the networks and buses to a more common infrastructure, common configuration and diagnostic tools, and eventually common controllers, I/O and operating software can provide a priceless secondary payout. The domain of the specialist might begin to make some room for engineers, who now have their hands in everything. And it won’t be because they have to; it’ll be because it makes good sense.

I suspect some of you will disagree with this premise. If you do, let’s expand the conversation. Tell me why, please.

Finally, let me offer a word of advice to you bickering wireless protocol camps out there. Take a lesson from the torturous, embarrassing journey that the wired world took. Don’t build solutions for specialists. Very soon, we might not put up with it anymore.