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  
.Net OPC Solutions - Server Development Kits Login  

Server Development Kits



Product Summary Version Info
OPC DA .NET Server Toolkit



The DANSrv is an OPC DA V2/V3 compliant Rapid Server Toolkit. All required customization is done in a .NET assembly. No COM knowledge is required. The toolkit is easy to use, has high performance and can easily handle ten thousands of items.



 
OPC AE .NET Server Toolkit

The Alarma&Events .NET OPC Server Toolkit is extends the DANSrv OPC DA server toolkit with OPC AE 1.1 functionality.

 
OPC HDA .NET Server Toolkit

OPC Historian .NET Server Toolkit. Provides well structured code of compliance tested sample servers.
OPC HDA servers can be implemented in C# or VB.Net.

 
XML-DA .NET Server Toolkit


The XML-DA .NET Server Toolkit (XDASrv) is a .Net web service with an XML-DA V1.01 compliant generic server and a .Net assembly with the application specific device handler.


 
UA Server Toolkit

The Advosol OPC UA Server Toolkit bases on the OPC Foundation OPC UA SDK V1.1.320 and uses the same customization plug-in .NET assembly as the Advosol OPC DA, XML DA and Xi server toolkits.

 


Category Description

How to develop OPC Servers with .NET ?

OPC DA Server for 32-bit and 64-bit

Advosol offers toolkits and components for the development of OPC servers for all OPC specifications. The application specific server part can be developed as a .Net assembly using C# or Visual Basic .Net. The OPC Client interface is handled in the generic server.
The same customization .NET plug-in assembly can be used with the different toolkits for Classic OPC (DCOM) and the newer Web Services based OPC specifications.
The same customization plug-in assembly can be used with the server running in 32-bit or 64-bit mode.

The OPC specification to choose may be pre-defined or selected in the design phase.

A comprehensive set of converter servers enable client applications to access servers for different OPC specifications.

OPC DA Client and OPC XML DA client access OPC DA Server and OPC XML Server

 

OPC DA/AE/HDA, XML DA and OPC UA and servers with the same customization plug-in

Having a native solution for either COM based OPC DA or web service based OPC DA or web service based XML DA simplifies usage and configuration and offers best performance. However only one type, either OPC DA or XML DA can be installed.

Native OPC DA and XML DA servers

Choosing the best suited OPC specification minimalize the need for converter servers and their configuration. The DCOM server doesn't need any web service features and the OPC UA and XML DA servers are native web services, not using any DCOM features.

The same plug-in .NET assembly can be used with the different servers. The plug-in interface is indepent from the client communication.
With a single server development effort you get native servers for different OPC specifications. The need for converter servers is minimized.

 


 

Which OPC Specification To Choose?

Web Services based OPC specifications are around since 2003 but still most installed and newly developed OPC application use the DCOM based Classic OPC, mostly OPC DA (current data) and less Alarm&Events (AE) and Historical Data Access (HDA). DCOM has communication limitations but is good enough for most applications. For local connections (server and client on the same machine) DCOM offers best performance and tunneling and bridging products are available for situations that DCOM cannot handle or gets too complicated to configure.
The web services based OPC specifications don't have the communication limitations of DCOM but converter servers are likely necessary because most installed OPC applications are Classic OPC.

Often the OPC specification can be chosen based on personal preferences but there are situations that require a specific OPC specification or exclude some as unusable.

  • Remote access thru the Internet or special communication links
    In such an environment Classic OPC can be used only in combination with tunneling solutions that make the communication vendor-specific.
  • More than OPC DA (current data) functionality required
    Application that require OPC AE (Alarms&Events) and/or OPC HDA (Historical Data) functionality cannot use OPC XML DA because the OPC Foundation created a Web Services based specification only for DA functionality. The newer OPC UA specification defines DA, AE, HDA functionality in a single interface specification while classic OPC has three different specifications.
  • Multi-Platform capability required.
    OPC UA is designed for multi-platform use. Classic OPC relies on DCOM that is supported only be Windows. Web services based OPC specifications can be implemented on different platforms but the communication features are limited to the feature set supported on both platforms.

Whatever OPC specification is chosen for an application there probably will be need for converter servers because applications implemented on different specifications need to communicate. Converter server products are available for most combinations. It's good practice to choose the OPC specification so that the need for converters in minimalized. Converters tend to complicate the setup and the configuration because two different communication types are involved.

 

 

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