Table of Contents

[an error occurred while processing this directive]

1. Executive Overview
With all the publicity surrounding OPC for industrial application connectivity, XML web services and Microsoft’s .NET technology, it is easy to believe that the three will be synonymous in the future, and that DCOM will quickly fade away. This is partially true. XML web services are an excellent alternative to DCOM for Business applications. Nevertheless, due to its real-time nature, Microsoft’s DCOM will continue to dominate the Operations application market for the foreseeable future. This paper discusses the benefits and limitations of XML web services as an alternative to DCOM for industrial applications.

Finally, it positions XML web services and DCOM for their proper usage.

2. XML and Business applications

2.1 Overview
XML web services are based on international standards. That is, XML web services leverage a strict message format definition. The reason XML web services are such a popular architecture among the standards-based bodies in the business world is that it the data format is relatively easy to decipher and it is independent of the operating system. Politically, XML is easy to sell within an organization since most management groups perceive it in a positive light. The combination of these factors makes XML web services a popular alternative to other data transfer mechanisms.

2.2 Web Services Provide Independence from Operating System
Web services enable distributed applications to be independent of any operating system. Thus, users can deploy one application on Windows and another application on UNIX, and have the two systems communicate with each other seamlessly.

For instance, when you conduct a search using the Google toolbar, you are unaware of the operating system that Google uses. The only thing of significance is that you can communicate with the remote web service. By using web service technology, one would be able to select the best operating system for a given task. The XML web services architecture leverages several standards to enable data transfer between applications on remote computers. Programmers have several choices to consider for their design. They can select Microsoft’s .NET technology and the C# programming language to reduce the development and deployment time. They might select IBM’s Websphere technology and program using Java instead.

These technologies and tools (web servers, libraries, APIs, etc) leverage the evolving security standards, user authentication, data transfers, data states, and a lot more. Applications programmers can rapidly build and deploy XML web services using existing tools and frameworks. It is important to stress that a web server (like Microsoft’s IIS) provides the necessary infrastructure to deploy XML web services. This is a common acceptable practice in the business world.

As a last alternative, programmers can even choose to build their own web services and the deployment technologies from the ground up (an arduous task). But no matter what the selection, XML web services provide that all-important independence from any hardware or software platform.

2.3 Poll-Report-By-Exception
Due to the nature of web server to web server communication that is a fundamental part of XML web service based applications, it is important to note that “report-by-exception” (RBX) is not possible. The best XML web services can do can do is a “poll-report-by-exception”, in other words, poll once and let the driver tell you what changed while you were away.

This approach works well for applications that collect data from remote sources, but do not require real time information updates. XML web services will make such application easier to deploy in the enterprise than DCOM-based.

Such applications include:

• Business applications such as CMMS (Computer Maintenance Management System), ERP (Enterprise Resource Planning), and EAM (Enterprise Asset Management). The applications require updates that are at hourly frequency at best, and usually updates every shift or more are more typical.

• Process Analysis applications such as Enterprise Process Historians, analytical reporting, trending, and others. The frequency of data capture is not nearly as important as the fact that data does not get lost. Companies typically use these applications on the Business Network, as opposed to the Operations Network.

• Remote monitoring applications such as web-based process visualization require very slow update rates. Furthermore, some of these applications limited supervisory control. In all cases, the applications limit this capability because data update rates are difficult to guarantee. Due to the slow nature of data updates, these applications are a good candidate for XML-based data transfers.

3. XML web services and Real-Time applications

3.1 Overview
While the name of the game is connectivity in the business world, real-time applications add transfer speed as another requirement. Real-time applications are unique because the significance of a calculation in entirely dependent on its timeliness. That is, if the application completes the computation late, the computation loses significance. So real-time applications must receive timely data updates in packages that are small enough that they can digest quickly.

As a last alternative, programmers can even choose to build their own web services and the deployment technologies from the ground up (an arduous task).  But no matter what the selection, XML web services provide that all-important independence from any hardware or software platform.

