I have a friend named Ivan. Ivan’s from the old country. A really great guy. He likes the Green Bay Packers (it’s kind of required in Wisconsin). He’s fun, married with two little daughters. That’s a problem, but he won’t know it until they become twelve or thirteen. I haven’t given him the bad news yet.
Anyway, Ivan’s real problem is that he’s an IT guy. IT guys are an odd breed. They’re different than us factory automation guys. We’re about making things go faster and getting better quality. It doesn’t matter if we’re making cars, doors, medicine or those little straw umbrellas they put in the girls’ drinks (visiting the little straw umbrella factory is on my bucket list). Factory automation isn’t a club; we don’t have a secret handshake or anything (at least one that they’ve let me in on), but we do have our way of doing things and our own technologies.
Ivan in IT and the rest of his kind have a much broader mission – to protect the electronic infrastructure of the corporation and the assets in that infrastructure. They have all sorts of rituals and processes for doing that. A lot of them I can understand and appreciate. Others I think are, well, nuts. Some of that is because the opponent (hackers) they’re working against is pretty stealthy. They can be attacked and not know it. They can lose millions of customer accounts and not know until long after the theft happened. They really never know if everything is fine or they’re just oblivious to the attack. Paranoia is an asset for IT guys.
So as we go about integrating with the company’s business systems (forward-integration with customers and backwards-integration with vendors) we have to be very conscious of how our work is going to be perceived by Ivan and the other IT guys. If we’re creating any vulnerabilities that are going to make the electronic infrastructure less secure, their paranoia is going to kick in and they’ll stop us pretty quickly.
A pretty typical example of that came up just the other day. A few quality control variables in a Logix processor are pretty important to understanding the operation of a process in the food and beverage industry. There’s a woman who is doing some analysis and wants to collect those variables from three Logix processors at three different remote sites in “the cloud” – the cloud in this case meaning a sequel database.
For those of us who aren’t IT trained, we’d think about this in a pretty standard way. An application in the cloud knows when to collect these things; it sends a message to the processors requesting that data. In this case, Logix processors, being not all that friendly to IT systems, would have one of our products (a RTA box) as a front end. The RTA box would gather the data and make it available in an OPC UA address space. Because the box is an OPC UA server, the cloud application could just ask the server for data every thirty seconds. Pretty tidy and straightforward from the factory automation perspective.
But it’s not tidy nor at all straightforward from Ivan’s perspective. To do what I’ve just described, there has to be an open port in the firewall for the cloud application to send the OPC UA message through to get to that server. That’s a problem. Because if the cloud app can send messages through, so can the people trying to infiltrate Ivan’s networks. Having an open incoming port through the firewall is a big non-starter for the IT guys.
On the factory automation side, we’ve always thought about clients (and masters) as devices like PLCs that communicate with servers (and slaves) to send them outputs and get their inputs. As we think about cloud communications, we are going to have to reverse that kind of thinking. Anything that needs to communicate with the cloud is going to have to be the client and send messages to servers in the cloud: providing them with data and requesting their data. Ivan’s OK with outgoing messages like that. He just doesn’t want unsolicited incoming messages.
You’ll be hearing more from us at RTA about cloud communications in the coming months. Stay tuned.