Emerson Exchange 365

OPC Tunneling with Redundant DeltaV OPC DA Servers

I'm evaluating methods of implementing OPC communication between DeltaV 14.3.1 and a 3rd party DCS and ensuring decent availability against downtime. Additionally I am seriously considering an OPC tunneler to reduce DCOM issues across multiple network segments and increase security. However I am running into some grey areas and any advise would be appreciated. So, for the following:

- DeltaV OPC DA (Server)

- 3rd party OPC DA (Client)

- As of yet to be chosen tunneler (desired local OPC transactions rather than local for better network resistance)

I see 2 main paths forward 

Native DeltaV Redundant OPC Servers

Seems the simplest and most Emerson supported method. 2 Application stations, set and licensed as redundant with automatic failure recover setup. However, it appears a THIRD station is required to have OPCRemote and then Redundant Handler installed. So the OPC servers themselves have higher availability but the Redundant Handler itself is now back to a single point of failure. I believe I would install a tunneler on this third station to access the overall OPC server and then serve it to the network. I see no way around the third station being a single point of failure apart from using ESXI/HyperV with a failover on the VM itself and multiple NICs on the same segment to allow network fail over.

Multiple DeltaV Servers With External Redundancy Manager

Set up 2 app stations as above as OPC servers and handle the redundancy with a 3rd party solution. This again involves a third machine, which would handle the fail over between the two. The main benefit here being that I could source a product that is both an OPC redundancy manager and tunneler in one. Seems to be the same hardware issue as above and would need some way to protect against the third machine from failure. Main benefit here being ease of integration of a tunneler, and potentially more control over the fail over conditions, etc. However I don't know if 2 non-redundant OPC servers load the DeltaV network differently than a native redundant pair.

If there's other reasonable configs for server-client access through OPC tunnels I'm all ears!

• OPC
• DeltaV

tennysog

• 21 Aug 2019 6:39 PM
• Cancel

4 Replies

• Bruno DB

  

  • 21 Aug 2019 9:38 PM

  Both solutions have their pros and cons.
  The biggest disadvantage of the second idea is the extra license cost.
  You will need twice the licenses as with the first solution, because you will pull data from 2 separate Application servers that acts not as a pair.
  
  I think the best idea for you is to look into OPC Mirror.
  It can be installed on the pair of redundant Application stations and you eliminate the use of the opc tunneler.
  
  Don't forgot that Most DCS systems are server and not client.
  Depending on your other DCS you need this kind of solution between both servers.
  
  
  Some more information:
  www.emerson.com/.../product-data-sheet-opc-mirror-redundancy-deltav-en-56210.pdf
  www.emerson.com/.../product-data-sheet-opc-mirror-deltav-en-56208.pdf
  
  From v14 you could use OPC UA to make the connection between both, but i have no idea if this can be redundant.
  www.emerson.com/.../product-data-sheet-deltav-opc-ua-servers-clients-en-3583458.pdf

  • Cancel
• tennysog

  

  • 21 Aug 2019 10:44 PM

  In reply to Bruno DB:

  Unless I’ve been misreading BoL as long as DeltaV is acting as a server not a client there should be no per point licensing for modules with OPC parameters updated by an external client.
  
  The 3rd party DCS is 800XA which can act as an OPC DA client so I shouldn’t need a mirror or bridge solution to do Server to Server OPC handling. Currently avoiding UA solutions due to legacy equipment onsite that might have to play nice in the future as well.
  
  The main reason I’m looking to use a tunnel is to make the connection more secure, reduce DCOM woes, and help limit the ability of user securities overlapping between systems.

  • Cancel
• tennysog

  

  • 27 Aug 2019 2:18 PM

  A quick add-on to the original question that I've been trying to work out separate. I will be working in a virtual DeltaV environment. Is there a large functional difference between a single OPC APP station with an automatic failover in the virtual studio vs. a configured redundant paired OPC APP station?
  
  I haven't found a ton of documentation, but my immediate reaction is that the failover solution will have a short (1-4 minute) comms loss on failover to the standby virtual machine, whereas a true redundant pair will have no comm failure when the primary node goes down. Is that the expected behavior in those two configurations?

  • Cancel
• Youssef.El-Bahtimy

  

  • 28 Aug 2019 10:39 AM

  In reply to tennysog:

  I usually avoid tunneling as I can almost always overcome the cross system issues , but you make a strong case for why it should be utilized regardless (i.e. security of both the systems and the data) despite the additional cost and complexity.
  Regarding architecture, if your OPC client supports redundant operation, then you can install that client on a pair of nodes, both of which would need the the deltav redundancy handler to facilitate resolution of opc server name to actual hostnames. Typically, it's easiest to install the client on the server especially if you need bridging between two opc server systems, but then which system becomes the conundrum.
  I agree with other posts that a redundant bridging client is your best bet, but OPC mirror is very limited in terms of features and more costly compared to other products.
  You are correct in stating that VM redundancy is not a replacement for application redundancy, and if cost is any issue that application redundancy on two VMs is superior to VM replication redundancy on one server, but otherwise just employ both.

  • Cancel