3.2 Update rates
The poll-report-by-exception mechanism of XML web services works well for business applications. However, in the real-time world, this approach works very poorly for applications such as:

• HMI (Human-Machine Interface) applications that require a quick updates of the screen. Operators require quick updates (usually every second) to enable them to monitor system response effectively. This is especially required during abnormal situations and hazardous operations such as startups or shutdowns.

• Real-time monitoring applications that operators would be use to set alarms or trigger various other applications to take action.

• MPC (Multivariate Predictive Controllers) applications that require fast process updates. These applications typically require process data every second or faster. They also change setpoints quickly.

Consequently, XML web services are a poor choice for applications that require fast real-time updates. A few applications that use XML web services to transfer OPC data have surfaced recently. The vendor’s hope is to transfer OPC data seamlessly from one computer to another using a “standard” interface. However, their implementation quickly shows the limitation of such a transfer, as they either suffer from extremely high bandwidth usage (since they have to constantly poll for changes), or they suffer a slow update rate. This update rate is unacceptable by the applications listed above.

Nevertheless, as the technology surrounding XML web services matures, these limitations will surely disappear.

[an error occurred while processing this directive] 3.3 Handling large message size
XML messages are very large in comparison to similar DCOM messages that carry the same information ,and their sheer size makes them difficult to transport en masse. One solution is to compress these messages in a binary format, but the compression process effectively renders the message to be of a proprietary format. This cancels the benefit of using XML in the first place.

Thus, if one can’t compress the message, its large size would have an impact in any network that is subject to any of the following:

• Limited network bandwidth such as a WAN (Wide Area Network) as well as radio, satellite or modem based networks.

• “Pay-per-byte” transmission such as that due to satellite communication.

• Noisy or unreliable communication has a lower chance of properly transmitting larger messages.

• Slow data transfer as in serial communication.

• Networks that must keep bandwidth usage under normal conditions to a minimum to allow for connectivity during abnormal situations.

XML web services based architectures are an attractive alternative in the business world that requires only a few messages, and delivery time is not important. Nevertheless, real-time networking applications that send large quantities of messages in quick succession would be unable to use XML web services for their strict connectivity requirements. Hence, large quantities of XML messages are not appropriate for the real-time world.

3.4 Web Services usually require a Web Server
As noted earlier, programmers can implement any custom application as a web service. The low-level specifics of inter-application communication for web services are quite complex, therefore it will be common to leverage technologies such as Microsoft’s .NET and deploy on full featured web servers such as Microsoft’s IIS. The problem with this approach is that while management will quickly accept XML as a transfer mechanism, they will rarely (knowingly) accept the deployment of web servers within the Operations network. This severely limits the installation base of applications that use web services for their communication infrastructure. Again, as technology matures, this limitation will surely disappear as well.

4. OPC UA (XML web services) versus OPC DA (DCOM)

First and foremost, OPC Unified Architecture (OPC UA) is complementary to OPC Data Access (OPC DA). The two specifications do not compete. OPC UA will not make your recent (or future) investment in OPC DA a financial failure. On the contrary, OPC UA will enhance your OPC DA infrastructure. OPC Unified Architecture, or OPC UA for short, is bases its communication on XML web services. This makes OPC UA a significant asset to Business network applications. In fact, OPC UA opens the business world to industrial connectivity that it has never experienced before. Applications from Finance, Maintenance, and Engineering will soon be able to benefit from data that the Operations network has had locked up for years. Imagine an enterprise that can produce financial reports accurately at the end of each quarter, month, or even shift. Imagine a maintenance crew that can schedule maintenance before impending equipment failure, or is able to divert maintenance resources away from equipment that can operate long past its scheduled maintenance time. Imagine an engineer who can produce accurate and timely production reports without resorting to their myriad of spreadsheets. OPC UA will deliver on its promise, and soon. Recent estimates show commercial applications appearing sometime in late 2006.

