Your shopping cart is currently empty.
Server Development Kits
Advosol offers .NET toolkits for the development of OPC DA and OPC 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...
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 Advosol uaPLUS OPC UA Server Toolkit simplifies the transition to OPC UA. The toolkit can use the same C#/VB.NET customization 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
Server Development Kits Category Description
Advosol offers toolkits for the development of OPC servers for the OPC specifications.
- Classic OPC DA
- OPC UA
The servers consist of generic part that handles the OPC client interface and 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) 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.
- 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.