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
