Interested in linking to "Playing Well with Others"?
You may use the Headline, Deck, Byline and URL of this article on your Web site. To link to this article, select and copy the HTML code below and paste it on your own Web site.
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 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.
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.