Jim Barry, Michael Batchelor, TJ McDermott and Rick Rice—these are individuals you need to know. Four of the most expansive thinkers in the machine-building technology space, these engineering veterans comprise the Control Design Editorial Advisory Board.
As an introduction, they shared their thoughts on a variety of topics, from motion control and wireless sensing to control platforms and cybersecurity. Here is their take on network security.
CD: Network security is a topic everyone asks about, and yet no one turns a nose to data connectivity because of security concerns. What does a manufacturing facility really need to know about network security, and how can they minimize the risks?
TJ McDermott: There’s no good answer to this question. It’s not being handled well. Those companies who do take data security seriously invariably take it to the extreme such that work becomes difficult.
Michael Batchelor: Network security is more than just a hot topic. It is an essential component for the future. Not only are open networks vulnerable to interruption, either malicious or benign, but the protection of trade secrets is also important. After all, manufacturing is money. Who wants their bank on an open network?
Rick Rice: I still believe that a pyramid architecture is as relative today as it was back in the early days of automation and SCADA. Levels of security were easier back then because the Ethernet connection on a PLC-5 didn’t allow the user to get into the ControlNet communication between adjacent PLCs nor did it allow anyone to get into the DeviceNet network where the field devices lived. We didn’t worry about someone getting into the configuration of a VFD on our steel pickling line because the dissimilar media wouldn’t allow the person who hacks into the plant Ethernet network to port through the ControlNet connection of a parallel processor and then through the DeviceNet or serial connection to the VFD.
Today’s PAC allows for navigation through the backplane of the controller rack to anything else that lives in that rack or other connected racks. This presents an even greater mixing of the build-in barriers because now we have similar network media on multiple levels of control. Ethernet can be used to reach a PAC from an outside connection, but it is also used to talk between controllers on the same level of control, and—fear and worry—it can also be used to connect to devices at the field level. In the interests of simplifying connectivity, we have taken down the physical barriers that were built into our earlier control systems.
I think the trick to mitigating risk and managing our systems involves becoming more intelligent about the technology we have available to us. The hardware vendors have been very good at selling the new features of connectivity and wizards that help us get things talking. However, what they don’t do such a good job with is telling us about the infrastructure components that we should have in our plant to control the pathways that lead to our machines and processes.
I have, for instance, a new ribbon blender that we just installed. It uses a CompactLogix platform with everything associated with the blender communicating via Ethernet. As a controls engineer, I was very happy to be able to just plug everything in to the device-level ring (DLR) technology that lets me just daisy-chain all of the devices in a linear fashion with the tail plugged back into the head. I was even more thrilled to learn that the vendor also has devices that interface non-DLR devices into the cute little network ring that I just created. Now, as a programmer, I can use one of those cool non-DLR interface modules to connect to my facility network so that I can connect from elsewhere in the building and get to my new mixer. I added a wireless router to the system, and now I can connect to not only my new mixer but the older-technology SLC-5/05 processors in the other six mixer rooms. Isn’t technology great?
My IT manager dashed my youthful exuberance by asking me how much traffic I was adding to his network. His network? Well it’s just my seven processors, right? Wrong. It is my sevem processors plus my remote Flex I/O rack, two HMIs, two VFDs and a scale interface, all talking to each other on his network. How did this happen? I was very careful to pick the right devices to leverage this new technology that was available to me. I was elated to get it all talking to each other. I was even able to overlook the fact that each of those non-DLR connection points had to have their own unique Ethernet addresses, making my clever address-planning chart explode with all these additional devices on my nice little control system. Suddenly, my vision of a nice, neat, interconnected mix facility is an IT nightmare.
Now we go back to the drawing board. If I want to connect to my new mixer, I go to the mix facility, 3 miles away from my office, and plug in like the old guys do—at the PLC in the room. Our next step involves going back to the school of network architecture. It will lead me to sessions with our vendor, figuring out the architecture that I now wish I was aware of before I got into all of this. I wouldn’t have done anything differently with my control system, but I sure would have had my eyes open when it came to my expectations of how we might connect to the Internet of Things and access all of the big data that the trade magazines are talking about.
Did you enjoy reading our content?
Main Image courtesy of Stuart Miles at FreeDigitalPhotos.net