OPC .Net client server toolkits for OPC DA, HDA, AE, XML-DA      Advanced
OPC
Solutions    
         OPC .Net client server toolkits for OPC DA, HDA, AE, XML-DA
Online Tools
- OPC Error Lookup
- ASP.NET Sample Clients
- XML DA Sample Servers
Sign In | My Account | Shopping Cart
Search  
   
* privacy and security Guaranteed  
White Paper .NET Wrappers Login  

OPC .NET Wrappers

 

October 2007,  Copyright Advosol Inc.

 

This paper is intended to show how .NET applications can access OPC servers. It explains the required .NET wrappers and additional features built into OPC .NET client components.

 

 

OPC Basics

 

The OPC specifications define component interfaces based on the Microsoft (D)COM technology. (D)COM still is an important part of all Windows operating system versions. Native Windows applications need COM for inter-process communication.

COM was created in 1995 to replace OLE. Distributed COM (DCOM) was added in 1997 as an extension to COM to allow network-based component interaction. Because of DCOM’s roots in older binary and component-based protocols, it fails to deliver the flexibility needed in today's networked environments, is problematic with Firewalls and is cumbersome to deploy and maintain. In 2002 Microsoft introduced .NET with Web Services and .NET Remoting as the base for distributed applications. .NET Remoting provides inter-process communication features and Web services provide interoperability, loosely coupled programming models, and communication based on standards-based protocols such as XML, WSDL, SOAP. The OPC Foundation created the XML DA specification for OPC Data Access applications based on the Web Service technology. .NET3 combines Remoting and Web Services into the Windows Communication Foundation and implements additional web services standards such as WS-Security. Despite these developments still most OPC applications are built on the DCOM based OPC DA specification.

 

 

.NET Wrapper Basics

 

.NET applications can access OPC servers only through a software layer that is usually called a .NET wrapper.

 

.NET wrappers are built on the.NET Framework Interop support for either the COM Custom interface or the COM Automation interface.

 

A .NET wrapper consists of two parts:

·         .NET definitions of the COM server interfaces. For functions with simple type arguments and results .NET handles all necessary conversions.

·         Application specific handling of complex data types. Structures with arrays need to be converted in application specific code.

OPC COM Server

.NET Interop Services

.NET Application

 

.NET Wrapper

OPC COM Server

OPC Automation Interface

.NET Wrapper

.NET Application

.NET Interop Services

 

.NET wrappers based on the COM custom interface are efficient and have no multi-threading limitations.

 

Most OPC Wrapper products are implemented as custom interface wrappers.

The COM Automation interface is more restricted and reduces the number of type conversions that cannot be handled by the .NET Interop classes.
However, the OPC Automation Interface layer is required and this software has proven to be a source of difficulties.

 


.NET Wrapper Functionality

 

There is no OPC specification for a .NET interface and different vendors offer .NET Wrapper software with much different user interfaces and features.

This doesn’t impede product interoperability on server level but it increases the developer training requirements. On the other hand it gives the user the opportunity to choose the best suited application interface and allows the wrapper vendor to add additional features.

Some .NET Wrapper products provide a .NET method for each OPC defined function. Others provide a high level interface that hides OPC details such as e.g. callback handler.
The Advosol OPCDA.NET wrapper has a layered structure and allows the user to choose the best suited interface.

The Advosol XMLDA.NET wrapper for example supports access to OPC DA and XML DA servers.

 

 

 

 

 

.NET Wrappers in 64-bit Mode

 

Structures have a different alignment in 32-bit mode and 64 bite mode. The .NET Interop layer doesn’t always transform structures correctly. The OPC .NET wrapper must convert the structures depending on the 32/64-bit working mode.

Visual Studio 2005 by default compiles applications ‘for Any CPU’. These applications execute either in 32-bit or 64-bit mode, depending on the platform. These applications fail on 64-bit systems if the used .NET wrapper is not 64-bit capable. All Advosol .NET wrappers are 64-bit capable.

 

The OPC Core Components proxy DLLs are required in a 64-bit version on 64-bit system. The OPC Foundation Core Components currently don’t provide 64-bit proxys. Advosol provides with its wrappers OPC Core Components with 64-bit proxy DLLs.

 

 

 

 

.NET Wrappers for Vista Certified Applications

 

Vista Certification strives toward higher software quality and reliability. Among the requirements are:

-         All components Authenticode signed

