Using the OPC Standard for Real-Time Process Monitoring and ...

feature

real-time process control

Using the OPC Standard for Real-Time Process Monitoring and Control Jun Liu, Institute of Chemical and Engineering Sciences Khiang Wee Lim, Science and Engineering Research Council of Singapore Weng Khuen Ho, Kay Chen Tan, Arthur Tay, and Rajagopalan Srinivasan, National University of Singapore

A plug-and-play system based on the Object Linking and Embedding for Process Control standard tackles the challenges of communications among diverse development technologies.

54

IEEE SOFTWARE

n recent years, the use of software engineering tools for the process industry has increased substantially, accelerating research and development work. However, such tools are essentially limited in their connectivity to other systems and applications. It’s therefore challenging to integrate the diverse components developed using these tools so that they can seamlessly communicate locally and remotely.1 Accomplishing this integration is nonetheless essential, particularly as process

I

control applications grow larger and more complex.2 In current automation systems, hardware and software are often located in various parts of the target process. We therefore need a common way to exchange information between autonomous production equipment and a coordinating manufacturing executing system. We must also account for the different levels of process control functionality. Regular control activities are typically handled by digital automation or programmable logic systems, while independent applications typically perform advanced process control. Because we lack an application-level interface standard, interconnecting such applications is often quite tedious. Finally, researchers have done ample work using lab equipment and process simulation. To apply this work in the chemical

Published by the IEEE Computer Society

and process industry, we must first solve the problem of communicating with distributed control systems (DCSs), which control all modern chemical plants. To address these challenges, we propose an open, nonproprietary, plug-and-play system (ONPS) for real-time process monitoring and control. Based on the Object Linking and Embedding for Process Control (OPC) standard, ONPS provides a standard method for individual process monitoring and process control software to interact and share data. It also enables a seamless switch between simulations and real applications. We can therefore test new technologies in a real-time simulation environment, then seamlessly integrate them into the plant. Here, we describe our system’s design and implementation, using an intelligent alarm-management system as a case study.3

0740-7459/05/$20.00 © 2005 IEEE

Object distribution models With the advent of low-cost but powerful computers and high-speed networks, it’s increasingly important that information exchange occur between devices from different vendors and applications running on different machines. To meet the need to distribute object-oriented functionality and encapsulate it with well-defined application programming interfaces, researchers developed object distribution models.4,5 Three of the most popular models are CORBA, the Distributed Component Object Model (DCOM), and Remote Method Invocation (RMI).

CORBA CORBA is an open, vendor-independent architecture and infrastructure that computer applications use to work together over networks.6 It is defined and supported by OMG, a nonprofit trade association of more than 700 software developers, vendors, and end users.4,7 CORBA defines a distributed object architecture that lets developers write object-oriented client–server applications in heterogeneous distributed environments.2 Such applications are composed of objects and their interfaces. The objects are individual software units that combine functionality and data, and frequently represent real-world processes and entities. In addition to sometimes maintaining an internal state, CORBA’s objects provide one or more interfaces that consist of a set of available operations that clients can request. Interfaces can be inherited, extended, and composed. An object can also act as a client for another object. At the CORBA architecture’s core is the allimportant Object Request Broker, which enables the communication and interoperability between a client and an object. The ORB acts as a central object bus; through it, each CORBA object interacts transparently with other local or remote CORBA objects. CORBA server objects each have an interface and expose a set of methods. To request a service, a CORBA client acquires an object reference to a CORBA server object. The client can then make method calls on the object reference as if the CORBA server object resided in the client’s address space. The ORB is responsible for finding a CORBA object’s implementation, preparing it to receive requests, communicating requests to it, and carrying the reply back to the client. CORBA objects interact with the ORB through the

ORB interface or through either a basic or portable object adapter. CORBA also defines a separate Internet interORB protocol (IIOP) that lets various CORBA implementations interact over the Internet. The CORBA architecture ensures transparency among the operating system, the communication system, and the programming language.2

