Have More Data Conversations

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

In contrast, says Luth, OPC UA is built on IP technology. “UA is designed to be both cross-platform and transportable,” he states. “As a result, you’ll see UA in devices and places where you’d never see DCOM-based applications.”

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.