-         No components installed into system folders

 

Currently few OPC applications fulfill the requirements. Few OPC .NET wrapper products are currently available as Authenticode signed components and the OPC Foundation Core Components install into the System32 folder.

 

All Advosol .NET wrapper products are Authenticode signed and the Advosol OPC Core Components install as a regular application with Authenticode signed proxy DLLs.

 

 

 


DCOM Issues

 

The DCOM configuration is the single most difficult and problematic issue in the deployment OPC applications.
It is therefore not surprising that some OPC .NET component products combine the .NET wrappers with features designed to reduce DCOM issues.
DCOM issues can best be reduced by eliminating DCOM network access. This is achieved by moving the OPC COM client to the same computer as the OPC server. Issues such as Firewall settings are eliminated. However, even on the same machine some DCOM access rights configuration is required.

 

To eliminate the DCOM network communication in networked applications another communication mechanism has to be used between the .Net client component and a counterpart component on the OPC server machine.
Possibilities are:

OPC DA Server

DCOM

.NET OPC DA Wrapper

.NET Application

DCOM

(D)COM

XML DA web service communication:

Proprietary Communication protocol:

 

OPC DA Server

(D)COM

.NET XML DA Proxy

XML DA web service

.NET Application

OPC DA Server

(D)COM

.NET Tunnel Proxy

Tunnel Server

.NET Application

 

The OPC XML DA specification defines communication messages based on the SOAP web service standard.
XML DA communication was often considered too slow but with .NET3 the performance can be comparable to a DCOM network communication.

The client application uses the standardized XML DA interface.

Tunneling products usually base on a TCP communication. Other implementations use .NET Remoting that can be configured for different communication protocols.
All implementations are proprietary solutions that require client and server side components from the same vendor.

The client application uses the vendor specific .NET application interface.

 

 

 

 

 


Advosol OPC DA Wrapper Products

 

The Advosol OPCDA.NET client component is available since 2002 and is the most widely used .NET Wrapper component. It is used by over 2000 companies.

OPCDA.NET is a .NET wrapper for the COM custom interface that works in 32-bit and 64-bit operation. In a layered class structure it offers highly efficient as well as easy to use server access.

 

Similar components are offered for OPC Alarms&Events (AE) and OPC Historical Data Access (HDA).

OPCDA.NET

.NET Application

OPC DA Server

(D)COM

DCOM

DCOM

The XMLDA.NET client component is a rather universal OPC Data Access client component.
The client application can use the convenient XML DA interface.
Local or remote OPC DA servers are accessed through the internal .NET Wrapper with the same performance as OPCDA.NET.
For XML DA server access the component is identical to the .NET XML DA proxy stubs. The .NET3 version works with all WCF supported communication bindings such as TCP, HTTP or secure connections.

 

XMLDA.NET

.NET Application

OPC DA Server

(D)COM

XDAGW-SS
 XML DA web service

OPC DA Server

(D)COM

DCOM

DCOM

XML DA Web Service

XMLDA.NET can be used in combination with the XDAGW-SS gateway web service to eliminate DCOM network issues.
The gateway is installed with the OPC DA server and makes the OCP DA server accessible as an XML DA web service.

 

 

 

 


Structure of the Advosol OPCDA.NET Client Component

 

OPCDA.NET offers OPC DA server access methods in a multi-layered class structure and a rich set of tools.


The base layer is a .NET wrapper with .NET methods for all OPC DA defined interfaces and functions.
The Helper classes provide user friendly server access methods for features such as browsing and reading item values. The DataBind class eliminates the need for user data change callback handlers. OPC server items are simple bound to a Windows control such as e.g. a text box or a property of a user defined class.

 

The additional DANVOP product bases on the OPCDA.NET DataBind feature and allows applications to be configured in the Visual Studio Designer without writing code. A rich set of controls is available.

 

 


.NET Client Application

 

.NET API

Wizards
for project creation

Compiler

e.g. Visual Studio


Helper Classes

Structure conversions
and error handling
(.NET Wrapper)

.NET definitions of the
COM server interfaces.

( RCW )

OPC COM Server

Documentation
e.g. as Visual Studio
integrated help

Tools for
configuration and tests

OPC .NET Client Component

.NET Framework
Interop Services

 

 

 

 

 

home | contact us | return policy | privacy policy | security policy | Copyright © 2016 Advosol Inc. All Rights Reserved.