To be effective, implementations of remote diagnostics generally require a fair amount of collaboration between the corporate IT department and manufacturing operations. It’s no secret, however, that the necessary understanding is often lacking when the two groups first come together, thereby slowing the adoption of information technologies in production.
The source of these difficulties has been their different worldviews, which, of course, stem from their different functions within the organization. Manufacturing operations tend to stress the ends of the network, whereas corporate IT tends to focus on the means. “Operations personnel are concerned about what remote diagnostics will give them,” explains Dan Schaffer, business development manager for networking and security at Phoenix Contact. “Corporate IT, on the other hand, is very concerned about how are you establishing that remote connection. Are you using a VPN? A phone line? Is it going through our firewall?”
In other words, each group tends to emphasize different elements of the CIA Triad (confidentiality, integrity and availability) that network experts use to define the main components of information security. “IT will sacrifice a little bit of availability or responsiveness in order to keep the confidentiality leg as strong as possible,” Schaffer says. “On the operational side, it’s all about availability. We need this line or plant up and running. It’s what keeps the lights on.”
The good news is that the two groups generally appreciate each other’s perspectives once they have a chance to work together on a few projects. For this reason, automation vendors often advocate expediting the process by assigning someone to work in both camps. One believer in this method is Ben Orchard, applications engineer at Opto 22. He was the one chosen when he worked at another company years ago during his formative years as a controls engineer.
“I was fortunate in that my engineering boss, a mechanical engineer, recognized the need,” he recalls. “Seeing that I had an interest in networking, he farmed me out to the IT department for two days a week for two years.” During that time, not only did he learn about information technology and strategies, but he also was able to educate the corporate IT staff about manufacturing.
A good example of the latter occurred when he brought in an industrial controller with an Ethernet port and admitted that it could send email. “The IT guys freaked out because they assumed that it was a PC capable of getting malware and becoming an email spambot,” he says. “It took a while to teach them that it was not an email server and couldn’t receive emails, but instead only sends an email based on an exception of a temperature or a pressure.”
The reality is, however, that not every facility is big enough to support this kind of intimate collaboration. In these cases, Orchard suggests instead a facilitator or mediator, who can attend meetings of each group to pass along insights from the other group. He describes the ideal mediator as a high-level technical person who is not in management, but still plays a hands-on role in operations.
Even when a mediator exists, though, establishing clear lines of responsibility is important. “Collaboration between corporate IT and manufacturing IT must at a minimum include establishing a line of demarcation—that is, the rules on who has responsibility where,” says Carl Henning, deputy director at PI North America.
“Often, the border is a single firewall between office and manufacturing. This would make remote access the responsibility of the control engineers, but they would be wise to get advice from corporate IT.”
