Advance d OPC Solutions

Online Tools - OPC Error Lookup ASP.N ET Sample Clients - XML DA Sample Servers

Sign In | My Account | Shopping Cart Search

HomeProductsServicesDownLoads XMLDA.NET White Paper

Purchase Customer privacy and Resources Company Info Service security Guaranteed Login

XMLDA.NET White Paper

Copyright 2004-07 by Advosol Inc. This paper was written in 2004 and was updated in April 2007 to include the features of XMLDA.NET V4 as well as information about the current operating system environments and the emerging OPC UA specification. The .NET platform required for XML DA is now widely used and OPC server and client applications are being developed on the .NET platform. However, still most applications are built as DCOM based OPC DA server/clients, using .NET wrappers. Despite the many difficulties with DCOM configuration the transition to web services based designs is slow. With most OPC talk being about the announced OPC Unified Architecture you may find it difficult to decide on how to approach new OPC projects. This paper tries to shed some light on the related factors. It focuses on the development of OPC clients and explains different approaches and products. Advosol Inc. started in 2002 with the development of .Net and XML-DA based client and server components and toolkits and offers high quality, matured products. These products will be explained in regards of what they do and why we decided for a particular implementation.

Current OPC Situation

OPC DA (Data Access) is broadly accepted for process data access applications and OPCDA V2 servers are available for almost any equipment. OPC-DA is based on DCOM and this foundation is becoming a legacy technology. Microsoft will keep supporting DCOM

but focuses new developments on web services. .NET3 combines the different Microsoft communication technologies (except DCOM) into one component, the Windows Communication Foundation (WCF). The OPC standard currently most widely used is OPC-DA V2.05. OPC DA V3 offers some additional features but most client applications don't use these in order to be able to work with the many installed OPC DA V2 servers. The OPC AE (Alarms&Events) and OPC HDA (Historical Data) specifications are used to a much less extent than OPC DA. Other OPC specifications such as OPC DX, Commands and Batch are hardly used at all. The XML DA specification defines a data access interface in the form of web service SOAP messages. XML DA is designed to provide the Data Access functionality on a web service base and is the only web services based OPC specification released so far. OPC UA is created as a very general specification that covers all previous OPC specifications and can be implemented with web services communication but also on other communication stacks. The designer of .Net based OPC application has the choice of using OPC DA, XML DA, or wait for OPC UA.

Application Design
New client applications are likely implemented as .NET applications. Since most installed OPC servers are DCOM based OPC DA servers, the client application needs some form of a .NET wrapper in order to be able to access these servers. The .NET wrapper can be implemented in widely different ways:

.NET OPC DA Interface wrapper There is no specification for a OPC DA .Net interface. Different wrapper products provide different user interfaces, either close to the OCP DA specification or quite different based on vendor preferences. The Advosol OPCDA.NET Client Component has a layered structure with the classes that implement the OPC DA interface and helper classes for simplified use. These wrappers support only access to OPC DA servers. The OPC DA interface is not well suited to access XML DA or UA servers. Use this approach if you need to be able to use all OPC DA V2/V3 features. XML DA to OPC DA wrappers Such wrappers enable XML DA clients to access OPC DA servers. Clients can be implemented on the rather simple XML DA interface with only eight methods. The wrapper can be: o Built into the client application The Advosol XMLDA.NET Client Component has the same interface as the .Net XML DA proxies created from the XML DA WSDL file. XML DA servers can be accessed without overhead. For access to OPC DA server the calls are wrapped to OPC DA calls without going through an XML serialization. OPC DA server access is as efficient as with an OPC DA

interface .Net wrapper.

o

A Wrapper XML DA service at the OPC DA server location Clients may access OPC DA servers at a remote location. The wrapper is actually an XML DA service that interfaces an OPC DA server. Any XML DA client can access the OPC DA server through this wrapper. The Advosol XDAGW-SS server-side Gateway is such a wrapper server.

OPC UA to OPC DA wrapper The OPC Foundation is planning an OPC DA wrapper that makes OPC DA servers accessible as an UA server. Since UA clients are rather complex this approach is only advisable if the application actually needs to access UA servers.

