Network Connectivity

The control engineer has retrofitted each primary work-center with an small panel to collect machine data. The configuration consists of a local HMI and a MicroLogix controller. His next step is to get his panel on our enterprise network. Wired Ethernet was our best choice since the hardware and infrastructure required to support 802.11 wireless is still more costly and complex in its configuration. We began discussions around security and the most cost effective solution was to logically separate the shop floor network from the enterprise via the means of VLANs. The traffic is still routed through the same network hardware as all other traffic, but the machines are logically split from the rest of the network. Running a network drop to the nearest IDF costs under $300 per machine. A single drop per machine is sufficient because of the way our panels were built. We have two flavors: dumb switch or a MOXA router. The dumb switch method means that each component inside the panel has an enterprise LAN IP address. This chews through the DHCP server allocations with no real value to us in the future, while increasing risk and complexity. The preferred configuration isolates all components behind a router with NAT capabilities. This way our enterprise network only sees a single IP address of the hardware hosted behind it. What this means to the control engineer is that he now has a pretty standard IP addressing setup behind the router. Secondary operations and all mechanical machines are retrofitted with specific purpose sensors tied to a Banner Engineering TL70 wireless light stack. The signal then travels over 900Mhz to the Banner DXM 100 controller. Fixtures and tertiary tooling are connected via DigiPort when possible.
So now you have all these machines and devices online, they have an IP address, and are segmented from the enterprise network. Now what? Time for the control engineer to talk to an IT guy. The data flowing from the machines has to be made sense of somewhere and the de facto standard has become Kepware’s KepserverEX Communication Platform. KepserverEX is an OPC server and the Manufacturing Suite comes with drivers for many, many PLCs. When starting with this project, before the IoT Gateway was released, our option into real-real time data was to ride the OPC-UA protocol. This got complicated quickly and I like to leave OPC-UA work to people smarter than myself. What makes Kepware’s product special, you might ask? There are multiple OPC servers on the market. However, Kepware is the first one to expose the machine interface over more IT friendly and familiar protocols like HTTP and MQTT. I do not get paid for saying good things about Kepware (maybe a couple unicorn t-shirts), but I continue to stand by Kepware’s solid product and excellent support.

Leave a Reply

Your email address will not be published. Required fields are marked *