This article was printed in CONTROL's December 2009 edition.
By Walt Boyes, Editor in Chief
There are several kinds of process analyzers, both on-line and at-line. On-line analyzers vary from simple pH meters to complex hydrocarbon analyzers and online scanning electron microscopes (SEMs), and they speak different languages. An at-line analyzer can be completely different from the on-line analyzer sitting next to it because they were designed to meet different specifications, to do different jobs, and to communicate in completely different ways. This is not a good thing when trying to fit analyzers into the control system communications framework to comply with the Process Analyzer Technology (PAT) Initiative or when trying to integrate analyzer data into the process control system.
The PAT initiative requires that analyzers be capable of reporting to the control system in real time, so their information can be used for real-time control of the processes. This is easier said than done for several reasons.
Some analyzers have analog (4-20 mADC) outputs; some have RS-232 or Modbus outputs; some have datalogging and data storage capability but no real-time output; and some have no output at all and weren't designed to have any.
Some control systems can't take in data other than simple outputs from analyzers, like pH or conductivity, and field instruments like flow, pressure, level and temperature. The output of some analyzers must be sent to data historians or advanced process control modules that can use it in their models for control.
Why Such a Big Deal?
Why is PAT this important? All you have to do is to look at the results reported at Emerson Global Users Exchange by Bob Wodjewodka of Lubrizol and Terry Blevins of Emerson Process Management. Control reported on this issue from the 2007 Emerson Exchange meetings ( 2007, www.controlglobal.com/articles/2007/321.html)
Wodjewodka, a statistician by training, has been trying to figure out how to control a batch while it is cooking and steer it into the good norm in real time or near-real time for years. Why? Because some of his batches require 30 days or more to complete, and throwing away a bad batch after that long plays havoc with production scheduling, not to mention the cost of waste and environmental issues associated with waste disposal. Wojewodka has identified thousands of dollars in potential savings, and in a test conducted earlier in 2009 in Rouen, France, payback began within hours of beginning the test, as problems were identified and fixed almost immediately.
If you add to this the convergence of industrial networks on Ethernet and the use of PC-based software for many larger analyzers, whether at-line or online, it becomes apparent that in order to comply with PAT and to assist in improving productivity or quality, analyzers must learn to speak a common language or work with a common translation.
Traditionally, this has been a very difficult integration to perform, since analyzers have disparate communications mediums, and custom application program interfaces (APIs) can be notoriously "brittle." That is, these links are easily broken, and the data then suddenly doesn't get from the analyzer to the control system until the API is repaired.
For years, the most commonly used method of data transfer in the process control space has been OPC. Originally called OLE, for Object Linking and Embedding, this started out as a Microsoft ad hoc standard for data exchange that used COM/DCOM as its translation method. Seeing the great value of this methodology, several automation professionals created a variation of OLE called OLE for Process Control, or OPC. The OPC Foundation (www.opcfoundation.org) now calls this OPC Classic.
In addition, with Microsoft's move away from OLE toward the .NET framework for services, and with the advent of open operating systems such as Linux, the OPC Foundation moved to create a radically new and significantly stronger and more robust version of OPC called OPC-UA, for Unified Architecture.
OPC ADI
Recently, a companion specification to OPC-UA called OPC Analyzer Devices Integration (ADI) was released by the OPC Foundation to provide users with a common method of data exchange for analyzer data models and laboratory, online and at-line analyzers. The OPC ADI Specification serves as an information model for analyzer devices which enables true plug-and-play, multi-vendor interoperability. "The release of the ADI spec enables us to provide the industry with analytical products based on open connectivity that will seamlessly interoperate with manufacturing systems to provide an enhanced degree of efficiency and reliability," according to Thomas Buijs, product manager at ABB (www.abb.com).
"OPC ADI is an exciting step forward toward establishing an industry standard for integrating process analyzers with production control systems," said Jay Cincotta, software marketing manager at Mettler-Toledo AutoChem Inc. (http://us.mt.com/)
"The specification is truly a pragmatic one, whose development was motivated by the end-user community," commented Alisher Maksumov, Software Engineering Group lead at OSIsoft (www.osisoft.com). A mix of end-user companies and process analytical technology vendors have committed to using the OPC ADI specification, including ABB, Abbott, Arla Foods, Bristol-Myers Squibb, BRL Consulting, Bruker Optics, CAS, FOSS, GlaxoSmithKline, Kaiser Optical Systems, Malvern Process Systems, Mettler-Toledo Autochem, Novartis, Pfizer, Sentronic GmbH, Siemens AG, Software Toolbox, Sympatec GmbH, Thermo Fisher Scientific, Umetrics and Yokogawa.
[sidebar id="3"]
For those end users and vendors who have standardized on the .NET framework for services and data exchange and interchange, the OPC Foundation has also recently announced the OPC Xi (Express Interface) specification. The OPC Xi interface is the result of collaboration among several OPC vendor companies from the process industry to develop an easily integrated and secure solution for a variety of plant communications, including analyzers with PC-based controls. "OPC Xi was developed with the primary goal to provide a .NET-based migration path from OPC Classic. OPC Xi may also be used as a standard .NET WCF interface for newly developed OPC servers," said Thomas Burke, OPC Foundation's president.
"Xi is a new Microsoft .NET-based interface designed for secure and reliable access to real-time and historical process automation system data. Xi provides a standard, .Net-based interface for 'classic' OPC server functionality, OPC Data Access (DA), OPC Alarms & Events (A&E) and OPC Historical Data Access (HDA), and represents a natural progression of Microsoft communication technology from the Microsoft Component Object Model (COM) to .Net," said one of the developers of OPC Xi, Chris Felts, product strategist with Emerson Process Management (www.emersonprocess.com).
"Xi provides the same functionality as the classic OPC servers, while addressing some of the known shortcomings of classic OPC. The classic OPC servers are based on COM communications, which was state-of the-art when the OPC specifications were created, but since the introduction of OPC DA in 1996, Microsoft moved from COM to .Net. COM is efficient for local server access, but it can be difficult to configure for remote server access and problematic for communication through firewalls," said another of OPC Xi's developers, Jon Brown, strategic account manager with Iconics (www.iconics.com).
"Xi provides secure communications with a firewall-friendly interface and patented security features to provide secure communications between process automation systems and higher level manufacturing execution systems (MES) and enterprise resources planning (ERP) systems. Xi increases client connectivity robustness by maintaining the state-of-the-client connection, allowing the client to reconnect quickly and easily if communications with the server become lost," said Lee Neitzel, senior technologist with Emerson Process Management. "Xi is based on Windows Communication Foundation (WCF), the latest communications technology available from Microsoft. Using WCF, a Xi server is able to offer industry-standard communication protocols, including Transmission Control Protocol (TCP), Hypertext Transfer Protocol (HTTP), and Secure Hypertext Transfer Protocol (HTTPS)."
The promise of PAT is far from being realized, partly due to integration problems with disparate analyzer communication protocols. These new OPC specifications may take us a long way toward achieving the FDA's vision for PAT.
