|
Client Components
| Product |
Summary |
Version Info |
| OPCDA.NET |
OPCDA.NET Client Development Component
OPC clients can be developed in .NET without the hassle of COM interoperability. The OPCDA.NET assembly provides .NET classes and methods for for all OPC DA V2/V3 defined functions. Additional helper classes, tools and many samples provide a highly efficient application development environment.
|
|
| OPCHDA.NET |
OPC HDA .NET Client Development Component
OPC historical data access clients can be developed in .NET without the hassle of COM interoperability. The OPCHDA.NET assembly provides classes and methods take advantage of the .NET features and make OPC HDA Server access real simple and also very efficient.
|
|
| OPCAE.NET |
OPC A&E .NET Client Development Component
OPC A&E clients can be developed in .NET without the hassle of COM interoperability. The OPCAE.NET assembly provides classes and methods take advantage of the .NET features and make OPC AE Server access real simple and also very efficient.
|
|
| XMLDA.NET |
.NET One-For-All Client Development Component
XMLDA.NET is a .NET component that handles the access to OPC DA and XML DA servers. The application is coded as an XML DA web client, independent of the type of server to be accessed.
|
|
.Net Applications |
ASP.NET Applications |
WCF Applications |
|
OPC-DA V2/V3 Servers |
yes |
yes |
yes |
|
XML-DA Servers |
yes |
yes |
yes |
Powerful helper classes such as BrowseTree, ListBuilder and DataBind reduce the application code to a minimum. Complex data visualization applications can be implemented in a few lines of VB.Net or C# code.
|
|
How to develop OPC Clients with .NET?
The OPC specifications base on the legacy (D)COM technology. A .NET wrapper is required to enable .NET application access to the OCP specified COM interface. The .NET Framework provides Interop services that handle the wrapping of basic data types. The complex data types used in the OPC interface need to be handled in an additional wrapper layer.
The Advosol OPC Client Components handle all necessary .NET wrapping and provide an easy to use interface with proper .NET data types. Additional classes provide a higher level interface that is even more .NET oriented. These classes encapsulate OPC specifics and error handling to make the development of high quality OPC applications highly efficient.
OPC .NET applications still use the DCOM communication, even if it's hidden by the .NET wrapper and the DCOM configuration is the most problematic part in getting OPC application to work. This issue can only be resolved by a transition from DCOM based OPC designs to web services based on XML DA or OPC UA. Most installed devices have DCOM based OPC DA V2 servers, but the increasingly required remote server access can only be properly implemented with web services. This means that client applications need to be able to access OPC-DA servers and increasingly also act as web service clients.
There are fundamental differences between DCOM and web services, but wrapper layers can hide these differences as long as performance is not a main issue. Wrappers products are available for XML DA and are planned for OPC UA. 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 the different requirements with two OPC DA wrapper products, OPCDA.NET is optimized for OPC-DA server access and XMLDA.NET is optimized for XML-DA but also supports access to OPC DA servers.
See OPC-DA / XML-DA Comparison for an overview and comparison of the two OPC specifications.
OPC UA is not included in the comparison because, on one hand it's not yet fully specified and on the other hand it's designed in a general way to cover every need. In a feature comparison table OPC UA looks therefore perfect. However, it comes at the price of high product complexity. Especially for client applications OPC UA is much more complex than OPC DA or XML DA. The success of OPC UA will depend on how good the products will be able to hide the complexity and offers the features needed in certain types of applications.
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 Wrappers |
 |
Commercial wrapper products that handle all .NET issues are available at low costs. The application can be coded in C# or VB .Net. Since there is no OPC specification for a .NET interface, each wrapper product offers a different application interface, either modeled after the OPC DA interface, or much different.
Advosol's OPCDA.NET client component is a .NET wrapper with a layered structure. The base layer has a method for each specified OPC DA function and offers top performance. Higher layers offer methods for simplified use. Included are also wizards, tools and context sensitive help to simplify and quicken the application development.
Advosol also offers the OPCAE.NET and OPCHDA.NET client components for the access of OPC Alarms&Events respectively OPC Historian servers. The Advosol OPC client components can be used in a single application in any combination.
64-bit operation is an increasingly important issue. The Advosol .NET wrappers support 64-bit operation mode.
The 64-bit capability is important because .NET applications are by default compiled to run in 64-bit mode on 64-bit systems. To prevent crashes on 64-bit systems the applications must either use a 64-bit capable OPC .NET wrapper or the application must be compiled to only run in 32-bit mode.
|
|
Web Services
|
If performance is not paramount then a more complex wrapper can be used. The client application can be implemented as an OPC XML-DA client and as such can efficiently access XML-DA servers. Such a client can access OPC DA servers in two ways:
|
XML-DA to OPC-DA Gateway
|
The OPC XML-DA client accesses the OPC-DA server through an XML-DA gateway server, which is installed at the location of the OPC-DA. The remote access is web service based and DCOM issues are eliminated. The Advosol gateway products are .NET3 capable and can use either a high performance TCP or a regular or secure HTTP connection
When an XML-DA server gets available the client can access it directly, eliminating the need for the gateway server.
|
|
XMLDA.NET Wrapper
|
XMLDA.NET is a .Net assembly DLL with the same interface as an XML-DA IIS Web Service stub. It is transparent for XML DA server calls and wraps the client calls to OPC DA server calls without going through XML serialization, achieving high performance, especially with the OPC server on the same computer.
XMLDA.NET is well suited for ASP.NET web applications that are installed on the same computer as the OPC server and accessed from remote browsers.
An XMLDA.NET based client application can access multiple OPC-DA and OPC XML-DA servers by specifying either a COM server ProgId or a web service URL.
On .NET3 systems the XML DA communication can be configured for basicHTTP to access .NET2 web services or any available binding for the access to .NET3 hosted XML DA servers. | |
|
