Network Design - Estimating PLC Traffic

[d-squared]

Has anyone come across any good resources for developing data flow estimates from PLC's, for some given inputs and constraints? We have a network of 34 SLC 5/05s to cover our manufacturing line that will be online in the coming months.

Corporate IT wants to design our pilot implementation of a WonderWare Historian and data collector back to central data center and have challenged us to forecast traffic flows of TCP/IP over switched Ethernet(routed over the WAN, of course).

Any experience in this area that anyone can share is greatly appreciated.

Thanks.

d2

 

[Singapore_Mats]

Industrial pc/plc should (MUST!) have its own network. Then no need to measure the traffic.

 

[d-squared]

Granted, and thanks for the reply. However in this case, the I-net is segmented from the corporate net by VLAN in the switch. What's proposed is to place the data collector (ouch) and the Historian on the corporate net and marry them through a router (WAN).

It seems to me that there's not a lot of concern and thus very little hard numbers on what traffic through PLCs looks like. I realize it's a function in part of the number of tags and the nature of the operation under control, but it seems reasonable that we would have better visibility into the patterns across the I-net.

Thanks.

d2

 

[Alan Case]

Rockwell has this data published somewhere (for the Logix 5000 platform) I will have a look later for it.
Regards Alan Case

 

[d-squared]

Thanks Alan. Appreciate the assist....d2

 

[George Graziano]

Do your best to keep things separate from the IT department (especially Corporate). We had many problems until the last IT guy that would trust our engineering department. They thought they should keep software CD's for everything. If you are running a 24/7 manufacturing location, there Monday through Friday 8-5 just doesn't work. One guy couldn't get it in his head, he couldn't just reboot the server, or start working on a computer running customized software for production.

George

 

[d-squared]

Understood George and thanks. Two different cultures for sure and it doesn't automatically translate well. I guess we're struggling with a common challenge among manufacturers trying to syncopate factory floor systems with corporate IS. Essentially that's what's driving my request for info - I need to communicate engineering imperatives in IS-speak in order to persuade.

Thanks.

d2

 

[wildswing]

Hi d-squared,

I must also ring in with the "keep it separate" encouragement. Our facility had a segregated process lan with a firewall in between US and THEM (the mill lan). Things were good. The ownership changed and IT marched in and said, "We do everything with V-Lans." It was not a good move. We've had issues ever since. Now THEY have begun to say things like, "Maybe we should separate the lans physically and put something like a firewall in between."

The issue, as I see it and I'm not anIT guru by a long shot, is the backbone of the switches. If a switch is busy, it affects all the ports. V-lan does nothing to seprate traffic congestion within the switch. Process control needs big, unhindered bandwidth. Buy as much as you can. You WILL use more and more in the future.

When our IT guy sniffs the network, he always comments on how much traffic we create. He says it looks like a 4 lane highway that's always full of traffic, compared to his stuff that happens in spurts.

One day we had something happen on the business lan. It slowed the whole network down. Switches got busy. This slowed the process lan down. Not a good thing. Had we still be separate, we would not have seen an issue.

FYI..we use WW's InSQL as a data historian, collecting process info from our WW DAServers running on Intouch runtime nodes. The InSQL server was on the process lan. Our on-site IT guy's plan was to create rules in the router to only allow our main InSQL server to query the InSQL database.

 

[Peter Nachtwey]

Has anyone come across any good resources for developing data flow estimates from PLC's, for some given inputs and constraints?

No, but we have done testing with the SLC5/05 to see how fast it can generate messages. It is about 1 every 27-28 milliseconds. That isn't very fast so I don't think you will have a problem with 34 SLC5/05s clogging up the net work. I would be more worried about HMIs.

If the SLC5/05s only reply to inquiries then that is still not a problem since the SLCs are slow the 'master' will have to wait a while to get a response. I forget how fast a SLC5/05 can respond to an external response but I have a program that can give you that information
http://www.deltamotion.com/dloads/downloads.php?category=rmc100&subcategory=Examples
Click on the Ethernet Demonstration link. This program is meant to test our controllers but it will test the SLC5/05 too.
I think you will not have a problem until you have many masters or HMIs inquiring data all at once.

 

[d-squared]

Thanks WildSwing, we will be using InSQL 9.0 and IAS too.

d2

 

[d-squared]

Thanks Peter. Good point about the HMI's...


I appreciate that link.

d2

 

[evilpig]

Insist on keeping it seperate

We just experianced an instance where a software installation on a mill network, of some demo software for some training, used all the bandwith and brought ALL switches that were not isolated by a firewall to a screeching halt. Needless to say our production people were not happy about losing all of their Auxillary programs, but because of network isolation, the machines kept running.

 

[rdrast]

Every machine should be isolated by a decent MANAGED switch, or router. Managed switches/routers can limit bandwidth by port, block unnecessary polling traffic, and isolate external ports if something looks screwey.

Aside: It is virtually impossible to 'Use All Bandwidth' globally on a switched/routed Ethernet network. Collision detection may cause packets to time out, but if you are using TCP, you will get either a timeout, or a long lag time. It is amazingly possible to completely disable the same network by connecting it to itself (puting a patch cord from one port on a switch to another port on the same switch) unless you have Level 3 (Spanning Tree Protocol) switches isolating parts of the network. Level 3 switches/routers with STP allow 'short-circuit' connections, with the drawback of taking slightly longer to evaluate the most efficient port-to-port connections.

NOTE: If your network does NOT have STP, then a simple laptop computer running Windows that has it's physical Ethernet connection 'bridged' to a wireless connection will kill an entire network.

We just experianced an instance where a software installation on a mill network, of some demo software for some training, used all the bandwith and brought ALL switches that were not isolated by a firewall to a screeching halt. Needless to say our production people were not happy about losing all of their Auxillary programs, but because of network isolation, the machines kept running.

 

[evilpig]

I was just trying to make the point that outside influences can have an effect on Ethernet communications. Our IT people tell me that the switches that they use are managed, and when they did unplug the switch from the rest of the network, the extremely long lag times did disapear.