|
.Net OPC Solutions
| Sub Category |
Summary |
Client Components
|
Advosol offers .NET components for OPC DA, HDA, A&E, XML-DA and OPC UA pc-54-3-easyua-client-sdk.aspxclients. These components provide a set of easy to use .NET classes that handle the OPC server access with the necessary DCOM interop wrapping.
|
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.
|
Servers and Tools
|
Converter servers make classic OPC DCOM applications interoperable with web services based OPC applications.
Test Client and Analyzer tools help with the commissioning of OPC applications and the necessary configurations settings. |
Please select a subcategory above
| .Net OPC Solutions
Before the first OPC specification was published each application needed a set of drivers to be able to communicate with devices from different vendors. The OPC specification simplified the situation dramatically. Server and client applications had to implement only the OPC interface and with this standardized interface the clients can access servers from different vendors.
Classic OPC defines interfaces for DA (Data Access), HDA (Historical Data) and AE (Alarms and Events) based on the Microsoft DCOM technology.
With the appearance of .NET and web services based communication the situation became more complicated. Instead of a single OPC interface there are now:
- .NET wrappers for classic OPC (with vendor specific application interfaces).
- The XML DA specification with .NET 2 based web service communication
- The OPC UA multi-platform specification with UA specific communication
- The OPC .NET (Xi) specification with WCF (Windows Communication Foundation) based communication
The vast majority of installed applications are still classic OPC DA but increasingly applications are implemented on the newer OPC specifications. Clients more and more often need to access different types of OPC servers. This can be achieved either with converter servers or multi-specification client development components.
Advosol offers multi-specification client development components and a range of converter servers.
OPC .NET Product Overview
Advosol Inc. offers the most complete .NET support with .Net Wrappers for the OPC client development, Server Toolkits with .Net customization module and OPC-XML gateways.
We have decades of experience developing and selling software components and know what it takes to for the user to achieve maximum cost savings:
- Robust, full featured, efficiently coded and well tested software
- Comprehensive documentation, guides and samples
- Tools for development, testing and deployment
- Support for the component usage and it's interaction with other components
All our products are OPC compliance tested and include tools, wizards, samples, documentation and free support.
|
With multiple OPC specification in use it's unavoidable that client and server happen to be implemented on different specifications and need to communicate thru a converter server.
The converter may be a separately installed server or may be built into the client application as part of an OPC interface module. Built-in converters have the advantage that there is only one type of external communication.
|
Advosol offers software components and tools that makes the combination of OPC and .NET real simple.
| .Net OPC Clients |
The client development components allow .Net client applications to access OPC servers. These software packages are much more than simple .Net wrapper. They provide everything needed for efficient application development. All OPC defined functions can be called through easy to use classes with all data properly converted. Additional software layers offer a number of higher level functions like browsing the server supported items into a .Net TreeNode structure. Visual Studio project and class generation wizards make usage simple and quick. The Visual Studio integrated help offers context sensitive help.
|
| .Net OPC Servers |
The .NET server toolkits have a generic server that implements the OPC specified client interface and a application specific .NET plug-in assembly that allows the application specific server functionality to be implemented with C# or VB.Net .
|
OPC DA .NET Server Toolkit
OPC AE Option
|
The DANSrv is an OPC DA V2.05 / V3.0 compliant server that can be customized in .Net assembly. OPC servers that e.g. front-end a database or an Ethernet connected device can take advantage of the .Net tools. A simple .Net assembly has to be created, no COM and OPC knowledge is required.
The customization assembly can also be used with the XML-DA, Xi and UA server toolkit. No further effort is required to support the new OPC standards. |
| OPC Historian .NET Server Toolkit |
With the HDANSrv server toolkit OPC HDA servers can be implemented in C# or VB.Net. |
| OPC UA Server Toolkit |
This toolkit implements the OPC UA DA profile. It uses the same application plug-in DLLs as the toolkit for classic OPC DA. |
|
How to develop OPC DA Servers?
|
If you have to develop a new OPC server today then you have to make a basic decision: Should the development be done for classic OPC on the legacy DCOM technology or for the newer .NET and Web Services based specifications?
Because there are still thousands of classic OPC applications you may have to decide for a classic OPC DCOM server, well knowing that you invest into a legacy technology and will have to invest again to be able to take advantage of the features offered by the new standards.
|
 |
