IoT Tech: The Universal Translator for the Industrial Tower of Babel
by Mike Fahrion
I attended the Automation Conference in Chicago today, where — among other things — I sat in the most uncomfortable chair that I have ever encountered. Human beings are all pretty much the same shape, so I’m guessing that the venue accidentally ordered furniture that was designed to accommodate some other species. Baby giraffes, perhaps.
But it was worth the trip, even if we had to perch ourselves on strangely shaped zoo equipment. I was surrounded by a crowd of very smart people, and we were there to discuss fun, geeky topics like industrial networking, smart manufacturing, and the Internet of Things. Being an automation conference, it wasn’t just futurists, analysts and the press. Most of these folks were hands-on operations technology types. They were looking for help with real issues and answers to questions that need answers right now.
I hadn’t even finished my first cup of coffee when I got into an interesting conversation with a plant manager named Alan. After the obligatory business card exchange, Alan got straight to the point – his reason for boarding a 6:00 A.M. flight to come to Chicago.
Alan operates a packaging plant. He’s got acres of machines and he’s got a vision. But he’s frustrated – maybe even a little angry. “I’ve got 153 different communications protocols in my plant,” he told me. “I’m tired of it. Every project I try, I run into problems. We can’t get machines connected to my network and my software without getting some five-figure quote for another layer of custom software, and I know it’s going to turn into six figures before we actually get it working.”
He summed it all up by saying that all he really wants is a plant that can answer the question, “How am I doing?”
Alan’s problem is far from unique. And his wish to be able to ask his plant, “How am I doing?” is spot-on. But trying to integrate every machine and process as a custom project is just a recipe for misery.
I said two things to Alan:
First, he’s not alone. He’s got 153 different communications protocols today, and he’ll probably have that many three years from now. It’s not ideal, but that’s just how it is.
Second, he’s been going about it all wrong. Nobody can afford to re-engineer their existing processes and machines every time they want to extract data up to some common application platform. It’s not just the money. Re-engineering means you’re mucking around with the systems that are paying your bills, covering your payroll, and producing your profit. No matter how careful you are, when you re-engineer your systems you’re going to break a few. There will be quality problems, interruptions, and downtime. Re-engineering existing systems to perform new tricks isn’t the answer.
I’ve talked to hundreds of Alans over the years, and I’ve come to the conclusion that solutions to extracting new data from the existing tech Tower of Babel have to embrace three principles.
- Don’t impact my existing processes
- Don’t impact my existing programming
- Don’t impact my people
First, you don’t have to re-engineer existing systems, and you shouldn’t. Nowadays you can layer new data communications technology over the top of what you already have. It won’t interfere with what’s already in place. It will simply collect and translate whatever data is already being produced, while simultaneously providing opportunities to collect new kinds of data; information that wouldn’t have been available just a few years ago.
Decide what parameters you really need to measure – the leading indicators from your operation. Then add appropriate equipment to grab those variables and publish the data. You may be pulling some information from existing networks and devices. You may be adding some new sensors and connectivity. But with today’s tech, there’s no reason that it can’t all work in harmony.
Say “No Way” to any more closed, proprietary systems that hold your data captive. You don’t need another M2M information silo. Your new layer of data communications tech can use today’s interoperable standards, and it will simply translate your proprietary communications protocols for use on modern networks. You may be gathering data from the operational world, but — no matter what the source may be — you can make all of that data available to your newest enterprise software.
If the difference between operations tech and enterprise tech sounds nebulous, just run it by some 20-something programmers. They assume that interoperability is the norm. Many would be amazed to learn that you’ve got protocols out on your plant floor that they’ve never even heard of, and that this is perfectly normal.
Alan got the point. He’ll be flying home tomorrow with a new strategy, and it’s one that won’t lead to an endless string of frustrating purchase orders. He’ll start small, adding bits of new IoT tech here and there, and he’ll turn his vision into reality one step at a time. And this time, he won’t have to break anything. He isn’t going to create any more information silos, either. It won’t be long before he can ask his plant, “How am I doing?” and the plant will provide clear, concise answers.
What’s you’re strategy for extracting useful data from existing equipment and processes? Talk back and share your success – or your pains or frustrations.
November 27, 2018
October 5, 2018
August 31, 2018