Distributed Component Object Model DCOM extends Microsoft’s object-oriented Component Object Model to promote interoperability of software objects in a distributed, heterogeneous environment.8,9 In a manner similar to CORBA, COM defines how software components and their clients interact. COM provides the communication between client and components by calls from the client to the component.8 To support remote objects, DCOM runs on the Remote Procedure Call (RPC). A DCOM server is a body of code that serves up particular object types at runtime. As with CORBA, each DCOM server object can support multiple interfaces, each of which represents a different object behavior. A DCOM client calls into a DCOM server’s exposed methods by acquiring a pointer to one of the server object’s interfaces. The client object then calls the server object’s exposed methods through the acquired interface pointer as if the server object resided in the client’s address space. Unlike CORBA implementations—which achieve source-level compatibility—COM/ DCOM permits binary component integration in an object-oriented fashion. However, it could be argued that CORBA is more object-oriented because, unlike DCOM, it supports object implementation inheritance. Because COM is specified at the binary level, developers can write DCOM server components in diverse programming languages, including C++, Java, Object Pascal (Delphi), Visual Basic, and even Cobol. As long as a platform supports COM services, DCOM can be used on that platform. CORBA implementations like IBM’s DSOM (Distributed System Object Model) and Iona’s Orbix provide proprietary extensions to the object model and language bindings, making their interoperability difficult. Such technologies are, however, better supported on various computational environments; DCOM is mainly targeted at Windows and NT platforms, although Unix and Macintosh implementations exist.

ONPS provides a standard method for individual process monitoring and process control software to interact and share data.

November/December 2005

IEEE SOFTWARE

55

Remote Method Invocation

OPC performance is more than adequate for most dedicated and distributed applications running on commonly available computers.

RMI, developed by Sun Microsystems, is an object-oriented model designed to promote transparent interoperability of Java objects in a distributed, heterogeneous environment.10 Because Java Object Serialization is specific to Java, both the RMI server object and the client object must be written in Java. Each RMI server object defines an interface that clients can use to access the server object on other machines’ Java Virtual Machines. The interface exposes a set of methods that are indicative of the server object’s services. Like CORBA and DCOM, the RMI clients come in contact only with the objects’ interfaces. An RMI client acquires an object reference to an RMI server object by doing a server object reference lookup, then invokes methods on the server object as if the RMI server object resided in the client’s address space. RMI server objects are named using URLs. Clients acquire server object references by specifying the service object URL. Because RMI relies on Java, developers can use it on diverse operating system platforms—from mainframes to Unix boxes, and Windows machines to handheld devices—so long as the platform has a JVM implementation. In addition to JavaSoft and Microsoft, several other companies have announced JVM ports.

Process monitoring and control system For software objects to interact with each other, they must comply with the rules of at least one of the three object distribution models. However, it’s difficult—if not impossible— for two objects conforming to different models to interact because the models use different interface approaches and implementations, different object references and storage, and different protocols.4 Within a given device, each software driver exposes a different software interface to the client application, and thus each application requires a unique piece of code for each driver, device, or network it wants to connect to. To solve this problem, we chose to base our system on the COM/DCOM-based OPC, which is widely used in the process industry and has become an industrial standard for accessing plant data.

automation-domain-specific component standard.11 OPC standardizes the mechanism for communicating to numerous data sources, whether they’re devices on the factory floor or databases in a control room. Vendors can therefore develop a reusable, highly optimized server to communicate to the data source and efficiently maintain the data source’s data access mechanism. OPC interfaces provided by the server let any client access the server devices.12 OPC also gives production and business applications across the manufacturing enterprise consistent access to real-time plant-floor information, making multivendor interoperability and plug-and-play connectivity possible. OPC performance is more than adequate for most dedicated and distributed applications running on commonly available computers. In one study, a P233 server using OPC supplied nearly 20,000 values per second to four clients with only 10 percent CPU load.13 OPC also provided more than 300 transactions per second for the single item requests— implying that OPC can also work effectively for small, simple, nonoptimized applications created for a specific task. In the same tests, one-million-plus values per second moved between an in-process OPC server and a client.13,14