Differences between OPC DA, XML DA and OPC UA

OPC DA and XML DA address the same interface functionality but they base on different communication technologies, giving them quite different characteristics that must be understood. OPC UA is designed to handle the sane features and much more. OPC-DA DCOM based OPC UA Defined as an interface that can be accessed as a web service or through an UA specific communication stack. (D)COM is a mechanism XML-DA is based on XML The OPC UA .NET to call procedures in a and SOAP (Simple Object implementation bases on shared server. It defines Access Protocol). SOAP is a .NET3 (WCF) and two interfaces. The low remote procedure call communicates through a level interface is used in mechanism that transfers secure HTTP transport or a the OPC Custom data as XML over HTTP UA specific binary TCP interface and is the communication channels. protocol. preferred choice for C++ Different transports such as OPC UA for .NET3 defines applications. The TCP or secured HTTP can the available web service ActiveX layer is used in be configured if client and methods in a WSDL file. An the OPC Automation server are running on .NET3. additional set of methods are interface and is The SOAP servers defined to manage the implemented as a generic capabilities are described in communiation. wrapper layer. OPC a WSDL (Web Service servers do only Definition Language) implement the custom document. It defines the interface and are accessed supported methods with their from ActiveX arguments and data types as applications through the they are transferred in XML XML-DA Web services based

generic wrapper layer.

form. The methods available to the programmer to implement web services or clients depend on the tools used. This will be further explained below. Web service calls involve XML serialization and possibly slow long distance Internet connections and may be slow. The XML-DA specification accordingly defines few (only 8) rather complex methods to achieve good performance. A call involving 1000 bytes of data is not much slower than on with only 10 bytes. OPC UA uses either a secure (encrypted) HTTP communication with serialized XML data or a UA specific binary protocol over a TCP connection.

(D)COM calls are quite fast, especially InProc and local servers. The OPC-DA specification accordingly defines a large number of relatively simple functions (over 60). Access to remote server through DCOM is slower but still acceptably fast. DCOM uses a binary data transfer that is fast but limited to a local network because it does not pass firewalls well. DCOM works with permanent connections and supports a data callback mechanism that allows the server to transfer unsolicited data.

Web services are connectionless and stateless. Each server call is self contained and independent of previous calls. The exception is only the OPC XML-DA subscription mechanism that allows the client to subscribe to a number of items and then poll these items with the server buffering value changes. Server initiated callbacks are not possible; the client has always to poll the server for new data. XML DA uses the well established SOAP protocol that is supported on

OPC UA uses sessions to define the communication characteristics. Within the session there is a stateless web service access. The session times out if there is no communication.

DCOM is not well suited for communications through firewalls and

OPC UA actually specifies an inner interface layer that is accessed through a

cannot be encrypted. Proprietary tunneling solutions address this issue.

practically all platforms. Inter-platform communication is simple. Using secure communication is simple between .NET3 server/clients is a matter of simple configuration. On other platforms the configuration may be more sophisticated even with .NET3 using only accepted web server extension standards.

communication stack such as the .NET3 web service layer. Clients and servers can only communicate when the implement a compatible communication stack.

OPC-DA and XML-DA Coexistence

The large number of installed OPC-DA servers will have to be accessed for a long time period. Clients are more quickly converted to .Net or new applications developed as .Net desktop or web applications. Wrapper and gateway software is therefore required:

To access OPC -DA servers from a .Net client application To access a remote OPC-DA server as an XML-DA server To access an XML -DA server from an existent OPC-DA client

A server is either implemented as an OPC-DA server or as an XML-DA web service. Sooner or later it will get hard to decide for server developers which one to choose. The Server Toolkits offered by Advosol enable the server developer to develop a customization assembly that can be used with the generic OPC-DA and XML-DA toolkit server. OPC client applications will need to be able to access OPC-DA and XML-DA servers. This can be achieved using:

