Server Development Kits

Advosol offers .NET toolkits for the development of OPC DA, A&E, HDA, XML-DA and UA servers. The toolkits are structured into two parts. The generic server part handles the client interface with the DCOM interop wrapping required for classic OPC servers.
The application specific .NET plug-in DLL handles the 'device' (any data source) access. It is coded in C# or VB.Net as a pure .NET assembly. No DCOM knowledge is required.   read more...
For information, evaluation downloads, quotes, purchase orders or credit card purchases, select the category/product.
The DANSrv is a .NET (C# and VB.NET) server development toolkit for OPC DA V2/V3 compliant servers. All required customization is done in a .NET assembly. No DCOM and little OPC knowledge is required. The toolkit is easy to use, has high performance and can easily handle ten thousands of items.
The Alarms&Events .NET (C# and VB.NET) OPC Server Toolkit is an add-on for the DANSrv OPC DA server toolkit. It adds OPC AE 1.1 functionality.
The OPC Historian .NET Server Toolkit includes well structured code of compliance tested sample servers.
OPC HDA servers can be implemented in C# or VB.Net.
The Advosol OPC UA Server Toolkit simplifies the transition to OPC UA. The toolkit can use the same  C#/VB.NETcustomization plug-in .NET assembly as the Advosol OPC DA/HDA/AE and XML DA server toolkits. Or, UA servers can be implemented with UA node managers
The XML-DA .NET Server Toolkit for C# and VB.NET is a .Net web service with an XML-DA V1.01 compliant generic server and a .Net assembly with the application specific device handler.

Server Development Kits      Category Description

Advosol offers toolkits for the development of OPC servers for all OPC specifications.

  • Classic OPC DA, HDA, AE
  • XML DA
  • OPC UA

The servers consist of generic part that handles the OPC client interface and a an application specific part the handles the devices.
The application specific server part can be developed as a .Net assembly using C# or Visual Basic .Net. The same customization .NET plug-in assembly can be used with the different toolkits for Classic OPC (DCOM), XML DA or OPC UA.
The same customization plug-in assembly can be used with the server running in 32-bit or 64-bit mode.

 

Which OPC Specification To Choose?

The XML DA and UA 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
    • Conversion to XML DA. XML DA converters are simple to configure but offer limited security options and support only OPC DA.
    • Conversion to UPC UA. UA converters can be configured for a wider range of communication requirements but the configuration an understanding of communication security features.
  • Multi-Platform capability required.
    OPC UA is designed for multi-platform use. Classic OPC relies on DCOM that is supported only in 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 implement the OPC specification that minimizes the need for converters. Converters tend to complicate the setup and the configuration because two different communication types are involved.

Loading...