How it works. The OPC specification defines a set of standard COM objects, methods, and properties that specifically address requirements for real-time factory automation and process control applications. In OPC’s clientserver model, server applications acquire, contain, and serve data to client applications. OPC servers provide a standard interface to the OPC COM objects, letting OPC client applications exchange data and control commands in a generic way. OPC client applications can communicate with one or more OPC servers from different suppliers.11 OPC client applications access data the same way, whether the data is coming from an OPC server connected to a PLC (programmable logic controller system); industrial networks like Foundation Fieldbus, Profibus, or DeviceNet; a supervisory control and data acquisition system (SCADA); a laboratory information management system; or a production management system.

OPC overview Developed by an automation software and hardware vendor consortium, OPC is the first 56

IEEE SOFTWARE

w w w . c o m p u t e r. o r g / s o f t w a r e

OPC support. OPC was developed by the OPC Foundation (www.opcfoundation.com), which

is supported by more than 300 process-industry companies worldwide, including nearly all of the world’s major providers of control systems and instrumentation. The goal of the OPC Foundation’s technical committees is to develop OPC enhancements that extend its functionality, including historic data access, alarm and event message delivery, security control, and batch data access. OPC runs on the Windows operating system, which is widely used for DCS, SCADA systems, PLC systems, and corporate management information systems. Even OPC-enabled applications developed in research environments can be easily applied to real plant and control systems. Because of OPC’s wide acceptance in the industrial field, the technology influenced OMG’s proposed data acquisition from industrial systems (DAIS) specification. Both DAIS and OPC share the same design idea, but DAIS is based on CORBA rather than COM/DCOM.15

OPC-enabled process monitoring and control applications Alarm management

Fault detection

Mode classification

Other applications

OPC interface Process simulation

OPC-enabled plant simulation

■

■

Multiple vendors can provide a variety of plug-and-play control solutions to the process industry. We can extend OPC’s functionality and scope to software-level system integration.

System implementation and results

Figure 1 shows the layout of our ONPS, which comprises three parts:

To facilitate connections between different areas—including process modeling, GUI, the database, process monitoring, and process control—we developed gateway bridges between an OPC server and different software tools such as Gensym G2, gProms (Process Systems Enterprise’s General Process Modeling System), and Matlab/Simulink. Software tools use OPC functionality to interact and share data through these gateway bridges every one or every few seconds (which is considered real time for chemical processes). Figure 2 shows an ONPS implementation that illustrates seamless and open system integration. As the figure shows, one OPC server effectively communicates with three OPC clients in parallel. The server application and client applications can be either on the same computer (using a local server) or different computers (using a remote server). We used a refinery’s process-flow diagrams and pipe and instrumentation diagrams to build a simplified physical model of the process and the controller. The target process is the reaction section of a cyclohexane unit, which is only a small part of the plant. After we built the process model (by combining differential and algebraic equations), we used dynamic simulation software to implement the process simulation. We then collected historic process data—recorded every minute under

■ ■

plant simulation, which provides plant data and an operator interface; an information database, which stores process data; and advanced process monitoring and control applications, which increase productivity and product yield.

ONPS must allow for common component interoperability, substitutability, extensibility, and reuse. We accomplish this using OPC functionality to integrate several systems and information databases. These systems include process simulation, DCS emulation, alarm management, fault detection, mode classification, and other process monitoring and control applications. By integrating these modules in an OPC-compliant way, we realize several objectives: ■

■

We can test new technologies in real-time simulation and seamlessly integrate them into the plant. We can develop control solutions using many engineering tools commonly used by process control engineers and then can incorporate them through a standard OPC interface.

Information database

Distributed control systems

ONPS overview

■

OPC data-access server