Figure 2: OPC UA (using XML web services) shares the enterprise with OPC (using DCOM). OPC UA connects Business applications while (DCOM-based) OPC handles real-time applications.
Picture courtesy of the OPC Foundation.

So what about those pesky real-time applications? Due to the nature of XML web services, the Operations network will continue to use OPC DA (OPC Data Access), which uses DCOM. DCOM is fast. It fills the gap between the real-time requirements of Operations and near real-time required by Business. OPC DA overcomes most, if not all, of the current drawbacks of XML web services (and therefore OPC UA). Again, technology will mature in time, and OPC UA will surely rise as the eventual winner.

5. Looking ahead

The OPC Foundation, in partnership with various industry leaders, is publicizing OPC, XML web services and openly embracing Microsoft’s .NET technology. Therefore, it is important to understand the position of OPC UA and OPC DA. In short, OPC UA (based on XML web services) will open much of the Business world to process data and information. It will enable management to make informed business decisions faster. However, OPC DA (based on DCOM) will continue to dominate applications used in Operations since OPC DA focuses on solving real-time data transfer requirements. OPC UA (for Business) and OPC DA (for Operations) complement each other, and they will continue to do so in the future.

6. Frequently Asked Questions

6.1 Overview
The OPC Foundation and its members have been talking about OPC UA for a few years now. During this time, we spoke to many vendors, integrators and end-users. This section covers that questions that we receive most often during our presentations.

6.2 Questions

[an error occurred while processing this directive] 6.2.1 Should I consider OPC UA as a communication platform for my future connectivity?
Absolutely. The OPC Foundation and most of its members fully endorse OPC UA. Many companies (including MatrikonOPC) have already announced that OPC UA will be included in their future products. Most of these products target connectivity on the Business network.

6.2.2 Is DCOM dead?
DCOM is alive and well. DCOM fills a void that XML web services cannot fill. In addition, the market currently provides a huge set of tools for programmers and end-users to help them with DCOM development and deployment. Consequently, DCOM will continue to dominate real-time communication in the Windows operating system.

6.2.3 How will OPC UA handle high communication performance requirements?
It is true that XML web services are much slower than DCOM. However, remember that the enterprise will use OPC UA for connectivity on the business network. These networks provide very high bandwidth, while their applications require low data update rates. Thus, communication performance should not be an issue.

Nevertheless, if communication performance is indeed an issue, then the following scenarios are likely to be the case:

a. The system requires real-time updates. If this is indeed the case, then you should consider OPC DA (using DCOM), as it fits the real-time data transfer model.
b. The system cannot use DCOM, but the system still requires real-time updates. This could be the case under the following circumstances:

• Using different Windows Domains or Workgroups
• Firewalls block communication
• Unreliable networks cause unpredictable DCOM timeouts
• Low-bandwidth networks make DCOM (and XML web services) ineffective
In all these cases, you should consider OPC Tunnelling technology such as what MatrikonOPC Tunneller provides.

6.2.4 What will happen to the existing (DCOM-based) OPC infrastructure?
Your current investment in (DCOM-based) OPC communication is safe. Since OPC DA and OPC UA are complementary technologies, we expect vendors to continue their support for DCOM-based OPC (MatrikonOPC will certainly continue their support).

6.2.5 How will I convert my OPC DCOM communication to OPC UA?
Vendors (such as MatrikonOPC) are already working applications that will convert DCOM–based OPC(DA, HDA and A&E) communication to OPC UA. You should expect to see commercial applications of this technology shortly after OPC UA makes its debut.

7. References
The following references will help you understand this whitepaper to a greater depth:
• Using Web Services instead of DCOM
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/webservicesdcom.asp
• Performance Considerations for Run-Time Technologies in the .NET Framework
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/dotnetperftechs.asp
• Improving .NET Application Performance and Scalability
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenet.asp

[an error occurred while processing this directive]
[Click Banner To Learn More]

[Home Page]  [The Automator]  [About]  [Subscribe ]  [Contact Us]