Emerson Exchange 365

EIOC Redundant

I have a project using a redundant EIOC to run an MCC over Ethernet / IP. The EIOC will directly control the devices on the network (PF525 and E300). What would be the best practice for having this network's high availability. We are using the redundant EIOC. One option would be to set up a network redundancy and use a RedBox Switch; however, the Switch would become my network bottleneck. How to get around this situation? What solutions have been adopted for this situation?
It is possible to mount a ring with two redBox switches. One from Lan A and one from Lan B?

Thanks.

• EIOC

Elton Souto

• 9 Mar 2020 9:24 PM
• Cancel

5 Replies

• RickV

  

  • 10 Mar 2020 12:05 PM

  Since you are already using Rockwell Drives and E300 Smart Overloads you can look at using Stratix Managed Industrial Ethernet Switches.

  • Cancel
• pmhamilton

  

  • 10 Mar 2020 12:51 PM

  The EIOC failover time for EtherNet/IP IO is 1900-4000ms as per Fig 5.6 and Table 5.8.
  
  "If the EIOC is using either of the supported EtherNet/IP protocols for control, devices must be configured to delay going into fail-safe state after detecting a communication loss. The delay time must be greater than the switchover time for the EIOC. Otherwise, devices will go into the fail-safe state whenever control passes from one EIOC to the other in the redundant pair"
  
  www.scalloncontrols.com/.../Planning-and-Designing-Your-DeltaV-Digital-Automation-Systems-and-DeltaV-SIS-Process-Safety-Systems-2015.pdf
  
  Since the EIOC does not support the EtherNet/IP Device Level Ring, DLR, protocol, you must have a valid way for EIOC to enter the DLR ring. The picture you drew can be obtained where the pair of "Red Box" is a pair of "E-TAP". The key concept here... EIOC is two, simplex EtherNet/IP scanners with identical scanlist... and DeltaV is just switching off one and switching on the other. EIOC-A is using E-TAP-A... EIOC-B is using E-TAP-B. So there is no media redundancy between the EIOC-A and the E-TAP-A (or EIOC-B and the E-TAP-B), However, you do have EIOC-A and EIOC-B independently connected to the DLR. All EIOC-A traffic will be via E-TAP-A and all EIOC-B traffic will be via E-TAP-B. The bigger question is how to handle the switchover between EIOC-A/B?
  
  I suspect the switchover time is how long it takes to stop EIOC-A, start EIOC-B, clear out the stale data, get new data, send new data to the controller. It doesn't address the failure detection. For example: If E-TAP-A loses power, then EIOC-A is disconnected from the DLR. Would that cause a failover? Since the E-TAP already lost power, didn't the motors already go to the fail-safe state? How long before the EIOC detects this and starts to react? What the difference between turning off the power to one motor (e.g. lock-out, tag-out)... and thus losing comms to that one motor... and losing comms to all motors? Maybe losing comms doesn't cause a failover? What conditions would cause and automatic failover?

  • Cancel
• BRENT DREISBACH

  

  • 17 Mar 2020 5:29 PM

  Elton,

  Currently the only network redundancy supported by the EIOC is PRP (Parallel Redundancy Protocol).  When this option is chosen, identical messages are sent out both the A and B ports.  Both messages are received by the end devices and one of the messages is discarded. In order to do this the EIOC requires that the A and B ports be on different subnets. The end device must be PRP aware, with connections on both A & B subnets. Neither the E300 or PowerFlex are PRP aware so you will not be able to use the current EIOC network redundancy with these devices. 

  

  You can set up a ring network, but it will still only operate from the EIOC's Port A.  The Port B will be on a different subnet and therefore unable to communicate with your devices.  If you have a small number of devices you could add a Redbox to each one to make it PRP aware. This become complex and cost prohibitive if you have a large number of devices.

  We currently have an active, large project with hundreds of E300s, Powerflexes and other devices.  We need the same type of redundancy that you are looking for - something similar to how network redundancy is handled in the VIMs.  We have an active request with Emerson to add this type of redundancy to the EIOC product. No word yet as to timing of when this capability will be added.

  • Cancel
• Andre Dicaire

  

  • 17 Mar 2020 7:54 PM

  In reply to BRENT DREISBACH:

  The PRP set up lends itself to use PRP enabled switches and a start network. The PRP switch provides a star connection to the devices. It becomes a single point of failure that affects it's connected devices. You would start with two upper level switches connected to each port on the EIOC. Then use multiple PRP switches that connect to both the A and B PRP networks. Now you can segregate equipment to group equipment to mitigate this failure mode. Critical devices could be connected with Red Box. Ultimately, since the Motor relays and starters do not have redundancy, you have to mitigate this with the topology.
  
  My understanding is that Stratix switches provide a Resilient Ethernet Protocol ring, but they do not support the DLR (Device Level Ring) that you have portrayed. Will a DLR work if it starts on one Stratix switch and ends on another? I'm not sure, but I think it does not. The DLR has to close back on its own switch, or to an E-tap that connects to a single switch, so if you lose this switch, that DLR is also lost. I'm aware of customers that used the Stratix REP in similar fashion to the PRP topology above, connecting groups of motors to a switch to mitigate impact of a switch failure.
  
  The "standard" redundant network support in the EIOC is one of two separate Subnets. This does not work with simple devices as explained above. Since the E300 and other have a single IP address in a single Subnet, they will rebind to a new master in the same subnet (VIM redundancy), but with EIOC (and PK controller), the redundant network is in a different Subnet.
  
  Another approach use the redundant network as two separate buses. you can divide your A and B devices such that loss of one network only impacts those connected devices. You could use an Etap connected to the EIOC primary device port and setup one DLR for bus A, and a second ETap on the Secondary network to communicate to a second DLR for bus B. Each DLR is in a separate Subnet.
  
  Remember that the EIOC itself is redundant. An EIOC failure will switch to the standby and restore communication to all devices. The single points of failure are limited to the E-tap (or switch) and the Communication module in the EIOC.
  A single device failure will open the DLR and remaining devices continue to communication. Not full redundancy, but a significantly reduced likelihood of failure limited to these network components.
  
  For simple devices like motor starters, protection relays and VFD's, the EIOC/PK controller redundant network scheme is problematic with two separate Subnets. The VIM architecture is different. It does not support redundant networks, just redundant Processors. It uses a single subnet and that allows both cards to connect to the same network such as an REP ring. The EIOC has four separate ethernet connections, a Primary and Secondary on each processor. These are connected to the Communication modules to connect to the outside world. Both Primary NIC's connect to the Primary Comm Port module, and both Redundant NIC's connect to the Secondary Comm port module. A Simplex EIOC still has redundant network connections. A Simplex VIM does not. But since the EIOC requires separate subnets, its redundancy network does not fit with the Fault tolerant Ring options like REP.
  
  The PK controller is really where Motors and Drives belong. They are part of the process control strategies and work closely with control loops, sharing status information in interlocks and being controlled under Equipment modules and sequences. In some cases, hardwired signals are desired for critical applications, including shutdown interlocks. VFD's as Final control elements need an AI signal. Best having these on the controller hosting the AI. Native support for PRP on the PK is a requirement. Simple devices should also be considering support for PRP as a redundancy option, in my opinion. I also agree that since the EIOC and PK controllers integrate third party devices and in the case of brown field projects, these need to adapt to the installed topology. Supporting a common subnet for primary and secondary networks is key to successful deployment. I hope Brent is able to get his request through.

  Andre Dicaire

  • Cancel
• pmhamilton

  

  • 18 Mar 2020 4:08 PM

  In reply to Andre Dicaire:

  literature.rockwellautomation.com/.../enet-pp005_-en-e.pdf
  
  The Allen-Bradley Stratix 5400, 5410, 5700 and 5800 all have several options for media and/or network redundancy. Device Level Ring, DLR is a ODVA ring protocol with a very fast recovery. Allen-Bradley says you can have 50 nodes on the ring an a disruption will heal without disrupting a 2ms IO connection. Resilient Ethernet Protocol is a Cisco switch level ring protocol. There are various numbers and factors, but using fiber and a small ring, 250ms would be the lowest possible recovery so REP is generally not used for IO unless the update rates are set quite high. REP is generally used on the information network... not the IO network. Parallel Redundancy Protocol, PRP, provides dual channel for media redundancy. The endpoints must specifically support the protocol but the switches within a channel don't necessarily need to know about PRP. The motor overload and the VFDs do not have PRP. The Stratix 5400 has PRP so it can be the "end-point" AKA "red box". The Stratix switches also have FlexLink and EtherChannel which are both Cisco protocols for link aggregation and redundancy.
  
  As mentioned above, REP is generally not fast enough for IO so we generally don't use REP ring where we have IO traffic. The solution for IO is either DLR ring (between end-devices, or between Stratix switches) or dual star (via FlexLinks) or PRP (mostly used for chassis-based IO). Since the EIOC does not have DLR, you can use the ETAP as I described in the previous post. Since the motor overload and the VFD both have dual ports, it is possible to set up a stacked switch and create a dual star by configuring FlexLink on the Stratix stack to each motor overload and VFD. Since the motor overload and VFD do not naively support PRP, you would need a "red box" solution.
  
  The more equipment you add, the more points of failure. I think the DLR solution (using ETAPs) on EIOC is a decent solutions because the the cost is low and you are not adding a lot of hardware.

  • Cancel