A client internal .NET wrapper that supports access both types of servers External gateways, either to access XML-DA servers from an OPC-DA client or vice versa. An external gateway located at the OPC-DA servers location is required to make the server accessible from a remote client

Gateway software for XML-DA to OPC-DA or OPC-DA to XML-DA conversion is available from Advosol and other vendors. The gateway products are quite similar; they have to implement a standardized interface on both ends. The differences are in the used base (.Net or other web services tools), configuration options and error handling and reporting features.

OPC Client internal support for both standards can be achieved in two different ways.

Define a .Net interface that is a combination of OPC-DA and XML-DA and wraps the OPC-DA procedure calls to XML-DA. The OPC Foundation has developed such sample code. Use the XML-DA interface and wrap the XML-DA procedure calls to OPC-DA. The client is developed as an XML-DA client but uses a wrapper that can access OPC-DA servers.

We think that the XML-DA interface is a much better approach for the following reasons:

The wrapper layer should be optimized for the new standard and allow the legacy support to be dropped at a later stage without leaving many legacy features in the wrapper and the client application. XML-DA is connectionless and stateless. It is easy to implement that on the DCOM OPC-DA interface by just ignoring the features offered by a permanent connection. It is however rather complex to emulate the OPC-DA connection features on XMLDA. XML-DA has only few rather complex methods. The wrapper can easily implement these methods by calling a number of OPC-DA methods. Implementing the many OPC-DA methods on the few XML-DA function is difficult and likely inefficient.

For these reasons Advosol decided to offer two .Net wrapper products instead of a combined one.

OPCDA.NET is a top performance .Net wrapper for access to OPC-DA servers only. The interface is similar to the OPC-DA custom interface and supports all mandatory and optional functions XMLDA.NET has an XML-DA interface and supports access to OPC-DA and XMLDA servers

Read the page How to develop OPC clients today for more information about different development approaches.

The XMLDA.NET Client Component

XMLDA.NET is a Advosol product that allows OPC clients to be developed as XML-DA clients and access either XML-DA or OPC-DA servers. It offers high performance access to both types of OPC servers and can easily be converted to a pure XML-DA client. Only the assembly reference needs to be changed.

The XMLDA.NET wrapper assembly is used.

The .Net generated XML-DA web service stub is used.

To explain how this is achieved I need to describe how web services are implemented.

Implementation of Web Services

The OPC XML-DA specification defines the services in the WSDL (Web Service Definition Language) document. SOAP and web services tools convert the WSDL specification into objects and methods. Each tool does generate a different set of methods and even web services tools generate different parameter passing definitions. Since all these tools convert from and to the same XML messages this doesnt cause compatibility issues. Only some more work is required if a client or server is ported to another environment. XMLDA.NET is provided in a version for .NET2 and one for .NET3. The .NET3 version can use the BasicHTTP binding for compatibility with .NET2 or servers on other web services platforms. With .NET3 based servers the communication can be configured to use any of the .NET3 supported bindings and transports. The .Net web services tools implement web service handling as follows:

.Net desktop or web application

A stub code assembly is created from the WSDL file. This assembly defines all data types declared in the WSDL file and a method for each declared procedure. The stub code handles the XML serialization to produce the WSDL defined XML messages and to de-serialize the reply.

The SOAP XML messages are transferred over a communication such as HTTP.

The web server de-serializes the SOAP XML messages and calls the XML-DA web service.

The .Net web service tool generates web service skeleton code. The generated methods are identical to the methods created in the client stub code. The server developer has to implement the methods according the functionality defined in the XML-DA specification. The web service is a .Net assembly that is loaded by the web server when a client accesses this web service.

Web service tool generated Stub Code Communication Link ( Internet, ) Web server with SOAP support

XML-DA Web service Web server methods

Since the assembly interface for the client side stub code and the web service are identical, the client application can reference the web service assembly in place of the stub code and access the web service assembly directly, without any XML handling. This is not of much general importance because .Net assemblies cannot be shared. However

XMLDA.NET uses it to embed an XML-DA server with the functionality of an OPC-DA wrapper into the client application.

