|
.Net OPC Solutions
| Sub Category |
Summary |
Client Components
|
A wrapper layer is required for .Net client applications to be able to access OPC servers. Advosol offers such wrapper software components for OPC DA, HDA, A&E and XML-DA clients.
|
Server Development Kits
|
OPC DA servers can be developed with .Net tools. No COM and COM Interop knowledge is required. A device access customization module with a simple interface to the generic OPC server is coded in C# or VB.Net.
This OPC server development approach is specially suited for servers that front-end a data base or have TCP/IP or serial communication to the device. |
Servers and Tools
|
The products in this category are for end user. Most other Advosol products are components and toolkits for the software developer. |
Please select a subcategory above
| .Net OPC Solutions
OPC is based on the Windows OLE/DCOM technology and has brought standardization to thousands of applications. Now most new applications are developed on the .NET base and require support for the OPC standard in .NET, including COM interop, web services and access to existing COM based OPC solutions.
Advosol offers the most complete set of .NET components and tools for the software developer and system builder. 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.
|
 |
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.
| |
DA V2 / V3 |
A & E |
HDA |
XML DA |
|
Client Components |
|
|
|
|
|
Server Tools |
|
|
|
|
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 an OPC standard compliant generic COM server and a .NET wrapper that allows the application specific server functionaly to be implemented with VB.Net/C# as a .NET assembly.
| OPC DA .NET Server Toolkit |
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 Customizable server. No further effort is required to support the new OPC XML-DA standard. |
| OPC Historian .NET Server Toolkit |
The HDANSrv includes full source code of compliance tested sample servers.
OPC HDA servers can be implemented in C# or VB.Net. | |
How to develop OPC DA Servers today?
|
If you have to develop a new OPC server today then you have to make a basic decision: Should the development be done on the legacy DCOM technology or the current .NET and XML Web Services base?
Because there are thousands of OPC DA applications but yet only a few OPC web service applications you may have to decide for an OPC DA DCOM server, well knowing that you invest into a legacy technology and soon will have to invest again to support 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 or XML DA server.
As it is common in OPC server toolkits, the Advosol server toolkits implement the OPC specification in a generic server part and the user only has to supply a .Net assembly with the device access functions. 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 OPC clients for access to OPC-DA 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. | |
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 5 times faster on a top end PC. Interesting is mainly 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