An OPC Client-Server Application for the Integration of an Intelligent System ..... When the diagnosis system founds an abnormal behavior in the monitored ...
Colloquium SC D2 June 2005 Cuernavaca, Mexico
An OPC Client-Server Application for the Integration of an Intelligent System into a Turbogas Simulator Jojutla Pacheco Instituto de Investigaciones Eléctricas
Pablo H. Ibargüengoytia Instituto de Investigaciones Eléctricas (México)
Alberto Reyes Instituto de Investigaciones Eléctricas
ABSTRACT This paper describes a communication system based on client-server architecture for the integration of an intelligent system into a turbogas simulator. This solution provides graphical features and allows the communication of a PLC-based control system with an intelligent operator assistant in order to transfer and access data. The development of this application was based on graphical programming using RAD tools such as Java, LabVIEW, In-Touch and Visual Basic. The end-user application allows plant operators to have graphical information about the process, as well as diagnosis and operation planning capabilities. The intelligent system for operator assistance is briefly described. We explain the details of OPC client-server architecture to manage the integration of both diagnosis and planning systems, and its role in control systems as a widespread communication protocol. We describe a testing platform and results.
1.0 INTRODUCTION Modern power plants are complex processes, as highly automated and instrumented that frequently leave out the operator from making decisions. However, there still exist some unusual manoeuvres that require the experience and ability of the operator in order to succeed in a rentable and safe operation. Some typical examples of these cases are load rejection, as well as responses to failures [1]. A novel strategy is the use of intelligent systems to support the human decision process during events as the one mentioned above. Many of the most efficient intelligent systems for real world applications are still developed only in research centers with academic tools such as Java, MatLab, C++, etc. On the other hand, industrial systems for process control are usually incompatible with these development languages. One example is a natural integration of Java and LabView, or Java and InTouch technologies. In this paper, we present our experience in the integration of a diagnosis and planning systems into a PLC-based turbogas simulator to detect a failure and provide an action plan for useful recommendations to plant operators. We took advantage of the industrial standard
Colloquium SC D2 June 2005 Cuernavaca, Mexico
communication protocol, OPC (Ole for Process Control) to exchange information in real time between the PLC database, the operator station, and the integrated intelligent system. This paper is organized as follows. Section 2 describes the power generation problem domain and the necessity to integrate the software modules of an intelligent system composed by a diagnosis and planning systems into a turbogas unit simulator. Section 3 presents each intelligent module and the way they interact through our solution to detect sensor failures, and formulate a plan to move the plant into a useful and safe condition. In section 4, we show the main features of the turbogas simulator system. Section 5 shows the system integration using OPC technology. In section 6, our laboratory testing platform is presented and we illustrate the expected system behavior with an example. Finally, in section 7, we conclude and give extensions and future work.
2.0. APPLICATION DOMAIN In a turbogas power unit, as in other industrial processes, the control system assumes that sensor information is correct. However, there are cases where one sensor or a group of sensors readings simply fail. Thus, it is possible that the control system to produce erroneous commands. On the other hand, an intelligent system can code a form of human knowledge, which allows it helping operators make right decisions about how to reset the control references when a sensor failure occurs. An opportune failure diagnosis and the performance of an emergency plan, in many cases could avoid operating a plant under unsafe conditions. It also could help reduce significant economical losses, given that an emergency plant trip could be avoided. In our end-user application, a diagnosis system detects and isolates a faulty turbogas component that makes the process behave abnormally [2], and a planning system assists the operator to minimize the effects of the failure and to coexist with it in a safe way until the maintenance can be achieved. The maneuvers are composed by several actions that the operator executes, e.g., closing valves, starting pumps, opening switches, etc. The state of the process is obtained using sensors. The diagnosis system reports the detection of a faulty component. The planner receives this information and designs a plan that will advise the operator in order to keep the process in the most useful and safe state. For example, if the diagnosis detects a failure in one of the temperature sensors, the operator may decrement the load and keep the unit generating in lower temperatures while the failure is fixed. On the contrary, if temperature readings are uncertain, then some operators may shut down the turbine in order to avoid damage. Next section briefly describes each intelligent system module in order to better understand how well an integrated computer system can improve the availability index in a turbogas power plant.
3.0. INTELLIGENT SYSTEM
Colloquium SC D2 June 2005 Cuernavaca, Mexico
The diagnosis system module is a typical intelligent system, i.e., it contains a knowledge base, an inference mechanism and an output. The knowledge base is a Bayesian network representing the probabilistic model that relates all the variables. The network is constructed from a data set and using an automatic learning program. The inference mechanism is the propagation of probabilities algorithms, and the output is a vector with the probability of failure of all the variables. From a functional point of view, the diagnosis has two tasks: fault detection and fault isolation [3]. Figure 1 shows the general architecture. The learning module receives a data set and produces a Bayesian network to be utilized by the detection module. This module is the inference mechanism mentioned above. The detection module reads data from the plant through the client-server application. Real time data is utilized as evidence in the propagation, so apparent faults are detected. The list of apparent faults is the input to the isolation module. The isolation module utilizes a causal model and produces the final output of the diagnosis system, namely, a vector with the probability of failure of all the variables in the system. This vector is transmitted to the graphical user interface (GUI) for indication to the operator of the plant. Notice that the diagnosis is carried out in a cycle between the detection and isolation modules until all the variables have been diagnosed.
LEARNING
NET
DETECTOR
ISOLATOR
GUI
REAL TIME DATA
Figure 1. General architecture of the diagnosis system.
The planning system (figure 2) which is widely described in [4], has two modules: the data to knowledge mapper and the search algorithm module. The mapper is formed by the production system, the working memory and the rules. The production system consults the value of the variables and triggers the corresponding rules that produce logical expressions stored in the working memory. This working memory represents the current state of the process. For example, when the variable VL65 has the value of logic one, the formula (main-switch state ON) can be inferred. Additionally, a set of rules can be included to store a theory of causality in the domain. For example, if the formula (main-switch state ON) is included in the working memory, then it can also be inferred that (400KV-bus state ON) and (maintransformer state ON). Thus, the knowledge base includes all the rules that may generate a complete theory that reflects the current state of the plant. This theory is stored in the working memory of the production system. Also Fig. 2 shows a goal module that can be considered as
Colloquium SC D2 June 2005 Cuernavaca, Mexico
part of the working memory. The goal formulas are determinant to the search algorithm in the plan formulation.
Base of ACTs
Goals
Planning algorithm
ACTs
Working memory (state of the process)
Production system
On-line database
rules
Real time data from plant
Figure 2. Architecture of the planning system. The planning algorithm uses the working memory with the state of the plant, the current goals and the knowledge base of the operations of the plant codified in the formalism described below. The search algorithm uses all these elements in order to find the plan. In the first prototype of this planner, the planning algorithm executes an exhaustive search. Search is made between the conditions and purposes of all possible actions in the knowledge base. The plan is simply a list of the actions that has to be followed by the operator, in response to a specific current state with a specific goal. All of the information about the current plant state was obtained on-line using the Client-Server application described in next section.
4.0. TURBOGAS SIMULATOR SYSTEM The TG simulator system (figure 3) is integrated by a signal conditioning system, a programmable logic controller, an operation station, and a supervision station. The simulator contains a dynamic model of the turbogas process. The mathematical model is a group of logic, algebraic and differential equations programmed in high level computation language. With this model is possible to reproduce or emulate the behavior of a generation unit under different operation situations, such as startup, synchronization and generation stages. Furthermore, it reproduces the main transients that can happen in the turbogas unit. The simulator was developed in “C” programming and it is running in an industrial computer. This computer includes acquisition boards for the analog and digital input-output signals. The signal conditioning system is a physical interface that allows connection and data exchange between the TG simulator and the programmable logic controller. Conditioning consists of a number of boards to adequate the levels of voltage and electrical intensity signals sent between the simulator and the controller.
Colloquium SC D2 June 2005 Cuernavaca, Mexico
The programmable logic controller (PLC) is an industrial controller S7-400. In the PLC, the control and diagnosis functions, fault corrections, actualization of the system input-output signals, temporization and communications are programmed. The control functions programming in the PLC was performed using ladder and functional diagrams and structured text. Supervision Station
Intranet Network Operation Station
Signal conditioning PLC S7-400 TG Simulator
Figure 3. TG simulator system The operation station is a personal computer (PC) with the graphical interface for the control system operation and the OPC client-server model. The graphical interface allows the plant operator to execute sequences of operation and supervision routines. Through this interface, the user can perform startup, stop, synchronization and generation operations. The control panel in the operation station provides historical records, alarm displaying, tendencies and graphical representation of the process variables. This graphical interface was developed in InTouch, which is a platform specially dedicated to develop human machine interfaces (HMI). The control panel enables plant operator capabilities of visualization and interaction with the control system. A RS232-MPI (Multi-Point Interface) adapter is used as a connection with the PLC. The adapter is connected to the PC serial port and the controller MPI port. The supervision station is a PC where the intelligent system is allocated, and interfaces to communicate, access and transfer data are installed. It also provides a mean for graphical data representation and assistance during plant operation of the turbogas unit. The programming tools used for developing these applications include LabVIEW and Java. Operation and supervision stations are connected by a 10 Mbps local area network.
5.0. SYSTEM INTEGRATION USING OPC TECHNOLOGY The integration of the intelligent system components and the turbogas simulator system are based on a client-server model. In this integration we had to develop different software
Colloquium SC D2 June 2005 Cuernavaca, Mexico
applications and we had to use commercial software such as TOP Server and OPCLink. The objective of these applications is: - Access, communication and data exchange in real time with the PLC - Plant operation by the control system and graphical interaction with operators - Concurrent data transfer between applications running in different development platforms - Graphical display of results - Assistance to the plant operator The software architecture (figure 3) is composed by graphical user interfaces, client-server applications and the intelligent system components. The PLC interfaces were property of its manufacturer. Graphical User Interfaces DataSocket Server
Intelligent Diagnosis Java Link Intelligent Planner
LV Client
OPC Server (TOP Server)
OPCLink
Operation GUI (InTouch)
PLC S7-400
Figure 3. Components integration The intelligent system components usually demand control system information in real time, in order to submit this requirement, an open communication that allows interoperability with the device control is necessary to use. OPC is a common industrial standard for sharing data between industrial controller and software applications develop in different programming languages. In OPC client-server architecture, the client establishes a link with the server using COM Microsoft technology. Multiple clients should communicate simultaneously using only one server. The OPC server is a critical element in the system because it permits read/write operations from the process variables, the OPC server used in our system is a TOP Server S7-MPI. TOP Server is a commercial driver, it communicates in serial way to PLC S7-400 through RS232MPI adapter. Two important functions of OPC server are: 1) Connection and data access of process controller, b) data provider to the client applications of the system. This driver is installed in the operation station and it was configured for accessing the PLC process control database. In this system, clients are local or remote applications that request data to the TOP Server using an OPC specification. Our software architecture has two clients: OPCLink and LV Client. OPCLink is a commercial client installed in the operation station with the TOP Server. LV Client is a remote client installed in the supervision station and it is an application developed in graphical programming.
Colloquium SC D2 June 2005 Cuernavaca, Mexico
Wonderware-OPCLink is a support bridge for the OPC protocol. OPCLink is a gateway driver that process and open and OPC protocol to be understood by Wonderware compatible software and at the same time is a high-performance SuiteLink server for InTouch. OPCLink enables communications and allows access to the TOP Server as a data provider to Intouch operation interface. OPCLink checks periodically the connection to TOP Server and also acts as a data monitor. Wonderware-SuiteLink is a TCP/IP-based communications protocol that provides highly reliable data communication with InTouch. LV Client is a remote client that performances two actions: It connects to TOP Server to read the control variables from the industrial controller database and it is a provider of this information for the intelligent system components and graphical user interfaces. LV Client reads analog and digital variables of process and makes public these data to a DataSocket server. In this way, data are replicated into a local server of the supervision station which shares them to subscribe applications (planning, diagnosis, interfaces). LV Client verifies periodically the remote connection to TOP Server and updates DataSocket server. Datasocket implements an easy-to-use, high-performance programming tool designed for sharing and publishing live data among LV Client and subscribing applications. Java Link is an application for data transfer and communication among Datasocket server and the intelligent system components. The function of this link is to process requests from the planning and diagnosis modules. Java link is based on TCP/IP technology and acts as a data interface for applications in different platforms like Java and LabVIEW. Communication is based on messages using a proprietary protocol. The types of messages includes: Request of values of process variables, graphical presentation of advices to operator sent by the planning module and data writing on server as a result of intelligent diagnosis. Graphical user interfaces are applications developed for graphical representation and interpretation of results from intelligent planning of operation actions and intelligent diagnosis of system faults. Diagnosis interface shows the turbogas sensor validation and includes control process variables. Each variable has numerical and graphical indicators for real value and validation result. Planning interface presents advices to operator to detect the cause of a fault and to operate the turbogas unit under this situation. The interface also shows the goal condition, and the time available to perform the recommended action.
6.0 EXPERIMENTAL RESULTS The system integration has been used in diagnosis and plan generation experiments at the laboratory. The simulation executed for this experiment consists in a load increasing from 2 MW to 23 MW. Six analog signals were sampled every half second so a number of 2111 records were obtained during the 20 minutes that this procedure took [3]. (1) the speed variable represents the measure of the velocity of the turbine in revolutions per second (RPS). (2) the power variable is the measure of the mega watts generated, (3) temp is the exhaust gas temperature in the turbine, (4) variable gaspress is the gas fuel pressure, (5) gasvalv is the position of gas control valve, and (6) variable gasdemd is the gas valve demand.
Colloquium SC D2 June 2005 Cuernavaca, Mexico
When the diagnosis system founds an abnormal behavior in the monitored variables, for example in the temperature sensor 2, it writes a code in the ttxd2 variable (exhaust gas temperature 2) of the real time data base. The planner contains a rule that explains that if the ttxd2 variable has a number 2, then a condition must be issued that establishes that the temperature sensor 2 is in a state of failure. Once that the mapper declares this failure, then the planner starts building a corrective plan based on the environment conditions in the knowledge base.
7.0. CONCLUSIONS AND FUTURE WORK In this work, we presented a communication system based on client-server architecture for the integration of an intelligent system into a turbogas simulator. We first described the power generation problem domain and the necessity to integrate the software modules of an intelligent system composed by the diagnosis and planning systems into a turbogas unit simulator. The simulator provided a sensor model to measure power, pressure, temperature, velocity, valve positions, in the turbogas system. We also presented each intelligent module and the way they interact through our solution to detect sensor failures, and formulate a plan to move the plant into an useful and safe condition. A detailed presentation of the communication system was provided explaining the intelligent system-simulator integration. We described our laboratory testing platform and provided an example of the expected system behavior. Despite the difficulties to integrate academic tools with real-world applications, we have surprisely found very satisfactory results. In the early future, we would like to improve our communication architecture in such a way we could uniform the development language, and decrease the communication links. The ideal communication system in process control should only have one OPC server and any amount of platform independent OPC clients. 8.0. BIBLIOGRAPHY
[1] M. E. Agueda and P. H. Ibarguengoytia, “An architecture for planning in uncertain domains,” in Proc. ICTAI-01 Thirteen International Conference on Tools with Artificial Intelligence, Dallas,Tx USA, 2001, pp. 152–159. [2] M. E. DesJardins, C. L. Ortiz, E. H. Durfee, and M. J. Welverton. A survey research in distributed, continual planning. AI Magazine, 20(4): 13-22, 1999. [3] González Noriega L. Jesús and Pablo H. Ibargüengoytia, “An architecture for real time diagnosis of gas turbines”, Advances in Artificial Intelligence - Iberamia 2002, Lecture Notes in Artificial Intelligence LNAI 2527, Springer, pp. 795-804, Sevilla Spain, November 2002. [4] Elí Bulmaro Zenteno and Pablo H. Ibargüengoytia, “Knowledge acquisition and management system for an intelligent Planner”, MICAI-2004: Advances in Artificial Intelligence, Edited by R. Monroy, G. Arroyo, L.E. Sucar y H. Sossa, Lecture Notes in Artificial Intelligence LNAI 2313, Springer, pp 159-168, México DF., México, April 2004.