OLE for process control (OPC) is the hottest new communications protocol for industrial control. Most vendors claim full support for OPC, and end users are more than ready for a universal communications standard. The OPC Foundation (http://www.opcfoundation.org) and supporting vendors tout plug-and-play connectivity among OPC servers and clients, but in the real world of day-to-day implementation there are still some potential pitfalls.
OPC is intended to provide a standards-based way of connecting supplier software applications together and easily connecting and storing information in enterprise-wide, SQL-based, data warehouses. Process control vendors love OPC because it has freed them from the task of writing and maintaining software drivers. Before OPC, many of these firms had to support hundreds on drivers to enable communication between their products and PLCs, analyzers, and loop controllers.
End users also appreciate the elimination of custom drivers, but many question the purported "ease" of establishing reliable OPC connections among products from different vendors. "After trying to connect several different systems (Bailey Infi90, Foxboro I/A, Emerson DeltaV, Yokogawa Centum 3000, Siemens Moore APACS+) that use OPC 2.0, it is clear that each vendor implements the standard in a slightly different way," says Dave Seiver, PE, APC project manager with Air Liquide Process & Construction, Houston. "This causes problems when connecting and thus tempts you to use their connectivity products."
Seiver feels this problem is probably related to loose specifications that allow wiggle room in implementing OPC standards. "The end result is end users have a heck of a time connecting DCSs with an industry standard connection," he says. "OPC standards and specifications should be more stringent so that the chances of non-compatibility are minimized, and vendors should strictly adhere to the specifications."
The OPC Foundation is addressing the problem of specification compliance through self-certification by product vendors. The foundation provides compliance test tools to members at no cost. Each vendor runs the compliance test tool on that vendor's OPC server product, and a compliance report is generated listing all functions that passed or failed the tests.
If the product passes, the vendor is required to send a test report to the OPC Foundation for final review and certification. The compliance test tool generates an encrypted final report so test results cannot be altered. "The OPC Foundation recommends that all member companies get their products compliance tested and certified, and we think that end users should make sure the OPC server products they buy are OPC Compliance Tested," says Don Holley, OPC Foundation marketing director.
A control systems engineer with a major refiner is currently implementing an OPC interface, and he finds OPC connectivity anything but seamless. "We need to replace existing operator consoles with consoles from a different vendor. Getting these consoles to talk reliably to the Bailey DCS, even using RoviSys's very nice OPC driver, is proving to be a challenge." He suggests that vendors should be asked to describe their design for real-time control reliability in OPC connections before any purchases are made.
One of the major process control vendors gives some insight into why OPC connectivity between DCSs and HMIs can be problematic. "Many DCSs are completely proprietary internally, but do have a software gateway through OPC," says Jonas Berge, an engineer with Smar (http://www.smar.com). "You can map information in and out of the DCS, but you cannot easily use an off-the-shelf HMI/SCADA package for process visualization." Berge suggests that the vendor should be asked if the system is built on OPC to the core, or if OPC is just a bolt-on.
Rick Caldwell, president of SCADAware (http://www.scadaware.com), a systems integrator in Bloomington, Ill., has vast experience with both custom software drivers and with OPC clients and servers. "Nothing beats a custom driver for performance and reliability, but these drivers are very difficult to write and maintain," he says. "OPC performs well enough for many applications, and implementation is much easier."
Caldwell claims that not all OPC clients and servers are created equal. Some are poorly written and will not work without tweaking, while others are ready to go right out of the box. He says OPC communications software should be purchased from a reliable vendor such as Kepware (http://www.kepware.com), and he cautions against buying "$29 OPC servers on e-Bay."
Most users and vendors agree that OPC is an excellent connectivity tool, but users caution that time and money must be budgeted for implementing OPC interfaces. Designing an OPC interface is much easier than writing a communications driver from scratch, but true plug-and-play operability depends on adherence to specifications and attention to detail.
