That's very helpful! Thanks for the pointers, no apologies needed.
Happy Thanksgiving,
Chad
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of Michael Toecker
Sent: Tuesday, November 24, 2015 11:32 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Anyone using Cutler Hammer SVX drives with Foxboro?
Apologies.
Basically, I'm trying to say there is some history of VFD controllers have
failed due to excessive traffic on the networks they were attached to, which
can cause the motors they control to stop working. The specific issue is on
page 20-21 of this document:
http://edocs.nps.edu/npspubs/institutional/newsletters/strategic%20insight/2011/SI_v10_I1_Spring_2011.pdf.
In hindsight, this event was a combination of frail VFD controllers, a poor
network design, and common mode failure with a high consequence. The idea is
not to repeat mistakes of the past.
So, when designing an interface via TCP/IP to these controllers you should be
asking the following questions:
1. Are these particular VFDs prone to failing under excessive network traffic?
2. How can I limit the potential exposure of these VFDs to excessive traffic if
they are prone to failure?
3. If, despite my precautions, excessive traffic causes the VFDs on this
network to fail, what are my consequences?
Question #1 is a vendor question, possibly followed up with a proof test.
The proof test would involve sending a ton of directed and broadcast traffic to
the VFDs to assess their susceptibility, similar to how you might over-pressure
a vessel to 120% of the maximum anticipated capacity as proof that it works to
100%. If they are susceptible, can you get a vendor to fix the susceptibility,
such as with a firmware patch? If they aren't susceptible, then you have a
good case to move forward with a simpler design that doesn't address #2 and #3
as strongly.
Question 2 is a design question of what switches to use, where to plug in the
VFDs and FBMs, what IP addresses, subnets, and potentially other controls
(firewalls, ACLs, etc) may be needed to reduce risk. The discussion about the
laptop is a good one, but what controls are in place on the laptop to prevent
it from generating traffic? For instance, I've seen conficker infections at
plants go undetected for years living on systems without anti-virus, and
conficker will generate lots of network traffic.
Your measure of having a separate switch that is hopefully not connected to the
mesh is a good measure, since mesh traffic is a lot of broadcast.
Another good design control would be to select IP addresses that could never
communicate with mesh IP addresses or corporate IP address, just in case the
switch gets plugged in the wrong place at some point. I also know there are
options are managed switches to limit traffic to specific ports, if you decided
to go .
Question 3 is an impact question... What VFDs am I planning to put there, and
what are the consequences if they fail from this event or a similar event? If
it's a VFD for a motor-pump that runs once a week to top off a water tank,
impact is low. If it's a bunch of VFDs all on the same network that run every
primary and secondary feedwater motor-pump, then your impact is high. If the
VFDs are not susceptible to this kind of failure, you're in a better position.
Lastly, I'm not saying "don't do it", cause I'm sure that information and
control from these VFDs is a good feature to have on the system. I'm saying
that there are some questions that should be addressed.
Was that helpful?
Mike
[trim]
_________________________________________________________________________
This mailing list is neither sponsored nor endorsed by Schneider Electric
(formerly The Foxboro Company). Use the info you obtain here at your own
risks. See the disclaimer at www.thecassandraproject.org/disclaimer.html
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
_________________________________________________________________________
This mailing list is neither sponsored nor endorsed by Schneider Electric
(formerly The Foxboro Company). Use the info you obtain here at your own
risks. See the disclaimer at www.thecassandraproject.org/disclaimer.html
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
