Detection of Anomalies in a Transport System using Automation Agents with a Reflective World Model Mathieu Vall´ee
Munir Merdan
Pavel Vrba
Institute of Computer Technology, Vienna University of Technology, Vienna, Austria Email:
[email protected]
Automation and Control Institute, Vienna University of Technology, Vienna, Austria Email:
[email protected]
Rockwell Automation Research Center, Pekarska 10a, Prague 155 00, Czech Republic E-mail:
[email protected]
Abstract—Manufacturing systems need to become more flexible and agile in order to address permanently changing requirements. Agent-based manufacturing control systems are envisioned as a relevant solution. However, designing and deploying such systems is complex, and raises some concerns regarding safety, robustness and emergence of unforeseen behaviors. To address these concerns, we propose an approach in which automation agents are created by extending existing hardware and real-time control software with advanced capabilities for cooperation and run-time diagnosis. The main feature of an automation agent is the reflective world model — a symbolic model of the agent’s world, including the agent itself. In this paper, we present the application of a reflective world model for automation agents to detect some anomalies in a pallet transport system. This work shows the suitability of the proposed approach for designing advanced run-time diagnosis capabilities, while preserving existing hardware and control software.
I. I NTRODUCTION The increased complexity of current manufacturing systems issued by dynamic market changes and technological challenges together with internal dynamic conditions (e.g., process failures or machine breakdowns) as well as permanent demands for flexible and fault-tolerant functionality makes their management and control very difficult and challenging. Agent technology is recognized as a promising paradigm for design and building the next generation of manufacturing systems [1]. This technology offers a convenient way for modeling distributed processes and systems, making them decentralized, thereby reducing the complexity, increasing flexibility and enhancing fault tolerance [2]. Although confirmed as a promising approach the widespread adoption of agent-based concepts by industry and governments is still missing due to a “pioneer” risk, which escorts every new technology that has not been proven in large scale industrial applications [3]. In this paper, our contribution is in extending an existing manufacturing control system with automation agents based on a reflective world model [4], thus providing additional run-time diagnosis and cooperation capabilities. More specifically, we investigated mechanisms for detecting anomalies in a transport system, without modification of the existing hardware, sensors and low-level control. By creating and maintaining an accurate representation of the world and of itself, an automation agent can detect anomalies during the transport of pallets and cooperate with other agents to identify their cause and to prevent
978-1-4244-5697-0/10/$25.00 ©2010 IEEE
489
them. We implemented this approach using the Manufacturing Agent Simulation Toolkit (MAST) [5]. The structure of this paper is as follows. Section II briefly positions existing approaches for designing flexible manufacturing control systems. Section III recalls the generic architecture of an automation agent. Section IV details the world model representation for an agent monitoring the transport of pallets on a conveyor. Section V discusses more advanced examples of agents detecting and preventing anomalies in a pallet transport system. Section VI presents our implementation in the MAST simulation environment. Finally, section VII concludes this paper. II. A PPROACHES FOR D ESIGING F LEXIBLE M ANUFACTURING C ONTROL S YSTEMS When designing a flexible manufacturing control system, it is necessary to take into account various requirements, e.g. regarding hardware integration, real-time control of individual machine and system-wide coordination. The holonic and agent-based approaches have been successfully investigated to address these requirements [6]. Several prototypes have been developed [5], [7]–[9], so that some generic knowledge about flexible manufacturing design is already available. Previous work has particularly pointed out the need of using simulation for evaluating flexible manufacturing systems more effectively, at lower costs and safely [5], [7], [8]. Another important aspect is the identification of distinct levels of control [10]: low-level control is dealing with hardware integration and real-time control, while high-level control is dealing with cooperation among machines in the system. Finally, several work have recognized the benefits of using established agent-based standards and technologies for developing the high-level control [5], [10]. Attempts in this direction have been particularly concentrating on the adoption of the FIPA standards for agent management and communication. Recent works have also been investigating the use of ontologies for representing knowledge in a well-defined and interoperable way [9]. Despite these promissing steps, these prototypical systems have been tailored to solve particular problems. As a consequence, a generic approach governing the design of flexible manufacturing systems is still not available.
High-Level Control Communication Management
Decision Making
World Model Repository
Low-Level Interface
Low-Level Control Fig. 1. Overview of the high-level control components within the automation agent architecture.
In the agent community, work on agent-oriented software engineering (AOSE) has been investigating the design of adaptive and flexible systems based on the agent paradigm. Several methodologies have been proposed, and evaluation and comparison have been performed. Although there were attempts at transferring these works in the manufacturing domain [11], a better understanding is still necessary. In particular, some central concepts in AOSE are heavily tied to a cognitive agent architecture (such as BDI [12]): an agent is designed to achieve a particular goal (e.g., reaching a given place for a robot) and can adapt its plans to handle unpredictable conditions (e.g., avoiding moving obstacles). This goal-oriented view may not be suitable for manufacturing control, for which an agent-controlled machine rather needs to continuously perform activities (e.g., transporting pallets for a conveyor), while adapting to changes in internal and external conditions (e.g., failure of a motor). Another shortcoming of most AOSE approaches is the strongly top-down design process, which focuses on creating a dedicated system of software agents to fulfill requirements. Reuse of existing hardware and real-time control software is seldom considered. Our work complements existing solutions by investigating more suitable concepts and representations for manufacturing control systems III. G ENERIC A RCHITECTURE OF AN AUTOMATION AGENT We now recall the concept of automation agent [4], which serves as the building block of a distributed intelligent control system. One key aspect is that the agents are not expected to completely replace the existing automation system, but rather they will extend the existing components. In particular, we see the automation agent as an extension of the automation component [13], where the automation agent has additional capabilities for explicitly representing its own world and reasoning about it. These capabilities are especially useful
490
for making diagnosis and coordinating with other agents. In [4], we introduce a generic architecture of an automation agent. This architecture serves as a basis for integrating new capabilities into existing systems. For illustration purpose, we will use the example of an automation agent built on top of a conveyor, which is part of the “testbed for distributed holonic control” 1 . Such a “conveyor agent” consists of three layers: (i) the physical conveyor, i.e., a mechatronic component composed of a conveyor belt, a motor and a power relais, (ii) a low-level control layer (LLC), which is mainly in charge of controlling the speed of the conveyor and reporting hardware failures, (iii) a high-level control layer (HLC), which enables the agent to make diagnosis and to coordinate with other agents based on its representation of the world. Within the testbed, the conveyor is in relation with other machines such as intersections, which are able to detect incoming pallets and direct them towards their destination. One of the main features of the automation agents is the distinction between HLC and LLC within each agent. A fundamental distinction between the layers is the ability of the LLC behaviors to execute in real-time, while the HLC might require longer computation, interactions with others agents or even interactions with human operators. In this paper, we focus on the HLC. Fig. 1 depicts the inner architecture of the HLC. It is composed of four main modules: •
•
•
•
The world model repository contains a world model, i.e., a symbolic representation of the world of the agent. The world model repository provides facilities for updating and querying the world model. The low-level interface enables the agent to use functionalities provided by the LLC. It especially provides facilities for receiving event notifications about the current operations of the LLC and for requesting particular operations from the LLC. Because various kinds of LLC may exist in a system, we use a unified low-level interface as described in [15]. The communication manager provides facilities for managing communication with other agents. The communication between agents depends on the knowledge they have to exchange and on the tasks they have to achieve collectively. The decision-making component is in charge of reasoning about the states of the world and deciding what to do (e.g., communicate with other machines, request an operation from the LLC, issue notifications to an operator). Event notifications generated by the low-level, by communication with other agents or by the world model trigger the decision-making procedures. These procedures then update the world model, request operations from the LLC and communicate with other agents.
1 Further
description of the testbed can be found in [14]
Situation Model
Activity Model
Ontology Activity
InputNode
OutputNode subClassOf
Conveyor hasInputNode
Classification of activity types
-isFailed -length -speed 1 * hasCurrentPallet
Observing Pallet Entering
hasOutputNode
Transporting Pallet
Observing Pallet Leaving
Detecting Motor Failure
subClassOf Observing Pallet entering from i1
Pallet
Transporting Pallet from i1 to i2
Observing Pallet leaving to i2
Detecting Motor Failure of c1
Facts type: "Transporting Pallet from i1 to i2" timing: (t0, t1=t0+d)
(c1 isA Conveyor) (c1 hasInputNode i1) (c1 hasOutputNode i2) (c1 hasCurrentPallet p123) (c1 hasCurrentPallet p234) (c1 isFailed false)
dependency: requires type: "Observing Pallet entering from i1" timing: (t0, t0)
dependency: preventedBy type: "Detecting Motor Failure" timing: (t0, t1)
Expectations / Observations
dependency: requires type: "Observing Pallet leaving to i2" timing: (t1, t1+1)
Type: "Observing p123 entering from i1" Timing: (15, 15)
Fig. 2.
Reflective world model of the conveyor agent.
IV. R EFLECTIVE W ORLD M ODEL OF AN AUTOMATION AGENT The world model plays a central role in the architecture of an automation agent. In this section, we detail the introduction of a world model for an automation agent capable of monitoring of pallets entering and leaving a conveyor. A. World Model Representation Fig. 2 illustrates the world model for the conveyor agent example. The world model consists of two parts: • The situation model (left) holds knowledge about the agent situation. The situation of an agent consists both of its own characteristics and its relations to other entities in the world. • The activity model (right) holds knowledge about activities of the agent. The situation model is composed of an ontology and a set of facts: • The ontology (top) is a model of the type of entities in the domain of the agent [16]. It defines relevant classes of entities as well as relations between entities. It also serves as a vocabulary for referencing these classes and relations, thus ensuring the consistency of the world model as well as the interoperability between different agents. For our example, the ontology defines that a
491
conveyor can have one input node, one output node, and a number of current pallets on it. Such concepts and relations can be extracted from existing ontologies, such as [14]. • The facts (bottom) express the current knowledge about the world. Facts are expressed using the vocabulary defined by the ontology. For our example, facts express that c1 is a conveyor, which has an input node i1 and an output node i2. It is important to note that facts expressed in the situation model do not intend to represent completely the world of the agent. They rather represent an abstraction of some meaningful aspects of the world, which can be used for realizing high-level control tasks. Although more complete and dynamic information about the world may be available at the low-level control, it is only processed in this layer, usually under real-time constraints. The activity model is composed of a classification of activity types and a model of expectations and observations: • The classification of activity types (top) models the types of activities in which the agent can be involved. Types are defined formally using description logics formulas and they are organized hierarchically based on the subsumption relationship [17] (noted subClassOf ). Primitive types are defined as direct subclasses of Activity. Derived types are defined by restriction of the primitive
•
types to take into account the actual world of the agent. For instance, the generic type “Transporting Pallet” is refined to the more specific type “Transporting Pallet from i1 to i2” corresponding to the case of the conveyor agent. The expectations and observations (bottom) is a model of the activities that are expected and observed by the agent. Expectations and observations are defined by the specification of a type (based on the classification of activity types) and timing. Timing is expressed using time intervals [18]. While observations can express a precise timing, expectations rather express constraints on their timing. Expectations are linked by dependencies, indicating how observations on one expectation can have consequences on other expectations. For instance, it is expected that “Transporting Pallet from i1 to i2” taking place between t0 and t1 requires both that “Observing p123 entering from i1” take place at t0 and “Observing p123 leaving to i2” take place at t1 (with a given tolerance). Additionally, it is expected that this activity would be prevented by “Detecting Motor Failure of c1” during the same interval of time.
B. Decision-Making using the World Model One of the main benefits of the reflective world model is the ability to detect anomalies between the expected and the observed activities. Fig. 3 illustrates this usage of the world model, which involves 5 main operations: 1) When an event is notified, the world model is updated with new information about the situation. 2) Part of the knowledge about the current situation is interpreted in terms of observation of an activity, if applicable. 3) The addition of a new observation triggers the verification of existing expectations, in order to find whether the new observation fulfills some of the expectations. 4) The addition of a new observation may also trigger the creation of new expectations, based on the dependencies between expectations. 5) Relevant changes and anomalies in the activity model are notified to the decision making component, which is in charge of initiating the appropriate actions. This is not only triggered by external events, but also by timing constraints on the expectations. C. Monitoring Pallet Transport on a Conveyor Based on the generic architecture and on the world model presented above, we now present some decision making procedures which enable the automation agent to monitor the transport of pallets on the conveyor. In the normal case, the following steps happen: 1) The conveyor agent first receives a message from its input node i1 indicating that the pallet p123 is leaving i1. Upon notification of this event, the conveyor agent deduces that p123 is entering. It consequently adds an observation of type “Observing p123 entering from i1”
492
1. update situation
Notification of event Decision Making
Fig. 3.
2. interpret as observation of activity
Situation Model 5. notify relevant changes and anomalies
3. verify existing expectations of activity
Activity Model 4. define new expectations of activity
Management of expectations and observations in the world model.
with timing (15, 15) to its world model. The timing is represented as an instantaneous time (time interval with same start and end) and the date corresponds to the message date 2 . 2) When the observation is added, the agent recognizes that it corresponds to an expectation of type “Observing Pallet entering from i1” (since p123 is a Pallet). As a consequence, it defines a new expectation of type “Transporting p123 from i1 to i2” with timing (15, 20), a new expectation of type “Observing p123 leaving to i2” with timing (19, 21), and a new expectation of type “Detecting motor failure of c1” with timing (15, 20). For these expectations, the end time is estimated from the length and speed of the conveyor. 3) After the pallet correctly reaches the following intersection i2, the conveyor agent receives a message from its output node i2, indicating that the pallet p123 is entering i2. Upon notification of this event, the conveyor agent deduces that p123 is leaving the conveyor so it adds an observation of type “Observing p123 leaving to i2” with timing (20, 20) to its world model. 4) As a consequence, the expectation of type “Observing p123 leaving to i2” and timing (19, 21) is verified. The expectation of type “Transporting p123 from i1 to i2” is also verified, because the two activities it requires are verified. The expectation of type “Detecting motor failure of c1” is proven unverified, as it would otherwise have prevented the transport of the pallet. As we see in the next section, this monitoring mechanism is the basis for detecting anomalies when a pallet does not leave the conveyor as expected. V. D ETECTING A NOMALIES WITH A S YSTEM OF AUTOMATION AGENTS The efficiency of a manufacturing system can considerably decrease when a particular component in the transport system fails. For instance, Merdan [19] studies the impact of diverse 2 Although this would be imprecise for real-time control, the HLC only needs to estimate time with a coarse granularity.
Time t0
Time t1
p123
Time t2
INTERSECTION
i1
CC3 i2 Stopper Sensor
Time t2
intersection from forwarding further pallets, so that to avoid this disturbance. These two examples indicate how the proposed approach provides a clean framework for enriching manufacturing systems with advanced run-time diagnosis and fault-tolerance capabilities. VI. I MPLEMENTATION
Fig. 4.
Case 1: Monitoring pallet entering and leaving a conveyor.
p123 i1
p124
p125
INTERSECTION CC3 i2
Stopper Sensor
Fig. 5.
Case 2: Monitoring number of pallets on a conveyor.
types of conveyor failures on a manufacturing system performance, measured in the number of finished products. In this section, we present how the monitoring mechanism described above enables a system of automation agents to handle some transport anomalies. We focus here on detecting if, when and which kind of failure or disturbance occurs — a necessary step towards more efficient and fault-tolerant manufacturing systems. Based on the monitoring mechanism presented above, a conveyor agent can detect that a pallet did not leave the conveyor as expected (Fig. 4). If it receives no confirmation that the pallet was detected by its output node i2, the expectation “Observing p123 leaving to i2” with timing (19, 21) is not verified. In that case, the conveyor agent can conclude that there is an anomaly. Nevertheless, two possible failures can cause this exception: (i) a pallet is missing or (ii) the input sensor of the intersection i2 failed. In order to clear this confusion, the conveyor agent transfers its expectation to the output intersection i2, so that i2 checks its world model regarding this expectation. If its output sensors have noticed the presence of the pallet, i2 concludes that the expectation was verified. In that case, this indicates that the input sensor of i2 failed to detect the pallet. On the other hand, if i2 is also not able to verify the expectation, it can conclude that this particular pallet is missing (it fell of the conveyor or it has been manually removed). In a second scenario (Fig. 5), the conveyor agent prevents disturbances by predicting that the conveyor is overloaded. Each conveyor has limited capacity given by its length so it can accumulate only a given number of pallets. It has to ensure that the conveyor will never become overloaded, since it could lead to other failures. Using the world model, the conveyor agent identifies a future state in which the maximum capacity would be reached. In that case, it can prevent the input
493
We implemented the anomaly detection mechanism based on the Manufacturing Agent Simulation Toolkit (MAST) [5]. Fig. 6 depicts the simulation of a part of the test bed. It consists mainly of two intersections (i1 and i2) and one conveyor (c1). Each intersection is equipped with presence sensors at its inputs and outputs. Four work cells (W1-W4) are added to the simulation in order to act as sources (W1 and W3) and destinations (W2 and W4) for pallets. The palette flow goes from the left to the right. It is possible to simulate the failure of the output and input sensors of the intersections i1 and i2, and also the blocking of a pallet on the conveyor c1. In MAST, each physical component is assigned to one agent, which is in charge of controlling it. For the components c1, i1 and i2, we adapted the existing agents so that they conform to the generic automation agent architecture. For each agent, we defined the relevant world model (as illustrated in section IV for the conveyor agent) and the decision-making procedures for detecting anomalies. We use the Web Ontology Language (OWL [20]) as a representation language and the Jena library 3 as a basis for maintaining the world model in the world model repository. The resulting agents retain most of the original implementation, especially the interface to the physical component, the low-level control tasks (e.g., directing a pallet based on its destination) and the management of communication with other agents. VII. C ONCLUSION In this paper, we showed how to improve existing agent-based manufacturing control systems by integrating an ontology-based, reflective world model into the agent highlevel control. The world model contains an explicit representation of agent’s surrounding environment, including the agent itself. Using the world model, high-level reasoning mechanisms for making diagnosis and coordinating with other agents can be introduced. In order to evaluate the interest of this approach, we investigated its ability to detect anomalies in a transport system without modification of the existing hardware, sensors and low-level control. We validated our approach on the existing simulated system MAST. The resulting agentbased control system is able to manage the transportation of pallets and to detect specific anomalies. Future works will consist in applying the proposed architecture to different types of agent-based control systems both in the context of pallet transport systems and in other domains, such as process control automation. Furthermore, we will investigate more precisely the consequences of using such 3 http://jena.sourceforge.net/
i1
c1
Sensor
i2
Sensor
Fig. 6.
Screenshot of the simulated manufacturing system.
an architecture both in simulated and real systems, in order to refine the world model representation and decision-making mechanisms. ACKNOWLEDGMENT The authors would like to acknowledge the financial support from the FIT-IT: Semantic Systems program, an initiative of the Austrian federal ministry of transport, innovation and technology (bm:vit) under contract FFG 815132. R EFERENCES [1] W. Shen, D. H. Norrie, and J. Barths, Multi-agent Systems for Concurrent Intelligent Design and Manufacturing. CRC, 2001. [2] N. Jennings and S. Bussmann, “Agent-based control systems: Why are they suited to engineering complex systems?” IEEE Control Systems Magazine, vol. 23, no. 3, pp. 61–73, 2003. [Online]. Available: http://dx.doi.org/10.1109/MCS.2003.1200249 [3] M. Pˇechoucˇek and V. Maˇr´ık, “Industrial deployment of multi-agent technologies: review and selected case studies,” Autonomous Agents and Multi-Agent Systems, vol. 17, no. 3, pp. 397–431, Dec. 2008. [Online]. Available: http://dx.doi.org/10.1007/s10458-008-9050-0 [4] M. Vall´ee, H. Kaindl, M. Merdan, W. Lepuschitz, E. Arnautovic, and P. Vrba, “An automation agent architecture with a reflective world model in manufacturing systems,” in IEEE International Conference on Systems, Man, and Cybernetics (SMC09), San Antonio, Texas, USA., 2009. [5] P. Vrba, V. Maˇr´ık, and M. Merdan, “Physical deployment of agent-based industrial control solutions: MAST story,” in 2008 IEEE International Conference on Distributed Human-Machine Systems, Athens, Greece, 2008. [6] S. Deen, Ed., Agent Based Manufacturing: Advances in the Holonic Approach. Springer, 2003. [Online]. Available: http://www.springer.com/978-3-540-44069-7 [7] R. W. Brennan and W. O, “A simulation test-bed to evaluate multi-agent control of manufacturing systems,” in Proceedings of the Winter Simulation Conference, WSC 2000, vol. 2, 2000, pp. 1756 vol.2, 1747. [Online]. Available: http://dx.doi.org/10.1109/WSC.2000.899165 [8] J. L. M. Lastra, E. L. Torres, and A. W. Colombo, “A 3D visualization and simulation framework for intelligent physical agents,” in Holonic and Multi-Agent Systems for Manufacturing, 2005, pp. 23–38. [Online]. Available: http://dx.doi.org/10.1007/11537847 3
494
[9] M. Merdan, T. Moser, D. Wahyudin, S. Biffl, and P. Vrba, “Simulation of workflow scheduling strategies using the MAST test management system,” in 10th International Conference on Control, Automation, Robotics and Vision, ICARCV 2008, 2008, pp. 1172–1177. [10] J. Christensen, “HMS/FB architecture and its implementation,” in Agent Based Manufacturing: Advances in the Holonic Approach, S. Deen, Ed. Springer, 2003, pp. 53–88. [11] S. Bussman, N. R. Jennings, and M. Wooldridge, Multiagent Systems for Manufacturing Control: A Design Methodology, ser. Springer Series on Agent Technology. Springer, 2004. [Online]. Available: http://www.springer.com/978-3-540-20924-9 [12] A. S. Rao and M. P. Georgeff, “Modeling rational agents within a BDIArchitecture,” in Proc. of Intl. Conf. on Knowledge Representation and Reasoning, 1991. [13] C. S¨under, A. Zoitl, and C. Dutzler, “Functional structurebased modelling of automation systems,” International Journal of Manufacturing Research, vol. 1, no. 4, pp. 405 – 420, 2006. [Online]. Available: http://dx.doi.org/10.1504/IJMR.2006.012253 [14] M. Merdan, G. Koppensteiner, I. Hegny, and B. Favre-Bulle, “Application of an ontology in a transport domain,” in IEEE International Conference on Industrial Technology (IEEE ICIT2008), Sichuan University, Chengdu, China, 2008. [Online]. Available: http://dx.doi.org/10.1109/ICIT.2008.4608572 [15] W. Lepuschitz, M. Vall´ee, M. Merdan, P. Vrba, and J. Resch, “Integration of a heterogeneous low level control in a Multi-Agent system for the manufacturing domain,” in 14th IEEE International Conference on Emerging Technologies and Factory Automation (ETFA09), 2009. [16] B. Chandrasekaran, J. Josephson, and V. Benjamins, “What are ontologies, and why do we need them?” IEEE Intelligent Systems and Their Applications [see also IEEE Intelligent Systems], vol. 14, no. 1, pp. 020–26, 1999. [Online]. Available: http://dx.doi.org/10.1109/5254.747902 [17] F. Baader, I. Horrock, and U. Sattler, “Description logics,” in Handbook on ontologies. Springer, 2004, pp. 3–28. [18] J. Allen, “Maintaining knowledge about temporal intervals.” Communications of the ACM, vol. 26, no. 11, pp. 832–843, November 1983. [19] M. Merdan, “Knowledge-based Multi-Agent architecture applied in the assembly domain,” PhD Thesis, Vienna University of Technology, 2009. [Online]. Available: http://www.ub.tuwien.ac.at/diss/AC05040230.pdf [20] M. Dean and G. Schreiber, “OWL Web Ontology Language Reference,” W3C, Recommendation, February 10 2004. [Online]. Available: http://www.w3.org/TR/owl-ref/