By Paul Miller, contributing editor
This is Part I of a two-part examination of OPC UA, how it differs from its predecessor OPC DA, and how users can determine its value to them. Part II will appear in the Q4 2008 (Have More Data ConversationsĀPart II).
For more than a decade now, OPC data accessĀ (DA) has provided a more-or-less-standard interface that allows software applications to capture dynamic data from different vendorsĀ intelligent devices. Despite some initial concerns about performance, especially on older PCs, and ongoing concerns about usability, security and its Microsoft-centric nature, OPC DA is widely used in industrial operations. No doubt, the proliferation of Microsoft-based personal computers on the plant and factory floor over this same time period has played a major role in the acceptance of OPC technology.
By now, most everyone reading this knows OPC stands for object linking and embedding (OLE) for process control. OPC DA is based on COM/DCOM (distributed component object model), a legacy Microsoft proprietary technology for primitiveĀby todayĀs standardsĀobject-based communications between computers on a network. COM/DCOM, which represents first-generation integration technology, is pretty long in the tooth and much maligned among those users in the know.
The next generation of integration standards from the OPC FoundationĀOPC Unified Architecture (UA)Ādeparts from its Microsoft roots and embraces open, vendor-independent Web Services technology. OPC UA ties together the functions associated with earlier OPC specifications: Data Access (DA), Historical Data Access (HDA), and Alarms & Events (A&E), bringing them into a common services-oriented architecture (SOA) environment.
OPC Data Access Architecture
Based on COM/DCOM technology, the OPC Data Access (DA) specification allows Microsoft-based clients and servers within the same network domain to exchange dynamic, tag-based data.
Source: OPC Foundation
While the original OPC specifications focused on tag-data-based device interoperability in a common control network, OPC UA focuses on cross-platform interoperability with a much richer set of data and information.Ā OPC UA is intended to provide a platform for secure, reliable interoperability based on Web Services. According to the OPC Foundation, backward-compatibility allows the existing base of OPC DA applications to be integrated into the new architecture.
The initial OPC UA specifications were released to early adopters in 2006 and the first OPC UA-enabled products just now are beginning to appear on the market, so itĀs still too early to gauge specific user experience. Initial OPC UA-enabled products incorporate OPC UA server technology from Kepware Technologies.
Advanced Production Systems (APS), a system integrator based in Louisville, Ky., recently used a Kepware OPC DA server for an interface to validate data in the PLC programs provided by machinery suppliers to a major automotive manufacturer. The goal was to provide a portable software application or validation tool, which would be installed by each supplier at its engineering and production facility. The use of the OPC-based technology eliminated custom drivers for each of the devices, which, considering the sheer quantity needed, would have been too expensive due to the go-to-market timeline.
ĀTodayĀs global economy requires most manufacturers to respond to rapid change,Ā says Dan Korfhage, owner of APS. ĀTo do this, they need to continually optimize operations and reduce costs through the entire supply chain. This validation tool is one example of closing the gaps in the supply chain using standards-based technologies like OPC.Ā
APS likely will take advantage of the increased capability of UA in the future, since KepwareĀs approach lets users connect via COM or UA-based OPC methods. ĀProviding a single OPC server that supports COM and UA-based OPC will help our customers make the transition to UA seamlessly.Ā says KepwareĀs president, Mark Hensley.
OPC UA is New Territory
Most end users in industrial process plants are not yet familiar with the emerging OPC UA specification, much less what it ultimately will mean to them. The same is true for vendors and SIs. ĀOur use of OPC is mostly with DA 2.0 in moving data from DCS to PIMS or reporting applications,Ā comments Phil Murray, engineering manager at system integrator, Feedforward, Marietta, Ga. We really havenĀt followed UA, but my biggest concern with OPC is the security issue with DCOM. Anything that UA offers to improve this is a step in the right direction.Ā
Feedforward used existing OPC technology to enable data exchange between two different vendorsĀ products. Feedforward was retained by Oneok, an energy company involved in oil and gas production, to integrate a system that would transfer data from an older Foxboro DCS , circa1986, at a facility in Maysville, Okla., over the Internet to a company in Houston for use in a process simulation. Gary Canfield, the project manager for Feedforward, says he needed an OPC solution that would provide the connectivity. Given the age of the legacy machine, an OPC driver didnĀt already exist, so he used a generic, off-the-shelf information exchange product from MatrikonOPC to create his own OPC server.
Previous Issues with DA
ĀThereĀs broad market acceptance for OPC DA, but the feeling is that its communications are unsecured, which means developers must create application-level security to prevent the network from overloading,Ā comments Stephen Briant, product manager at Rockwell Automation.
ĀMost of the OPC UA questions the OPC Foundation has received from the end users, SIs and automation vendors address the pain points theyĀre currently having with the existing OPC products,Ā says Jim Luth, OPC Foundation technical director, Āincluding the need to get rid of DCOM technology that is difficult to configure and has firewall issues. DCOM worked well as long as you kept it within one network domain and didnĀt cross firewalls. But as soon as you have a big organization with multiple network domains and firewalls, things get really tricky. To get around the firewall issue, you had to open up ports, and IT guys donĀt like doing that at all.Ā
OPC Unified Architecture
Based on Web Services, the platform-, and protocol-independent OPC Unified Access (UA) specifications facilitate data and information interoperability across multiple network domains, including field networks, process control networks, plant information networks and enterprise networks.
Source: OPC Foundation
According to Roy Kok, KepwareĀs vice president of marketing and sales, OPC UA solves several problems, making it a logical extension of OPC today. ĀThese include removing the dependence on Microsoft COM and DCOM technology, combining specifications into one primary spec for ease of understanding and development and adding security mechanisms which are independent of Microsoft user security,Ā says Kok. ĀUsers will benefit the most from the breaking of the ties with COM and DCOM. OPC UA leverages the current concepts of SOA and Web Services.Ā This should facilitate a broader level of connectivity, including embedded devices and non-Microsoft platforms.
ĀOPC-UA will be a well-behaved IT citizen, thanks to support for Web Services and next-generation design,Ā claims Invensys WonderwareĀs Rashesh Mody, chief architect at the OPC Foundation. ĀThe robust architecture addresses earlier problems.Ā
From an engineering perspective, key services built into OPC UA, such as network discovery and diagnostic services, will simplify engineering, he states. ĀFrom an operations perspective, a formal OPC Foundation certification process using independent labs will eliminate interoperability issues,Ā claims Mody. ĀUsers will decide which level of certification theyĀll accept for their applications. Special APIs (application program interfaces) and toolkits eliminate performance issues sometimes associated with Web Services. The Web Services will be optimized for OPC UA. Its performance is so good that people are thinking about embedding UA drivers into their hardware.Ā
From the IT perspective, continues Mody, OPC UA can work through firewalls without problems, Āeliminating the earlier security issues with OPC. OPC UA has built-in diagnostics to simplify network troubleshooting. And since its platform-independent, it works with different operating systems and platforms.Ā
But does OPC UA do more than just address the shortcomings of earlier OPC technology? ĀItĀs important to note what weĀve been doing with the other consortiums,Ā says Tom Burke, OPC Foundation president. ĀYou shouldnĀt underestimate the significance of the collaboration weĀve done with EDDL and inclusion of the FDT team to form the Future Device Integration (FDI) architecture team. WeĀve taken Profibus and Profinet and HART and Foundation fieldbus and created opportunities for tight collaboration by leveraging OPC UA as the transport mechanism and the SOA.When The OPC Foundation started doing this in 2001, it had a vision about exchanging data and information between different vendorsĀ PLCs and DCSs. ĀThese last two years, weĀve expanded the vision to the field devices to come up with a standard device description language (DDL) and using OPC UA as a common mechanism for diagnostics, configuration and run-time operation,Ā says Burke. ĀSo step back one level. This means youĀll be able to take any valve and any industrial control network, regardless of vendor, and be able to configure the thing. And users just have one tool to learn instead of the multiple tools we have today, which has been the nightmare.Ā
Burke says when the originators started OPC, it basically was about providing a standardized interface for talking to all these devices. ĀThis helped the vendors by minimizing the amount of software they had to write,Ā he adds. ĀNow, with OPC UA, we have a standardized interface that goes beyond simple communications. We have a way to have standardized dialogue windows, standardized representation of simple text and dynamic variables and diagrams and archive files, essentially integrating all these network devices while having respective industrial networking technologies from OPC, PNO, HART, FF and FDT all coming together.Ā
Factory automation will be next. ĀOnce we add the capabilities of DeviceNet, ControlNet, and EtherNet/IP, weĀll essentially have one way for doing configuration, diagnostics and run-time operation for any device, regardless of the network itĀs on,Ā says Burke.
End users long have been concerned about their legacy systems and devices that came from many vendors and donĀt necessarily all run on the same industrial network. So, how do you lower the cost of education and training and development and maintenance? ĀYou do it by having standard mechanisms for easy plug and play, independent of the network,Ā argues Burke. ĀThatĀs what the collaboration between the OPC, PNO and FF and HART and EDDL and FDT organizations allows. The partnership provides a solid foundation for device configuration, diagnostics and run-time information, such that generic applications with a standardized user interface independent of the underlying network technology can be developed.Ā Devices can be discovered as soon as they are plugged into the network with all the necessary information for configuration, diagnostics and run time readily available to the upstream software applications, adds Burke.
ĀOPC DA typically sits on top of proprietary networks,Ā says RockwellĀs Briant. ĀThe move from proprietary to Ethernet-based networks is significant. With the proliferation of Ethernet over the last couple of years, we see an opportunity in the future to take some of the stuff thatĀs currently at the proprietary protocol level down to the device level to allow more plug and play. The OPC Foundation is working with EDDL and FDT to develop a common device definition. With OPC DA, device interoperability will be limited since DA only provides limited tag-level information, rather than the rich set of data that will be available via UA. With Ethernet, I can pull more information through the pipe.Ā
With OPC UA, an OEM doesnĀt need to create drivers for third-party devices. ĀUA provides a rich communications environment that will allow SIs and end users to pull together applications that they donĀt have today with DA tags and custom drivers,Ā continues Briant. ĀAll the vendors in the automation space have some level of proprietary connections between their hardware devices and software. This gets in the way of interoperability at the device level. Assuming that the automation world continues the move toward Ethernet, UA will allow interoperability at a lower level.Ā
In the Q4 2008 issue of INDUSTRIAL NETWORKING, weĀll discuss the certification and interoperability assurances OPC UA must provide its potential users. WeĀll also look at how it affects the relationship between factory and IT personnel. To read the second part of this article right now, visit IndustrialNetworking.net/opcua2.

Leaders relevant to this article: