SOFTWARE AGENTS IN HANDLING ABNORMAL SITUATIONS IN INDUSTRIAL PLANTS

Transcription

1 SOFTWARE AGENTS IN HANDLING ABNORMAL SITUATIONS IN INDUSTRIAL PLANTS Sami Syrjälä and Seppo Kuikka Institute of Automation and Control Department of Automation Tampere University of Technology Korkeakoulunkatu 10, Tampere Finland and ABSTRACT Software agents have recently gained a lot of reputation in software engineering. These autonomous actors can provide, for example, more flexibility than many other programming concepts and they fit well for complex situations. The abnormal situation handling in industrial plants is a challenging application area due to the complexity and dynamical nature of modern processes. Agents seem to have great potential in the field. In this paper we first introduce the basic agent concepts and the application area. Then we discuss the possibilities of agents in it and describe a test scenario we have made. KEY WORDS multi-agent systems, BDI-model, abnormal situation handling, industrial plants 1. Introduction This paper is based on the work made in a project called Improving the Handling of Abnormal Situations in Industrial Plants (abbreviated POHA based on the Finnish name [1]). One work package of the project involves software agents. The TEKES-funded project is carried out by Finnish research centers VTT and Tampere University of Technology, along with some industrial companies. Agents have recently become quite popular in the software developing field. Sometimes it feels that almost everything is called an agent. The term has somewhat suffered but when interpreted correctly (i.e. strictly) the paradigm has many useful unique qualities. Agents seem to fit well for relatively complex decision situations and therefore it is reasonable to try to apply them to handling abnormal situations in industrial plants. The structure of this paper is following: short definitions are given for basic agent concepts (BDI-model is emphasized), then follows a discussion about abnormal situation handling using agents, the next section describes a test scenario that we have implemented and finally the conclusions are drawn. 2. Software agents forming a multi-agent system 2.1 What is a software agent? Software agent is a software component that has characteristics, some of which concern agent s internal capabilities and some relate to the agent s external behavior. Internally, agent has some decision making capabilities. Externally, the agent reacts to situations, takes initiative influencing its surroundings and may even be social. According to [2] and [3], the following features characterize agents: Intelligence refers to agent s ability to make reasonable decisions based on its observations and internal knowledge. Autonomy means that an agent can act on some problem based on its (often imperfect) observations without a constant guidance from user. Reactivity means that the agent reacts to events happening in the environment. Good reactive capabilities are essential when the agent operates in an environment it is not familiar with. Proactivity means that the agent does not just wait for events to happen. It also takes initiatives in order to advance its goals. Sociality refers to the human-like way the agent interacts with other agents (and sometimes with the user). As an agent is a conceptual entity (not an implementation technique), using agents does not automatically add any intelligence to an application or system. Instead, the agent-concept provides a flexible and scalable platform for theories of distributed artificial intelligence to be implemented

2 2.2 BDI-model of practical reasoning BDI-theorem is among the most popular theorems in describing the internal behavior of an agent. It was originally introduced by Bratman ([4]). According to the model, a BDI-agent has as its mental qualities beliefs, desires and intentions. Beliefs represent what the agent thinks is true regarding the environment. As a result of agent s own observations and what others have told, the beliefs contain an element of uncertainty. But still the agent acts on its beliefs. Desires represent the target state of the world according to the agent. Desires do not, however, activate any external behavior since the agent might have conflicting desires or it might think that the desires are currently impossible to fulfill. Intentions represent those desires that the agent has decided to pursue. Thus intentions are the force that makes the agent to reason and act. The agent can be thought to commit internally to act for its intentions. An agent should also know when to drop an intention (this is discussed in [5]). Even though the model is quite intuitive and clarifies the handling of agent s behavior, it is by no means selfevident how it should be implemented. There are many different implementation frameworks that include the BDI-semantics. Many of them deal with goals, that have similar meaning as desires, and plans that are possible ways to achieve goals. Goals that are adopted mean usually about the same as intentions. More information about BDI-concepts can be found for example in [6]. 2.3 Multi-agent systems Sometimes the entire application consists of a single agent or a few agents that act completely independent of each other. However, the advanced social abilities of the agent concept make it possible for many agents to interact with each other in a complex way. An application of many agents interacting with each other is called a multi-agent system. The main issues for advanced agent interaction are agent communication language, ontology and interaction protocols. Agents communicate with each other by using some welldefined communication language that has semantics rather close to human language. These languages make it possible, for example for an agent to query some information, request action it thinks some other agent can do, or even call for help. Nowadays, maybe the most popular agent language is Agent Communication Language (ACL) defined by FIPA ([7]), an organization that does useful standardization relating to multi-agent systems. However good the used language is, it is useless if the speakers can not agree on the terms and their meanings. This is what ontology defines in a multi-agent system. In the future, if we want agents made by different vendors to work together, we must have some general applicationarea-related ontology definitions. The common language and ontology are still not enough to make agents to interact correctly, at least in more complicated situations. The overall behavior is easily chaotic, if the agents do not comply with some sort of conversation patterns. These patterns are implemented as interaction protocols and they define the course of conversation and possible messages in different stages of it. One of the most famous interaction protocols is Contract Net protocol, where an initiator agent asks other agents for proposals relating to some problem. Then the other agents, who received the call-for-proposals-message, answer by giving a proposal (possibly including some sort of cost info) or refusing to propose if they can not or will not help. Next, the initiator agent evaluates the received proposals and sends back messages indicating which, if any, of the proposals were accepted. Demands to individual agents capabilities vary relating to the situation and the nature of the application area. Sometimes it is natural for agents to work together, giving their best effort while sometimes it is suitable for agents to compete with each other and behave selfishly. The examples of the latter include many applications of e- commerce and game industry. In the field of process control and abnormal situation handling, however, the cooperative approach seems to be more useful. 3. Agents in abnormal situation handling Application areas of agents include managing information in the Internet and other systems, electronic commerce, business process management, entertainment, manufacturing and process control (a summary can be found for example in [2]). The process control application area contains also our challenging field, the abnormal situation handling in industrial plants. 3.1 Abnormal situations in industrial plants There can be many different types of abnormal situations in modern industrial plants. All the situations in an industrial plant not belonging to the basic running state are, in fact, abnormal situations. For example, start-up and shutdown procedures, producing uncommon product items and running beyond the capacity recommendations 8

3 are (usually less known) abnormal situations. More familiar are situations caused by malfunctioning process equipment and human errors. These present many challenges for the automated control system. Many abnormal situation problems can be solved with correct use of traditional safety features built into the process control system, such as function blocks containing safety-related parameters. Among the most critical safety mechanisms in many processes are interlocking mechanisms and protection systems. An interlocking mechanism tries to prevent harmful operations from being executed and protection system detects potentially hazardous states in plant or equipment and tries to return a safe state, often by shutting some part or the whole system down. It is, however, often so that the processes are so complicated that not all abnormal situations can be anticipated beforehand during the design phase. What makes the situation even more difficult is the fact that often the processes are under constant change, due to changing production demands. The complexity and dynamical nature of many modern processes make the traditional approach inadequate. Many advanced approaches have therefore been developed. These include, for example expert systems and operator support features of a control system. Also software agents have been seen by researchers as a promising new technique. 3.2 Potential advantages of agents Agents are by definition autonomous, initiative-taking and reactive. In addition they exchange information and interact with each other using a mechanism far more advanced than basic method-calling between software objects. All these features, correctly implemented, can give a single agent and the whole multi-agent system great flexibility. Flexibility is, indeed, what many of the other abnormal situation handling techniques lack. Agents provide a new way of thinking because they can increase the level of abstraction and give thus a different view to complex problems. With agents we do not need to code knowledge about everything relating to abnormal situations in one place. Instead the agents may represent different parts of the system and form a hierarchy where every agent has different responsibilities and abilities. An agent may, for example, represent some part of process equipment, having knowledge about its behavior and qualities, some agent may have special knowledge about the produced material etc. By using a multi-agent conversation, the agents can try to find the actual reasons to the encountered abnormal situations and even find some ways to overcome them. Standardized interaction protocols for different purposes play significant role in this. One concept that is often emphasized in the field of abnormal situation handling is graceful degradation. It means that when not possible to run the process at its full power or quality, it should be run as well as possible. This quality can be achieved with agents through, for example, a negotiation procedure, where agents come to a compromise. Agents can (and should) be distributed around the network, which helps to make the system itself more fault tolerant. This way, also the calculation and memory resources are distributed. If the multi-agent system is implemented properly, only the associated agents are changed or reconfigured after a change in the process configuration. The agreed interaction protocols work as before. Even the participants in those protocols may automatically change when making use of mechanisms like the directory facilitator (DF) of FIPA-compliant agent platforms. The DF works as a yellow pages service where the agents can register descriptions of themselves. One should note that agents are not by any means deterministic by nature. Therefore they should not be performing real time control or other critical operations including hard time limits. Instead, agents could be used as kind of intelligent analyzers and abstract actors. 3.3 Other research in the field There have already been several research studies and even a few commercial applications regarding agents in process control and manufacturing. Two of the most famous are described below. One of the most successful research projects of agents in the field is ARCHON. In it an architecture was developed to make full use of different legacy expert systems that could not exchange information by themselves ([8]). The approach had specialized agents making use of different expert systems and solving data exchange problems. ARCHON has been successfully used in diagnosing faults in electricity transfer networks and also in CERN s particle accelerator. In a more recent IST-project called PABADIS, a new agent based plant automation concept was developed ([9]). The concept aims to provide a way to replace the traditional MES (Manufacturing Execution System) with a more advanced distributed agent architecture. 4. A Test Scenario In Tampere University of Technology, at the Institute of Automation and Control ([10]) we developed a small test scenario in order to understand better how agent systems may be implemented. 9

4 4.1 Process and scenario The used process is a part of a simulated batch process that produces a medical substance (called Prokutamin). A Java-based simulation of that process and a control system for it was developed in a separate TEKES-project OHJAAVA-1 ([11]). In our abnormal situation scenario, we have agents representing different items of the process equipment (one agent per item): valves, tanks and pumps. We also have an agent representing a batch control component. The agents were added on top of the existing control system so that the control system is not dependent on them. An UI was built through which it was possible to cause four different faults to the process equipment. The faults included breaking a valve and causing a tank leakage. The agents then noticed a symptom (the tank level failing to rise fast enough) and tried to find its cause by starting a multi-agent conversation. The agent representing the batch control unit also performed a simple compensation procedure, when needed. 4.2 Implementation Java was chosen as the implementation programming language since many agent frameworks and toolkits have been made for Java environment. These frameworks take care of many of the low level implementation issues so that the programmer can focus on the application specific problems. JADE (Java Agent DEvelopment framework [12]) was chosen as the framework, especially with Jadex plug-in ([13]). JADE is probably the most popular open source agent framework currently available. It is FIPA compliant and is being actively improved. Jadex is a promising plugin that implements the BDI-model on top of JADE. In this way we get both the important FIPA-compliance and advanced handling of internal behavior of an agent. Jadex includes also a handy XML-based agent definition file (ADF) mechanism that makes it possible to define the configuration of each agent before it is launched. The scenario itself was implemented in two different ways: first by using a heuristic style and then by using an applied contract net protocol. In the first implementation, the agent that represents the tank notices that the level of the tank stops rising or rises too slowly. It checks from its ADF which agents represent the inputs and outputs of the tank. It then queries the position of those actuators from their representatives and tries to conclude what item was possibly broken (which was in the wrong position). If the reason could not be concluded from that information, it will carry out a simple leakage test of closing the inputs and outputs and observing the level for a while. Finally, it tells the concluded diagnosis to all agents interested, in this case to the agent representing the batch control component. Since the agent representing the batch control component (and no one else) has power over the controlling of the system, it is logical that it considers and carries out the possible compensating procedures. In this case, depending on the diagnosis, it is sometimes possible to complete the batch sequence with reduced batch size. And so the agent modifies the current batch size and cancels the waiting batches, if any. Some details of this approach: The level tracking was made with configurable rule objects. Before the leakage test was carried out, permission was asked from the agent representing the batch control component. The agents of certain qualities, like those interested in receiving fault diagnoses, were searched through the DF. The second implementation differed on the part of forming a diagnosis. The principle is depicted as a (simplified) example sequence diagram in picture 1. When the tank representative noticed the symptom, it initiated a contract net interaction protocol, describing the symptom to all agents in the same process unit. The participating agents then evaluated if their pieces of process equipment could cause the problem and sent proposals accordingly. tank agent valve agent1 notices the symptom valve agent2 pump agent batch control agent BROADCAST (all agents in process unit): CFP (description of the symptom) REFUSE PROPOSE (possible reason) REFUSE PROPOSE (value tracking test) after waiting time: forms the diagnosis ACCEPT PROPOSAL REJECT PROPOSAL Picture 1: Applied Contract Net Next, the initiator evaluated the proposals and concluded the diagnosis if possible. This time the leakage test was first proposed and then performed by the batch control component representative, but only if the other proposals could not solve the problem. 4.3 What was learned? One lesson was that the software designer has to learn a new way of thinking. BDI agents are very different to design and program than basic object oriented software. One should also try to find genuinely agent-like solutions 10

5 to problems. For example, the first solution of our test scenario was less agent-like than the second one. The use of FIPA-compliant agent frameworks has many advantages. The FIPA standards seem to be the most well-known and widely supported agent standards available. So for future compliance, it is beneficial to support FIPA. And without any frameworks it would, in most cases, be too difficult and time consuming to implement the low level functionalities and agent s basic architecture. The BDI-model (as implemented by Jadex) was found to be an intuitive and useful way of handling the behavior of an agent. However, implementing agent software is still by no means easy. The frameworks and their documentation should be further improved. About the total system architecture, it can be said that, at least for now, it suits well to add the agents as a kind of separate layer on top of the basic control system. This is because a more intimate integration can make the use of existing control software impossible. Of course, a loose integration has its own problems in exchanging data between the control system components and agents. Software component techniques, especially OPC, help in this. 5. Conclusion Maybe the biggest advantage of using agents in handling abnormal situations is the high abstraction level that agents provide. With loosely connected autonomous actors in the program we have more freedom in solving problems than with traditional, tightly coupled objects or components. Many of the new DAI techniques fit well for agents. Agents, especially when using FIPA-based frameworks, also make the distribution transparent. A programmer does not need to know where exactly some agent is located at every instance of time of execution; the framework takes care of delivering the messages to the right address. Furthermore, with using registered services the programmer does not even need to know all the names and abilities of different agents. There are also negative aspects in using agents that mainly relate to the immaturity of the field. Although agent theories themselves are already quite advanced, the frameworks, tools and standards are still largely untested and lack in quantity, as well as in quality of properties. The documentation also often lacks important details and examples (even though the tool is open source, it should not mean having to read through the code in order to learn how to use it). This all makes the programming and testing of agent applications rather difficult. How could the situation then be improved? The communities and organizations around the standards and frameworks are active and many of the deficiencies will be solved over time. Among the most important things needed, as seen by the writers, is easy-to-use developing tools for the most popular agent frameworks. For example, a good plug-in for the Eclipse developing environment would make the threshold of making use of agent technology much lower. This is especially important when considering industrial and other commercial applications. In conclusion, application areas of complex problems need to have more advanced software programming concepts and techniques than object and component oriented programming. Agents seem to be a promising one. References: [1] Improving the Handling of Abnormal Situations in Industrial Plants, [referred ]. [2] N. R. Jennings & M. Wooldridge, Applications of Intelligent Agents. N. R. Jennings & M. Wooldridge (eds.), Agent Technology: Foundations, Applications, and Markets, Berlin, Springer-Verlag, 1998, [3] M. Wooldridge, Intelligent Agents. G. Weiss (ed.), Multiagent Systems: A Modern Approach to Distributed Artificial Intelligence, Cambridge, The MIT Press, 1999, [4] M. E. Bratman, Intentions, Plans, and Practical Reason (Cambridge, MA, Harvard University Press, 1987). [5] P. R. Cohen & H. J. Levesque, Intention Is Choice with Commitment, Artificial Intelligence, 42(2-3), 1990, [6] M. Georgeff, B. Bell, M. Pollack, M. Tambre & M. Wooldridge, The Belief-Desire-Intention Model of Agency. J. Müller, M. Singh & A. Rao (eds.), Proc. 5 th International Workshop on Intelligent Agents V: Agent Theories, Architectures and Languages (ATAL), Heidelberg, Springer-Verlag, 1999, [7] Foundation for Intelligent Physical Agents, [referred ]. [8] D. Cockburn & N. R. Jennings, ARCHON: A distributed artificial intelligence system for industrial applications. G. M. P. O'Hare & N. R. Jennings (eds.), Foundations of Distributed Artificial Intelligence, John Wiley & Sons, 1996,

6 [9] PABADIS - Plant automation based on distributed systems, [referred ]. [10] Tampere University of Technology, Institute of Automation and Control, [referred ]. [11] Ohjaava tavoitteena tulevaisuuden automaatioarkkitehtuurit, [referred ]. [12] Java Agent DEvelopment framework, [referred ]. [13] Jadex BDI Agent System, [referred ]. 12