This technical note describes the options for OPC communications over unsecured networks.

One of the troubles with OPC communications is the difficulty in securing it against external access.  If firewalls are used between the computers, a large number of ports must be opened for proper communications.  These ports do not only expose OPC, they expose all DCOM based components to the external network: this is undesirable.  Normally this is not a problem, as the OPC communciations take place on an secured, isolated LAN.  However, if the network between the OPC client and server is not isolated, then extra security precautions must be taken, especially if the Internet is the only path available between the stations.  The firewalls that are normally used to secure the MiMiC system and the Simulation Control System present large hurdles for OPC communications.  There are two solutions for this problem: OPC Tunnelling or Virtual Private Networking.

OPC Tunneling

Using an OPC Tunneling product for communications is an option, but portions of MiMiC are not currently designed to work with it.  The OPC IO drivers (DeltaV Simulate, DeltaV Simulate SIS, Open OPC, etc.) will work, but the Operator Training system, which depends on OPC as well as Windows File Sharing, usualy will not work properly.  For DeltaV Simulate, OTM needs to have the actual DeltaV Station name in the "Server Machine" field of the IO Definition configuration.  If the tunneling software used requres a different host name for a connection (such as localhost), then the OPC Tunneling product is not compatable with OTM. 

In addition to the OPC Tunnel, the ports used by Windows File Sharing would need to be open on the firewall devices.  This presents its own security risks that may not be desired.  OTM uses the Windows File Sharing services to copy the control system snapshot files from the soft controllers to the MiMiC Station.  This is required so that when the snapshot is restored, the control system can be returned to the correct state. 

The best solution would tunnel both OPC communications and the Windows File Sharing communication, so that both of these protocols would not have to be exposed to an unsecure network.

VPN

Using a virtual private network provides a convenient way to connect MiMiC stations to the control system over an unsecured network.  With a VPN, the number of open ports becomes a non-issue, as all of the network traffic between the MiMiC system and the soft controllers is encrypted while traveling over the unsecured network.  In this setup, the MiMiC system and soft controllers connect as if they were on the same physical network, they are not aware of the VPN tunnel.  With this option, the OPC IO Drivers and OTM should function normally.  The only exception to this would be if the name resolution does not work over the VPN.

Normally the largest problem with the VPN is the name resolution, and it is only a problem for OTM with DeltaV Simulate.  As stated above, the actual hostname of the DeltaV soft controller must be used for OTM to properly take a snapshot of it.  If the broadcast based name resolution (normally available on a standard LAN) does not work, then the hosts files on both the MiMiC system and the DeltaV systems will have to be edited to include a hostname-to-IP address map for all of the hosts invovled.  On Windows, the standard location for this file is "C:\WINDOWS\system32\drivers\etc\hosts".

Conclusion

There are two primary options for OPC communications between MiMiC and the control system: OPC Tunneling and VPN. For the OPC-based IO drivers, either solution will work with MiMiC. The primary problems come from the OTM system. OTM (especially when working with DeltaV Simulate) requires a very specific IO Definition configuration that makes it incompatible with most OPC Tunneling products. In the cases where OTM is required, a VPN is the easiest and most secure option.