Figure 1. The open, nonproprietary, plugand-play system for real-time process monitoring and control. Based on the Object Linking and Embedding for Process Control standard, ONPS includes three modules: plant simulation, information database, and the advanced process monitoring and control applications.

November/December 2005

IEEE SOFTWARE

57

gProms process simulation

G2 DCS emulation

Foreign process interface

Test bed gProms OPC bridge

Gateway standard interface

G2–OPC bridge

OPC server

(a)

OPC interface Intelligent Alarm Management System

(b)

Intelligent Alarm Management System

Operator

OPC server

Plant simulation

Distributed control system with OPC server

Distributed control system emulation

Plant

Figure 3. The Intelligent Alarm Management System simulation versus application. The same IAMS applies to both the simulation and the real plant.

58

IEEE SOFTWARE

w w w . c o m p u t e r. o r g / s o f t w a r e

Figure 2. Implementation example. (a) Applying Intelligent Alarm Management System (IAMS) to a test bed consisting of a process simulation using a general process monitoring system (gProms), a distributed control systems (DCS) emulation in G2, and an Object Linking and Embedding for Process Control (OPC) server. (b) Simulation snapshot: OPC server (top left), IAMS (top right), process simulation (middle left), G2–OPC bridge (bottom left), DCS emulation (bottom right).

different operation conditions—to calibrate and verify the process model. We developed the process simulation using gProms, a process modeling, simulation, and optimization software based on physical and chemical relationships in the process and the operational task sequences superimposed on them. We also developed a general gProms–OPC bridge for communication between gProms and the OPC server. The gProms–OPC bridge is actually a combination of OPC client functions and gProms foreign process interface functions. The gProms process simulation provides real-time process data (every second) to the OPC server and receives the operator’s controller settings from the OPC server. We developed the DCS emulation using G2, a graphical, customizable, object-oriented real-time software platform from Gensym for rapidly building expert manufacturing applications. However, in our example implementation, we mainly used G2’s GUI, rather than its expert system. We also developed a general G2–OPC bridge for communication between G2 and the OPC server. The G2–OPC bridge is actually a combination of OPC client functions and G2 gateway standard interface functions. The G2 DCS emulation receives process data from the OPC server and sends the operator’s controller setting to the OPC server. We developed the Intelligent Alarm Management System3 using Visual C++. The IAMS has been successfully applied to both a real refinery plant and a real-time process simulation (see figure 2), which simulates part of the cyclohexane plant’s reaction section, involving about 40 variables. Figure 3 shows the simulation compared to the real-world application. Aside from specifying different OPC servers

to collect the process data, the same IAMS works well for both the real plant and the simulation. This consistency shows that the ONPS can provide totally seamless and truly open system integration for industry automation, as well as a seamless switch between simulations and real applications. Because most popular DCS and SCADA software available today include OPC server functionality, our OPC-compliant ONPS makes process monitoring and control applications plug-and-play to the real plant. For those few software applications that don’t include this functionality, third-party solutions might be available. OPC client applications could simply be “plugged in” to third-party software packages’ process data.

About the Authors Jun Liu is a senior research fellow in the Institute of Chemical and Engineering Sciences. His

research interests include process monitoring, process control, alarm management, and software development. He received his PhD in control engineering from Southeast University. Contact him at [email protected].

Khiang Wee Lim is deputy executive director of the Science and Engineering Research

Council of Singapore. His research interests are in supervisory control and fault diagnosis. He received his DPhil in engineering science from Oxford. He is a senior AdCom member of the IEEE Industrial Electronics Society. Contact him at [email protected].

Weng Khuen Ho is an associate professor in the Department of Electrical and Computer Engineering at the National University of Singapore. His research interests are in semiconductor manufacturing, process control, and signal processing. He received his PhD in electrical engineering from the National University of Singapore. He is an associate editor of IEEE Transactions on Industrial Informatics. Contact him at [email protected].

I