The XML DA client application references the XMLDA.NET assembly in place of a XML-DA web reference. XMLDA.NET is an XMLDA web service with an embedded XML-DA client and an OPC-DA wrapper. Depending on the URL the client call is forwarded to the specified XML-DA web service or wrapped to OPC-DA server calls.

XMLDA.NET assembly XML-DA Web service XML-DA web server as Multiple OPC-DA and XML-DA servers can be accessed by the client application. OPC-DA Server OPC-DA wrapper Web service stub code

The forwarding of XML-DA service request causes minimal overhead and OPC-DA servers can be accessed without any XML serialization. The OPC-DA wrapper uses handcoded calls to the OPC-DA custom interface for top performance. XML-DA subscriptions create an OPC-DA group and a data change call back handler. Data changes are buffered within the wrapper. The client subscription poll is extremely fast because it only has to read the buffered values within the .Net assembly. No COM calls are necessary at this time.

Helper Classes
XMLDA.NET also offers an additional layer of helper classes that enhance and simplify the

XML-DA interface and make the client development much quicker. These classes are
implemented on top of the XML-DA layer, insuring that the application always can use all XML-DA defined methods if the higher layer does not support a feature required in a particular application.

BrowseTreeThe server is browsed into a TreeNode structure in a single method call. XML-DA defines better browse functions than OPC-DA but still is restricted to browsing a single hierarchy level in one browse call. In Windows Forms application the BrowseTree class displays the branches/items directly in a Windows TreeView control or in a TreeView/ListView combination. ListBuilder The ListBuilder Tool and Class create the request lists needed in XML-DA server calls. The tool creates an XML file and the class loads the definitions from the XML file instead of initializing the data structures within the client code. DataBind Server items can be associated with properties of user classes or Windows controls and the DataBind class handles the update, eliminating the need for user poll or callback handlers. In ASP.NET applications DataBind is used in combination with the ASP.NET DataBind feature. By using DataBind in combination with the ListBuilder, complex applications can be realized with only a few lines of application code. See the product specification for more details.

Sample Windows Application

The simple Windows desktop application shown here displays the current values of three items and updates the displayed values when the server executes a DataChange callback. There is no need for a user callback handler. Only the shown application code is required. A boolean value is displayed in a checkBox, an integer value is shown in a progressBar and an item with an array of doubles value is

displayed in a row of a listView. Either OPC-DA or XML-DA servers can be accessed. Only the server URL needs to be changed.
Dim OpcSrv As XmlServer = Nothing Private Sub btnStart_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) _ Handles btnStart.Click If Not OpcSrv Is Nothing Then Return End If tbStatus.Text = "" ListView1.Items.Clear() ListView1.Items.Add("") ListView1.Items.Add("") Try OpcSrv = New XmlServer(Me.cbOPCServers.Text) Dim sbl As ArrayList = New ArrayList Dim subscr As DataBindSubscription() ReDim subscr(2) subscr(0) = New DataBindSubscription("SimulatedData.Signal", Me.CheckBox1) subscr(1) = New DataBindSubscription("SimulatedData.Ramp", Me.ProgressBar1) subscr(2) = New DataBindSubscription("Dynamic.Analog Types.Double[]", _ Me.ListView1.Items(1).SubItems) Dim err As OPCError() OpcSrv.DataBindSubscribe(Me, subscr, 1000, Nothing, err) tbStatus.Text = "Started" Catch ex As Exception tbStatus.Text = ex.Message OpcSrv = Nothing End Try End Sub Private Sub btnDisconnect_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnStop.Click If Not OpcSrv Is Nothing Then Dim err As OPCError() OpcSrv.DataBindCancel(Nothing, Nothing, err) OpcSrv = Nothing tbStatus.Text = "Stopped" End If End Sub

Help Documentation, Wizards and Samples

