White Paper .NET OPC Servers

.NET is the choice platform for most client applications and it’s also a good choice for the development of OPC servers.

Server toolkits isolate the OPC specified COM interface and application independent server functionality into a generic server part. The toolkit user only has to implement the application specific server functionality. In .NET server toolkits the generic server part includes a .NET wrapper, allowing the user to implement the application specific server part in .NET, either C# or VB.NET.

Server Toolkit structure

.NET OPC servers need to consist of two parts:

The generic part with the COM handling and the .NET wrapper
The application part that is coded in a .NET language such as C# or VB.NET

As with traditional Rapid OPC server toolkits, the generic part can either be implemented as a DLL or as an EXE with the application part in a DLL.

The generic part in a DLL may be the obvious choice but the application part in a DLL has many advantages. One important advantage is that the application DLL can be used with different kind of servers:

Server Type	Main Module	Starts:	Runs as:
Out-of-process COM server	EXE	When a client connects	COM server
Windows Service	EXE	At Windows startup or when client connects	Windows service (accessed as COM server)
XML DA web service	DLL	At access from a client	Web Service
XML DA self-hosted WCF	EXE	Started as process	WCF Service or Web Service
OPC Xi, self hosted	EXE	Started as process or Windows Service	WCF Service
OPC Xi, IIS hosted	DLL	At access from a client	Web Service
OPC UA	EXE	Started as process	Process

With the application part of the OPC server in a DLL the same DLL can be used with all type of servers. The generic server is built for the appropriate server type.

Functionality of the Generic Server

The generic server part should implement much of the specification defined behavior to make usage simple. However, it should not restrict the user and prevent the implementation of needed features. These are opposing requirements and toolkit suppliers have to find a suitable compromise. This is especially important in .Net toolkits where application programmers may not have the training to modify the C++ generic server with the rather tricky .Net wrapper code.

How much server functionality can be handled in the generic server part depends on the implemented OPC specification.

The Advosol .NET server toolkits are designed as follows:

OPC Specification	Generic server functionality
DA (Data Access)	The generic server maintains a data cache and handles the client notifications whenever necessary due to value changes or client actions. Basically the application part can simply write new values into the cache. The usage is very simple but still highly flexible. The set of items in the cache may be static or dynamic and the generic server can be configured for optimized handling in applications with either, many items and rather few changes or a lower number of items with a high data change rate.
XML DA	The XML DA specification defines functionality similar to the OPC DA specification. The XML DA server toolkit has a generic part with the same customization DLL interface and can use the same application DLLs as the OPC DA server toolkit.
AE (Alarms & Events)	The OPC AE specification allows the handling of very different kind of events. Not much functionality can be implemented in the generic server without imposing restrictions. The generic server is basically only a .Net wrapper for client calls and OnEvent callbacks.
HDA (Historical Data Access)	The many data selection options defined in the OPC HDA specification may have to be handled in the data base query or in an application specific way. The generic server is therefore basically only a .Net wrapper for client calls and callbacks.
Xi	OPC Xi combines the DA, AE and HDA functionality into a single .NET client interface. The generic server is a pure .NET application, designed to work with the same plug-in DLLs as the toolkits for the classic OPC servers.

OPC Server as part of a complex .NET application

Large applications may have to expose some features as an OPC server. In unmanaged C++ applications it was quite simple to add the OPC server functionality to the application. It’s not so simple in .NET applications or to expose an XML DA web service.

The best solution is to implement the application in two processes, the main application in one and the OPC server in another. The inter-process communication can be implemented with .NET2 Remoting classes or with .NET3 WCF classes (Windows Communication Foundation).

This approach works identically with different application types such as:

Windows Forms
ASP.NET

and different OPC server types:

OPC DA/AE/HDA COM Server
OPC COM Server as Windows Service
XML DA web service
OPC Xi server (WCF)

The OPC server has two interfaces:

The OPC specified interface for client applications
The internal WCF interface to the partner application

WCF Data Exchange Sample Code

The following code shows how a .NET OPC server implementation can be coupled with another .NET application to expose features of this application as an OPC server.

WCF based data exchange is simple to implement and highly flexible. The type of communication is defined in the application configuration file. For on-machine data exchange the high performance "Named Pipe" binding is recommended.

WCF Service Configuration	WCF Client Configuration
<system.serviceModel> <services> <service name="ServerAccess"> <endpoint address="net.pipe://localhost/ServerAccess" binding="netNamedPipeBinding" contract="ServerAccessChn" name="Pipe" /> </service> </services> </system.serviceModel>	<system.serviceModel> <client> <endpoint address="net.pipe://localhost/ServerAccess" binding="netNamedPipeBinding" contract="ServerAccessChn" name="ServerAccess" /> </client> </system.serviceModel>

Interface Definition
The interface is internal between the application and the OPC server implementation and can be defined in any way. The definition is used by the service and client application. It defines the methods the WCF client can call for the data exchange.

using System.ServiceModel;
[ServiceContract]
public interface ServerAccessChn
{
    // method to write an item value into the OPC DA / XML DA server cache
   [OperationContract]
   int SetItemValue(string itemName, object val);
}

Sample Service Class
The service class implements the data exchange interface. In this sample the WCF service is in the OPC Server .NET plug-in DLL.

public class ServerAccess : ServerAccessChn
{
   // method to write an item value into the OPC DA / XML DA server cache
   public int SetItemValue(string itemName, object val)
   {
       ItemDef itm = (ItemDef)AppPlugin.CacheItemIndex[itemName];
       if (itm == null)
          return HRESULTS.OPC_E_INVALIDITEMID;
       else
       {
          try
          {
              object v = Convert.ChangeType(val, AppPlugin.Items[itm.Handle].Value.GetType());
              // write new value into the server cache
              return GenericServer.SetItemValue(itm.Handle, v, (short)OPCQuality.GOOD, DateTime.Now);
          }
          catch
          {
              return HRESULTS.OPC_E_BADTYPE;
          }
      }
   }
}

WCF Service Activation.

The following code is typically in the server plug-in initialization method.

ServiceHost customerServiceHost = new ServiceHost(typeof(ServerAccess));
customerServiceHost.Open();

WCF Client Activation and Usage.

The following code is in the application that wants to exchange data with the OPC server plug-in.

private void Form1_Load(object sender, System.EventArgs e)
{
   // activate the WCF channel to the OPC server
   ChannelFactory<ServerAccessChn> fact = new ChannelFactory<ServerAccessChn>("ServerAccess");
   SrvAcc = fact.CreateChannel();
}

ServerAccessChn  SrvAcc;

private void btnWrite1_Click(object sender, System.EventArgs e)
{
    int rtc = SrvAcc.SetItemValue(cbItemName1.Text, tbItem1.Text);
}