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 ConversationsPart 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 primitiveby todays standardsobject-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 FoundationOPC 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.
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.
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 its 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.
Todays 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 Kepwares 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 Kepwares 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 havent 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 didnt already exist, so he used a generic, off-the-shelf information exchange product from MatrikonOPC to create his own OPC server.