Emerson Exchange 365

Ethernet Fault Tolerance and Redundancy for DCS DeltaV control network

Dear experts DeltaV!
Whitepaper "Ethernet Fault Tolerance and Redundancy" which we can see on Emerson website describes the use of topology with redundant of control network DeltaV to provide higher reliability. However, in my practice, I see the rejection of making a ring topology at the level of regional representation Emerson.
Why do you think the engineering center Emerson refuse to use control systems with redundant ring topology on switches or Moxa или Hirschmann?

• Moxa
• Media Redundancy
• fault tolerance
• Ring

Alex Ey

• 14 Jun 2016 11:26 AM
• Cancel

6 Replies

• Mike Link

  

  • 14 Jun 2016 7:33 PM

  Complexity. In the current DeltaV architecture the switches can be "dumb" devices (granted the DeltaV smart switches provide some pretty cool smart features), they are simple network devices and rarely cause issues. The ring switches you are proposing adds an extra layer of complexity, troubleshooting network problems becomes much more difficult.

  • Cancel
• Alex Ey

  

  • 15 Jun 2016 9:20 AM

  In reply to Mike Link:

  Of course, the use of managed switches require advanced level of knowledge to configure network equipment. However, this is just a one-time costs in the deployment of the system. I think that the redundancy of communication channels at the level of the transmission medium provides a very important advantage.
  
  Consider an example. Damage to the communications channel, such as an optical cable, in a typical Emerson system degrades reliability of the DeltaV network level as will work only one of Primary or Secondary parts. If the owner of the DCS is not able to quickly restore the cable (this may be due to the weather conditions, lack of expertise or materials) any hardware failure in the other parts of the network will lead to a system crash.
  
  Damage ring segment does not degrade the reliability level of the system to hardware failure if use a ring topology Moxa Turbo Ring, RSTP and other.
  
  I also can not agree that the "dumb" devices are less susceptible to network failures. In the old days, it might have been true, but now the unmanaged switches is usually performed on the same hardware components as managed switches. Difference is the presence or absence of end-user access to internal control functions. If you are interested in hardware blogs find about enthusiasts that turned unmanaged switches to managed by making light changes to the electrical circuit.
  
  I asked the engineer Emerson, why they do not use ring topology - answer me discouraged. He said that this is not due to the incompatibility of network interfaces DeltaV, but it gives the ability to quickly detect a failure in the control network. But let opportunities managed switches for detection of failures is also very large, but it does not lose the level of reliability in case of damage the transmission medium.
  
  What do you think about it?

  • Cancel
• AdrianOffield

  

  • 15 Jun 2016 9:35 AM

  In reply to Alex Ey:

  I do believe one of the main reasons for not considering ring topologies is regarding deterministic behavior, with a ring, frames can take an undetermined amount of time to reach the destination, not good for a control system.
  
  I'm sure Andre will provide an in-depth explanation to this question, but here's a link for ref: us.profinet.com/.../

  • Cancel
• Alex Ey

  

  • 16 Jun 2016 7:03 AM

  In reply to AdrianOffield:

  Is there a need for finding solutions "undetermined amount of time" for DeltaV which is very slow system in its architecture?
  Cascade connection between CIOCs provided in the documentation Emerson for electronic marshaling would not it be an example of "undetermined amount of time"?

  • Cancel
• Tyler Anderson

  

  • 16 Jun 2016 12:37 PM

  Mr Alex,
  
  In short, the regional Emerson representation is trying to provide you a SOLUTION that is FULLY supported. When the DeltaV Systems are designed, tested and certified for different things, they have to do so against a solution as opposed to trying for every conceivable option that may exist. How do you test a system with every single switch or network configuration on the market? Who pays to test every network or switch on the market? What size system do you test with every network option?The myriad of different networks that ARE supported in DeltaV go through pretty intense testing and verification that so that Emerson knows that they will work with every part of the DeltaV System. Furthermore, the solutions that are suggested are the ones that are "easy" for most people to implement. For most people the networking and even just configuring a managed switch for spanning tree protocol is not considered "easy", nor would they have any interest in doing so.
  
  If there is a particular reason that a ring-topology is desired for your project you have a couple options:
  
  1) Go ahead and use the ring-topology but understand there are some major caveats. The biggest one being that if you call into the GSC because you have a weird issue with your DeltaV system, they will only be able to help you so far. I can tell you from my travels, that I've seen this type of network installed on a couple different DeltaV systems successfully. I've also seen issues with this solution when people don't understand Spanning Tree Protocol or how it's setup in the switch. In each case of using a ring-topology, each system, at least once, has been brought down because of the ring. Due to either improper setup or there being a failure/glitch which caused multiple switches to start blocking traffic, causing nothing in the system to talk. So I think it's up to you and your company to decide if you are ok with the risks and feel that you have the appropriate people to troubleshoot your own custom solution.
  
  2)I believe you can still hire Emerson for "Advanced Services" with the objective to test a specific solution to work with DeltaV. I've not personally gone this route but know that it's an option. It's my understanding that this option is not cheap and will require you to wait for their findings, which may not be helpful to your specific situation.
  
  So again, the Emerson Representation is just trying to provide you the best SUPPORTED SOLUTION that they have to offer. DeltaV is not just a control system, it's a solution.

  • Cancel
• Alexandre Peixoto

  

  • 20 Jun 2016 9:18 PM

  This is a great topic for discussion and I just decided to add a couple of points here to help clarify some of the doubts shared in this forum:
  
  The whitepaper “Ethernet Fault Tolerance and Redundancy” referenced by Alex Ey was issued in 2007 and therefore completely based on the DeltaV requirements applicable to the system release available at that time, which in summary is: DeltaV M-Series, Microsoft Windows XP and Server 2003.
  
  Electronic Marshalling (CHARMs and CHARM I/O Cards) was not available during that time and therefore the use of unmanaged switches was a common practice since Controllers to I/O communication was 100% handled by the local rail buses.
  
  For the Electronic Marshalling solution, the DeltaV Smart Switches were released to satisfy new DeltaV network requirements, and deliver extra built-in security features (such as: port lockdown). The DeltaV Smart Switches were released based on commercial off the shelf technology, but running custom software and settings defined and managed by Emerson.
  
  With the introduction of Electronic Marshalling and the DeltaV S-Series, additional requirements were embedded into the DeltaV Smart Switches including: storm control, loop prevention, etc. which are basic settings hardcoded to the DeltaV Smart Switches to guarantee proper DeltaV functionality. DeltaV Smart Switches cannot be connected in ring (or loop) since they are configured to prevent such physical deployment, and to Tyler’s point: ring topology is not a supported network topology for DeltaV – only star topologies with DeltaV Smart Switches are. This is basically why the Engineering Centers are not entertaining discussions about ring topologies on a global basis, which matches the global recommendations we share with our local teams.
  
  DeltaV redundancy is validated with the network design in mind. On DeltaV networks the use of the primary and/or secondary links is determined by the embedded node and not the switches, therefore each node can even use both links (primary and secondary) at the same time when it is communicating to multiple nodes, if the embedded nodes deem it necessary. This is an important factor which is also deeply investigated by Emerson during validation of every DeltaV release.
  
  The architecture example provided above in this forum is not supported by Emerson whereas the use of DeltaV Smart Switches, star topologies, and redundancy should be used instead. Please refer to the DeltaV Smart Switches product data sheet for additional information about our current support architectures and products for the DeltaV ACN.
  
  I really hope my comments help to clarify the topics in this forum.
  
  Regards,
  
  Alexandre Peixoto

  • Cancel