What is an OPC .NET Wrapper ?

An OPC .NET wrapper is a software layer that makes OPC COM servers accessible from a .NET client application.
Largely different pieces of software, that can hardly be compared, fit this description and are rightfully called OPC .NET wrappers. This documents explains the different software layers that are or can be part of an OPC .NET wrapper.

The aim of this document is to give an overview and help determine what kind of wrapper should be chosen in a specific application.

 

 

 

Run-time callable wrapper (RCW)
This layer is required in each OPC .NET wrapper. It does handle the call of a COM server method from a .NET application. This is all it does. Data type conversions and dynamic memory allocations need to be handled outside the RCW.

COM Interop
This layer handles data type conversions and dynamic memory allocation. Strings, variants, arrays etc. need to be converted when passed to the COM server or returned from it. This is the most difficult layer in a .NET wrapper. It is error prone and can introduce memory faults and memory leaks if not done properly. It takes months of development and testing to write such a software layer.

.NET API
The OPC Foundation has not yet standardized the .NET API. Each wrapper product and custom implementation has therefore a different application interface and oriented on different goals:

• Modeled after the OPC DA ( respectively AE or HDA ) specification. 
  Supporting the OPC server functions on-to-one gives highest performance. Having an identical set of functions does not standardize the API. The OPC DA method interface has to be adapted to .NET data types, which can be done in different ways.
  
  
• Optimized for certain applications, such as e.g. ASP applications. 
  Such an API is easier to use, on cost of flexibility.
  
  
• According the XML-DA specification. 
  The XML-DA standard specifies SOAP messages and .NET makes a transformation into method calls. A wrapper with the same API as generated for the XML-DA web services can be used in place of the web service stub. Clients can be developed as XML-DA client applications and still access OPC DA (COM) servers.
  
  
• OPC-DA and XML-DA combination.
  Both types of servers can be accessed through the same API. Since the OPC-DA interface has far more features, the wrapper has to simulate features that are not available in XML-DA. A lot of OPC DA emulation is required when the newer XML-DA type servers are accessed. Typically APIs are optimized for the newest standard and emulation is done to provide compatibility with older standard.

 

Helper Methods
Helper methods can simplify usage. For example the OPC DA 2 browse interface is very basic. Helper methods can make features more convenient to use and e.g. provide a browse interface according the OPC DA 3 specification. Another example are DirectIO read/write methods. OPC DA 3 specifies such easy to use methods. The .NET wrapper can offer such methods also for OPC DA 2 servers.
Helper methods can address features that are not directly related to server access, such as reading item definition arrays from an XML file.

 

 

OPC .NET Wrapper Products

The remarks above illustrate that an OPC .NET wrapper is a rather complex software component that can be implemented differently. A number of vendors offer such implementations. A overview can be found atwww.opcconnect.com/dotnet.php

To select a product the user needs to determine what's important in his applications:

• Type of client applications ( Windows, ASP, ASP.NET, etc. )
• Type of servers to be accessed, now and in the future ( OPC DA, AE, HDA, XML-DA )
• Performance requirements

 

Development Tools
Listed above are components that are required in the wrapper to access the server. 
A good software component should not only provide these features but also good support for the application development process. That includes wizards, documentation and utilities for configuration and test support.

Wizards
Wizards can greatly simplify the project creation process and reduce the training requirements. Wizards can be added to Visual Studio and can create a client application that contains the server access components selected in the wizard dialog. The application development can start on a simple but functional code that contains the needed elements.

Documentation
Extensive documentation is essential for the efficient use of software components. The documentation can be provided as HTML, Windows CHM help file or it can be integrated into Visual Studio for context sensitive help.

Utilities
Utilities provided with the wrapper product eliminate the need to develop such tools as part of the project. Often needed utilities are:

Test Clients	Test clients are are an important reference tools in case of problems with the client application. The test client should use the same .Net wrapper.
Configuration Tools	If clients use a predefined set of items then it's good practice to define these items in an XML configuration file. The wrapper product can supply a helper class to load the XML file and a Windows application to created/modify the XML file.