n the future, we plan to use the ONPS to monitor and control our pilot plant. To further develop ONPS, one future direction might be to include additional system functions, such as historic data access, alarm and event access, batch data access, and so on. Another future improvement might be to provide a proxy bridge object (such as CORBA–DCOM bridge) or use a common XML-based protocol to implement interoperation between different object distribution models.

Kay Chen Tan is an associate professor in the Department of Electrical and Computer

Engineering at the National University of Singapore. His research interests are in evolutionary computation, intelligent control and design automation, and computational intelligence. He received his PhD in control engineering from the University of Glasgow. He’s a member of the IEEE. Contact him at [email protected].

Arthur Tay is an assistant professor in the Department of Electrical and Computer Engi-

References 1. L. Wills et al., “An Open Platform for Reconfigurable Control,” IEEE Control Systems, vol. 21, no. 3, 2001, pp. 49–64. 2. K. Feldmann, T. Stöckel, and B. Haberstumpf, “Conception and Implementation of an Object Request Broker for the Integration of the Process Level in Manufacturing Systems,” J. Systems Integration, vol. 10, no. 2, 2001, pp. 169–180. 3. J. Liu et al., “The Intelligent Alarm Management System,” IEEE Software, vol. 20, no. 2, 2003, pp. 66–71. 4. K. Raptis, D. Spinellis, and S. Katsikas, “Multi-Technology Distributed Objects and Their Integration,” Computer Standards & Interfaces, vol. 23, no. 3, 2001, pp. 157–168. 5. G.S. Raj, A Detailed Comparison of CORBA, DCOM, and Java/RMI, white paper, Object Management Group, Sept. 1998. 6. The Common Object Request Broker: Architecture and Specification, version 2.3.1, Object Management Group, 1999. 7. S. Vinoski, “CORBA: Integrating Diverse Applications within Distributed Heterogeneous Environments,” IEEE Comm., vol. 14, no. 2, 1997, pp. 46–55. 8. The Component Object Model Specification, version 0.9, Microsoft, Oct. 1995. 9. M. Horstmann and M. Kirtland, DCOM Architecture, white paper, June 1997, Microsoft Corp.; http://msdn. microsoft.com/library/default.asp?url=/library/en-us/ dndcom/html/msdn_dcomarch.asp. 10. Java Remote Method Invocation Specification, Sun Microsystems, 1998. 11. OPC Task Force, OLE for Process Control—OPC

neering at the National University of Singapore. His research interests include process control and monitoring, and design and process integration for microelectronic manufacturing. He received his PhD in electrical engineering from the National University of Singapore. He’s a member of the IEEE and International Society for Optical Engineering. Contact him at [email protected].

Rajagopalan Srinivasan is an associate professor in the Department of Chemical and Biomolecular Engineering at the National University of Singapore and a senior scientist in the Institute of Chemical and Engineering Sciences. His research interests include abnormal situation management, design of safe and environmentally benign chemical processes, business process optimization, and computational systems biology. He received his PhD in chemical engineering from Purdue University. Contact him at [email protected].

12.

13. 14. 15.

Overview, v. 1.0, OPC Foundation, 1998; www. opcfoundation.org/DownloadFile.aspx/General/ OPC%20Overview%201.00.pdf?RI=1. Y. Shimanuki, “OLE for Process Control (OPC) for New Industrial Automation Systems,” Proc. 1999 IEEE Int’l Conf. Systems, Man, and Cybernetics, vol. 6, IEEE Press, 1999, pp. 1048–1050. A. Chisholm, DCOM, OPC and Performance Issues, OPC Foundation white paper, 1998. A. Chisholm, “OPC Solves the I/O Driver Problem,” Control Eng., vol. 45, May 1998, pp. 127–130. H. Xu and J.H. Wang, “An Extendable Data Engine Based on OPC Specification,” Computer Standards & Interfaces, vol. 26, no. 6, 2004, pp. 515–525.

November/December 2005

IEEE SOFTWARE

59