Advosol offers components that actually prevent having to make such a decision. You can develop an OPC server as a .Net assembly using Visual Basic or C# and run it as an OPC DA, XML DA, Xi or UA server.
The Advosol server toolkits implement the OPC client interface in a generic server part and the user only has to supply a .Net plug-in assembly with the device access handling. This .Net assembly doesn't use any COM features, is multi-threaded and doesn't have the limitations of an ActiveX based solution.
How to develop OPC DA Clients today?
The DCOM base of OPC is declared a legacy technology and Microsoft bases new developments on .Net and web services. Developers of OPC client applications follow this trend rather quickly and new OPC clients are likely developed as .Net applications. Most devices installed today however, have DCOM based OPC DA V2 servers. Devices that need to be accessed remotely are likely to have OPC XML-DA servers based on the web services technology.
This means that clients currently mostly access OPC-DA servers but will soon have to be able to access XML-DA servers.
There are fundamental differences between OPC-DA and XML-DA servers, but a wrapper layer can hide these differences as long as performance is not an issue. To achieve high performance the wrapper layer has to be minimized and therefore the client has to be designed to match the structure of the server. Advosol supports these requirements with two OPC DA wrapper products, OPCDA.NET is optimized for OPC-DA server access and XMLDA.NET is optimized for XML-DA.
See OPC-DA / XML-DA Comparison for an overview and comparison of the two OPC specifications.
There are different ways to develop .Net client applications for access to classic (DCOM based) OPC servers:
.Net Interop Services |
Microsoft provides COM Interop Services in the .Net Framework that allow a .Net application to access COM servers.
Best documented is the access to Automation objects. With OPC servers this means that access has to go through the Automation wrapper, resulting in a .Net wrapper on top of the Automation wrapper. The additional layer adds an additional interface that lowers the performance and increases the potential for problems if parts of the software are updated.
To access OPC servers, many type conversions have to be correctly implemented. Be prepared to spend quite some time if you do this the first time.
|
|
.Net Wrapper Product
|
|
Commercial wrapper products that handle all type conversions are available at low costs. They solve the .Net wrapping but are proprietary solutions because there is not yet a OPC .NET API specified.
Advosol's OPCDA.NET is such a wrapper. It is optimized for top performance and offers additional features such as wizards and context sensitive help to simplify and quicken the application development.
OPCDA.NET offers a .Net API that is modeled after the OPC DA interface and offers high performance, faster than the OPC DA Automation interface in a conventional C++ application.
|
|
XML-DA Wrapper
|
If performance is not paramount then a more complex wrapper can be used. The client application can be implemented as an XML-DA client and as such can directly access the soon to be more widely available XML-DA servers.
Such a client can access OPC DA servers in two ways:
|
XML-DA to OPC-DA Gateway
 >
|
The XML-DA client accesses the OPC-DA server through an XML-DA gateway server, which is installed at the location of the OPC-DA.
When an XML-DA server gets available the client can access it directly, eliminating the need for the gateway server.
This is not a highly efficient solution but it supports access to remote OPC DA servers and is readily available for use with any OPC server.
|
|
XMLDA.NET Wrapper
|
XMLDA.NET is a .Net assembly DLL with the same interface as an XML-DA .Net Web Service. It wraps the client calls to OPC DA server calls without going through XML serialization, achieving much better performance. If the client application is implemented as an ASP web application then remote access is possible on application level and the ASP application can be installed at the location of the OPC DA server.
A client application that references the XMLDA.NET assembly in place of an XML-DA web service can access multiple OPC-DA and XML-DA servers by specifying either a COM server ProgId or a web service URL.
To change an XMLDA.NET based client into a pure XML-DA client only the XMLDA.NET assembly reference needs to be replaced by an XML-DA web service reference.
|
|
| OPC .NET (Xi) Wrapper |
The OPC .NET (Express Interface) specification is based on WCF and can be configured for high performance or highly secure communication.
Advosol offers products for different solutions:
|
| OPC UA Proxy |
UA add-on options are available for the classic OPC client components. OPC UA servers can be accessed thru the same API as classic OPC DA/HDA/AE servers. |
Benchmarks
The following benchmark data was measured in a C# .Net Windows Form application.
One item is read from OPC-DA and XML-DA servers using different wrappers and gateways.
The absolute times depend on the computer and could be much faster on a top end PC. Meaningful is the relative performance of the different access methods.
|
|
Client with
OPCDA.NET Wrapper
|
XML-DA Client with XMLDA.NET
|
XML-DA web services client |
| read |
poll |
read / poll |
|
OPC DA Server
|
0.58 ms
|
10 ms |
0.07 ms
|
|
|
local XML-DA Gateway to local OPC DA Server
|
|
45 ms |
<35ms
|
45 ms / 35 ms |
|
local XML-DA Server
|
|
35 ms |
35 ms
|
35 ms |
|
XML-DA Gateway to OPC DA Server
via Internet access from client in USA to server in Europe
|
|
1.2 s |
1.2 s
|
1.2 s |
Notes:
1) OPCDA.NET clients create a group and add items only once and then call the read function repeatedly. XML-DA clients make independent read calls and the wrapper has to create a group and add items for each read call.
2) The large difference between read and poll times for XML-DA clients with XMLDA.NET is because a read connects to the OPC-DA server and reads the values from the server. For subscriptions the OPC-DA callback handler transfers the values into the XMLDA.NET subscription buffers and the poll only has to read the subscription buffer, no COM access is required.
3) The XML-DA server handles poll and read similarly and the processing time is mainly for the XML serialization respectively the Internet communication.
|
.Net OPC Solutions