XMLDA.NET comes with Help2 documentation that plugs into Visual Studios help system and provides context sensitive help. Visual Studio project and class templates create an XML-DA client project with small functional sample code or add a class with XML-DA client functionality to an existing application. A number of VB and C# desktop client applications and ASP.NET web applications are provided. These range from very simple applications to samples that use all XML-DA defined methods and can be used to get a better understanding or as the base for a user application.

XMLDA.NET in ASP.NET applications

XMLDA.NET is well suited for use in ASP.NET web applications for the following reasons:

ASP.NET applications are .Net applications that require some wrapper layer to be able to access OPC-DA servers. XMLDA.NET is such a wrapper and it has an integrated buffer for data changes. This is important because ASP.NET applications can only be polled from the user. Callbacks to the user browser from the server side are not possible. The ASP.NET application can be used from a browser on a user computer located anywhere. The ASP.NET application can therefore be installed on a web server that is networked with the OPC-DA servers. The OPC-DA servers can be accessed locally through the XMLDA.NET internal wrapper without XML serialization. Desktop client application to the contrary run on the user computer and can access remote OPC-DA servers only through an XML-DA gateway located at the OPC-DA server. Access to remote OPC-DA servers is possible by having an XML-DA gateway at the OPC-DA servers location. It is accessed from the ASP.NET client application as an XML-DA server. XML-DA servers, when such become available, can be accessed without a wrapper layer. The XMLDA.NET DataBind subscriptions can be used in combination with the ASP.NET DataBind feature.

Sample ASP.NET Application

The simple ASP.NET application creates DataBind subscriptions according the definitions in an XML file. The page is periodically refreshed and uses the ASP.NET DataBind feature to display new item values.

<%@ <%@ <%@ <%@

Page language="c#" AutoEventWireup="true" %> Import Namespace="System.Net" %> Import Namespace="xmldanet" %> Import Namespace="xmldanet.xmlda" %>

<%@ Register TagPrefix="xmldanet" Namespace="xmldanet" Assembly="XmlDANet" %> <script runat="server" lang="c#"> //static string OpcURL = "http://localhost/OpcXmlGateway/OpcDaGateway.asmx" ; static string OpcURL = "OCSTK.DA.Sim.32" ; static XmlServer OpcSrv ; private void Page_Load(object sender, System.EventArgs e) { if( ! IsPostBack ) { chkStopped.Checked = false ; OpcSrv = new XmlServer( OpcURL ); OPCError[] err ; DataBindSubscription[] subscr ; OpcSrv.DataBindFromXmlFile( this, "AspDemo1.xml", "Demo1", null, 1000, null, out subscr, out err ); } if( OpcSrv == null ) chkStopped.Checked = true ; DataBind(); } //-----------------------------------------------------// method used in DataBind definitons private object GetOpcItemValue( string SubscrID ) { if( OpcSrv == null ) return "" ; return OpcSrv.GetBindValue( SubscrID ); } //-----------------------------------------------------private void btnRefresh_Click(object sender, System.EventArgs e) { // only postback handling is required } //----------------------------------------------------private void chkStopped_CheckedChanged(object sender, System.EventArgs e) { if( OpcSrv != null ) { OPCError[] err ; OpcSrv.DataBindCancel( null, null, out err ); OpcSrv = null ; } } </script> <HTML> <HEAD> <title>XMLDA.NET Demo</title> <meta content="Microsoft Visual Studio .NET 7.1" name="GENERATOR"> <meta content="C#" name="CODE_LANGUAGE"> <meta content="JavaScript" name="vs_defaultClientScript"> <meta content="http://schemas.microsoft.com/intellisense/ie5" name="vs_targetSchema"> <script language="javascript" id="clientEventHandlersJS"> <!-var timer; function window_onload() { timer = window.setInterval ("refresh()", 1000 ); } function refresh() { if( Form1.chkStopped.checked ) window.clearInterval(timer); else Form1.btnRefresh.click(); } --> </script> </HEAD> <body MS_POSITIONING="GridLayout" language="javascript" onload="return window_onload()"> <form id="Form1" method="post" runat="server">

