Are Routers the solution to my problem?

[ian s 0]

Hi all In our factory we have 10 or more panels running AB PLC's (Mainly SLC & a Few CLX). All the panels use Ethernet for local PLC-HMI comms but none of the panels are networked to each other. They all use different IP address ranges which causes some of our maintenance guys problems when trying to connect into the panels via the installed ethernet switches. I have suggested installing routers in each panel so that either of our two laptops could be plugged into any panel without requiring its TCP/IP properties changing. The routers would also be the first step towards networking all the panels back to a central point for data & alarm logging/SCADA/backups. My reason for suggesting routers was so that we did not have to reprogram the existing comms links within the PLCs/HMIs and to provide a common IP Address for our laptops. Also in the future routers would supply subnet isolation for our new process network. That is about as far as my basic networking knowledge gets me but I have been asked to take this suggestion further by specifying routers for the job. Any answers to the following questions would be helpful. 1. Are routers an appropriate solution for this problem, If not what is?. 2. Does the intended use of PLC Programming, Upload, Download, SCADA limit my choice of router. 3. I had envisaged using fixed IP addressing tables rather than DHCP. Is that a good choice? 4. Recomendation of any particular router(s). Cheers ian

[paulengr 44]

If you still insist, get an industrial grade one such as the ones from Hirschmann. These particular ones also allow you to implement firewalling to isolate general LAN problems from your controls network. A 100% switch fabric is still be best in my opinion and I'd rather be putting in managed switches instead.

[Nathan 7]

To add my $.02 to Paul's good advice. 1. A router could absolutely solve your problem. However, you would need someone who knows what they're doing. This is very different from sharing your home Internet connection via a Linksys device. It probably does make sense to segment broadcast domains (what a router does) between separate processes. Paul is absolutely right - even if you wanted this type of configuration, the proper way would be to use "non-routable" (RFC 1918) address ranges. It sounds like you're trying to patch up a mistake. But if downtime is money, you can do it. Document the heck out of whatever you do! Network guys are bound to look at you with very little respect until you justify what you had to do to upgrade your legacy system. 2. If your network will always be physically isolated from the Internet then the address range isn't so important - skip this answer. You can share Internet access using a proxy server or "real" router with IP addresses that aren't yours. It's considered to be poor practice by convention for several good reasons. This is another task that will need more expensive hardware and an "expert". Contrast that to using 192.168 addresses where you could set this up yourself with a Walmart router. 3. For your question #2 - the PLC programming and SCADA package operate at a "higher level" than the router. 4. Go with static IP addresses for PLCs. DHCP for clients. For central management I often prefer using DHCP with reservations for servers and printers, then accessing them by name (DNS takes care of this for you). This would be ideal for PLCs if the hardware and software wasn't so primitive (ie, RSLinx Ethernet driver only working with IP addresses instead of hostnames, PLCs using BOOTP instead of DHCP, etc). 5. Router advise - use whatever the person implementing it is familiar with. I like Cisco. BOTTOM LINE - unless you have a compelling reason to do otherwise, you're far better off actually planning an appropriate address scheme then cutting everything over at your convenience. This will save you trouble and confusion, especially as you expand in size or capability (VPN between sites or for remote users, providing Internet access, increasing security, etc). Paul - you seem to be framing your response in a specific non-applicable context. A few of your statements are factually correct, but misleading. 1. About routers being intended to work on "small pipes". Sure they have general purpose processors instead of ASICs, but 100Mbs is a "small pipe". Keep in mind that traffic will only go through the router when communicating with another subnet. It's not going to slow down his network in any practical sense unless he designs the system to be asinine. 2. About IP addresses wanting to be hierarchical. True, but irrelevant in this context. He's not using RIP and he's not engineering an enterprise architecture. He'd be using CIDR and could achieve all the same effects with a set of screwy ranges. There might be a few more entries since he doesn't get the benefit of route summarization, but we're talking about a very small setup, with probably only 1 router. 3. OP never brought up NAT or "remapping" - you did. He wanted to communicate between nodes on different IP address ranges - that's what a router does. Edited 14 Dec 2008 by Nathan

[ian s 0]

Hi Paul & Nathan Thanks for your replies, sorry for the delay responding to your posts. It would never be my intentention to connect this system to the Internet or company Intranet but who can say what will happen. Interpanel comms would be even further from my mind but I suppose more likely once the network is in place. Any way it seems that although my plan would work it is an overcomplicated solution (which I suppose I already knew). The more acceptable solution of realigning the IP adresses of all the panels has now become "Plan A". The largest of our panels has 7 network nodes in the 192.168.1.x range so I will sit down and workout a plan based its structure to apply to all the plant. I will no doubt be back for more advice on this later. thanks ian

[kaiser_will 65]

Paul and Nathan address excellent points about control systems and Ethernet/IP. I, as well as most of us, have lived through this hell over and over. Engineering managers and IT managers calling the shots that need to done on a system design level with controls engineers. I highly suggest you use this opportunity to start developing an Controls System Ethernet/IP standard from the basics first and growing from there. I have found that IT is open as long as engineering has their control network and does not interfere with the company business network (i.e., bridge the networks at only one point and let IT manage traffic between them). It you can get that agreed to, then the control network is your baby (or engineering's baby) and life should be good. Tough it up right now and start re-addressing machines fitting in with the business plan to minimize the impact on production and keeping risks low. If you have a system that is way too high risk to re-address, then capture its MAC addresses and build into a switch or router table. I personally think adding routers everywhere is a horribly bad idea for long-term. Your solution should be flexible, solid, adaptable to hardware failure (i.e., if a routing device [switch] fails, anything you can get in a hurry will work). Look at performing a FMEA (Failure Mode Emergency Analysis) on your control network access. I found that it is very important for electricians to get quick access via the control network to a process and get that process up and running. If that is your case, a reliable and broad control network is a very viable part of your business plan and should be built and managed as such. If you cobble together something to work, you will quickly find out your solution's shortfalls through failures or additional load (more machines or panels). Crap in = crap out.

[paulengr 44]

Addressing some points... Agreed. And that's why I answered with the idea that a 100% switch fabric is the way to go. The goal is to reduce downtime. Fiddling with network settings on a laptop is unplanned downtime. Fiddling with the network configuration on existing equipment is downtime but at least you can do it on a planned schedule. Once done, the network settings on the laptop disappear (no more downtime). A router can band-aid things but eventually (as OP was suggesting eventually tying everything together) it will result in further downtime because the patching will become a hindrance. In the even longer term, you can increase productivity in terms of troubleshooting with an integrated network. This becomes immensely useful not only to be able to troubleshoot anything anywhere anytime (like being on the phone with some tech support guy while remotely monitoring the machine) but also helps in those nasty triage situations where you can fix/abate 1 service call in 30 seconds to a minute while simultaneously continuing progress on another longer term one. To do this though you almost have to straighten out your IP address space at least enough to make it possible to link all your subnets.