<asp:button id="btnRefresh" style="Z-INDEX: 101; LEFT: 144px; POSITION: absolute; TOP: 184px" runat="server" Height="32px" Width="96px" Text=" " BackColor="White" BorderColor="White" BorderStyle="None" OnClick="btnRefresh_Click"></asp:button> <asp:CheckBox id="chkStopped" style="Z-INDEX: 111; LEFT: 24px; POSITION: absolute; TOP: 184px" runat="server" Text="Stopped" Width="104px" Height="24px" AutoPostBack="True" OnCheckedChanged="chkStopped_CheckedChanged"></asp:CheckBox> <asp:Label id="Label10" style="Z-INDEX: 110; LEFT: 304px; POSITION: absolute; TOP: 192px" runat="server" Width="120px" Height="24px"> <font face="Verdana" size="2">IntArr[]</font></asp:Label> <asp:Label id="Label9" style="Z-INDEX: 109; LEFT: 200px; POSITION: absolute; TOP: 136px" runat="server" Width="120px" Height="24px"> <font face="Verdana" size="2">Random</font></asp:Label> <asp:Label id="Label8" style="Z-INDEX: 108; LEFT: 200px; POSITION: absolute; TOP: 104px" runat="server" Width="120px" Height="24px"> <font face="Verdana" size="2">Step</font></asp:Label><asp:textbox id=tbRandom style="Z-INDEX: 104; LEFT: 24px; POSITION: absolute; TOP: 136px" runat="server" Height="24px" Width="168px" Text='<%# GetOpcItemValue("Random") %>'></asp:textbox> <asp:textbox id=tbRamp style="Z-INDEX: 103; LEFT: 24px; POSITION: absolute; TOP: 64px" runat="server" Height="24px" Width="168px" Text='<%# GetOpcItemValue("Ramp") %>'></asp:textbox> <asp:textbox id=tbStep style="Z-INDEX: 102; LEFT: 24px; POSITION: absolute; TOP: 96px" runat="server" Height="24px" Width="168px" Text='<%# GetOpcItemValue("Step") %>'></asp:textbox> <asp:ListBox id=ListBox1 style="Z-INDEX: 105; LEFT: 296px; POSITION: absolute; TOP: 64px" runat="server" Height="129px" Width="177px" DataSource='<%# GetOpcItemValue("IntArr") %>'> </asp:ListBox> <asp:Label id="Label6" style="Z-INDEX: 106; LEFT: 24px; POSITION: absolute; TOP: 16px" runat="server" Width="392px" Height="48px"> <font face="Verdana" size="4">XMLDA.NET DataBind Sample</font></asp:Label> <asp:Label id="Label7" style="Z-INDEX: 107; LEFT: 200px; POSITION: absolute; TOP: 72px" runat="server" Width="120px" Height="24px"> <font face="Verdana" size="2">Ramp</font></asp:Label> </form> </body> </HTML>

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 read XML-DA Client with XMLDA.NET read poll XML-DA web services client read poll

OPC-DA Server XML-DA Gateway to local OPC-DA Server local XML-DA Server

0.58

10 ms 45 ms 35 ms

0.07 ms 35ms 35 ms 45 ms 35 ms 35 ms 35 ms 1.2 s

XML-DA Gateway to OPC-DAServer via Internet access from client in USA to 1.2 s 1.2 s 1.2 s server in Europe 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.

Additional related Advosol Products

OPCDA.NET high performance wrapper for access to OPC-DA servers from .Net client applications OPCAE.NET high performance wrapper for access to OPC A&E servers from .Net client applications OPCHDA.NET high performance wrapper for access to OPC HDA servers from .Net client applications XDAGW-SS Gateway for access to OPC-DA servers from XML-DA clients XDAGW-CS Gateway for access to XML-DA servers from OPC-DA clients DANSrv OPC-DA server toolkit with application customization plug-in as a .Net assembly XDASrv XML DA Server Toolkit that is customized with the same .Net plug-in assembly as the DANSrv OPC DA toolkit server..

home | contact us | return policy | privacy policy | security policy | Copyright 2012 Advosol Inc. All Rights Reserved.