Intelligent Software Agents in Plant Automation Alexei Bratoukhine, Yoseba K. Penya and Thilo Sauter Institute of Computer Technology VIENNA UNIVERSITY OF TECHNOLOGY Gusshausstrasse 27/E384, A-1040 Wien AUSTRIA {bratukhi, yoseba, sauter}@ict.tuwien.ac.at Abstract Recently, the worldwide spread of e- business has led industry into a scenario where flexibility, reconfigurability and a product-oriented approach are necessary to successfully deal with the new requirements of the market. This paper presents the EU-funded BADIS project (Plant Automation Based on Distribution Systems), which tackles these problems by using intelligent software agents. It addresses a distributed plant automation system where machines and products are represented by software agents that collaborate to schedule the production and resources in the most optimized way. Hence, the system gains fault tolerance and achieves both plant and production reconfigurability. Moreover, we describe the agents and the model that governs their relationship within the community and with the other components of the BADIS system. Finally, there is an analysis of agent platforms in the market with regard to the BADIS model requirements. I. INTRODUCTION The confluence of diverse factors, such as Object Oriented Programming (OOP) or Distributed Artificial Intelligence (DAI), has made possible a new step in the evolution of the computer science: software agents. Although the scientific community does not agree on a certain definition [1], all of them coincide to point out the following aspects of software agents: Autonomy Sociability Problem-oriented design In other words, they are nothing more than autonomous software programs able to communicate with other agents (or humans) in order to cooperate in the resolution of a certain problem. They can be divided in multiple categories, depending on the criteria or aspect to be stressed, as in [2]. Furthermore, there is yet another feature that not all the agent present: mobility. Mobile agents are able to migrate from one host to another, bringing code and whatever data might be necessary for any further development of the process. Therefore, the combination of mobile and non-mobile agents brings an innovative approach in areas such as plant automation, where artificial intelligence traditionally has always played a minor role. This is changing due to the transformation of the market demand in the wake of the advent and expansion of Internet-based shopping and business. From the former huge mono-model series, the factories deal nowadays with small product-oriented orders that have changed the old conception of a manufacturing plant. Since agents can provide flexibility, control on every step of the development process, reconfiguration or fault tolerance, they introduce new possibilities that allow manufacturing factories not to fall from the train of progress. There have been other attempts to find a solution to these problems. For instance, the Holonic Systems [3, 4] proposed an approach based on equipping each machine with intelligence (and the union of both is the so-called Holon). Although this model achieves to decentralise the plant automation, it already presents a number of disadvantages: Non product-oriented, but rather plant oriented. Not enough flexibility regarding products, because control is done in a centralised or partly distributed way, where the set of agents are performing the control of the whole plant. Hence, the objective of the BADIS project [5] is to introduce not only stationary but also mobile agents as a key to extremely optimize the management of the resources. This proposal is specially indicated for environments with non-reliable networks or systems, which need an easily scalable architecture. For a better appreciation of the advantages of combining mobile and stationary agents in plant automation, let us think about one mobile agent that symbolises a product.
It has to be manufactured in a big factory where all the machines are represented by a private stationery agent. The product agent may ask it about the exposed functionality, current situation and even get a certain time slot to use the resources of the device. Thereby, it can previously negotiate the development process and afterwards migrate in every step to accurately control its progress. Finally, the extrapolation of this case leads us to a decentralised manufacturing plant that provides the following facilities: An automated scheduling method Fault tolerance More flexibility to reconfigure the plant and the production II. THE BADIS MODEL The BADIS model is based on the following components: (Co-operative Manufacturing Unit), Agents (Product Agent, Residential Agent and Product Management Agent), Agency and Look-up service. The combination and collaboration of all of them constructs an architecture whose main objective is to distribute the manufacturing control (MES, Manufacturing Execution System) functions as much as possible within the plant automation system. Fig. 1 shows a BADIS model including the ERP System (Enterprise Resource Planning), and several types. A is the union of a manufacturing unit and a residential Agent (). The provides the network with an interface to the unit where it is hosted. It imports the functionality, no matter what the abstracted manufacturing unit is. There are two main types of s: Logical : It provides computational services such as complex scheduling algorithms, database search etc. It can be individual PC/IPC, computation networks, Internet, databases, etc. Manufacturing : It is used for physical processing of products and can be individual machines, multipurpose manufacturing cells, or full production lines. SCADA ERP Agency Manufacturing Logical Manufacturing and logical Manufacturing Fig. 1: BADIS model Jini Community Look-up Service Ethernet As is shown in Fig. 1, there are hybrid types of Manufacturing and Logical, which are necessary in the case of complex machine where the logical and physical functionality are hardly separable. Finally, it can also be appreciated that there is still a fourth type of : the SCADA (Supervisory Control and Data Acquisition) that provides the BADIS system with an interface to the SCADA functionality and allows it to control the plant. AGENTS As it was already explained, software agents are just an extreme object-oriented view of a software program. These programs have an interface to communicate and a certain function to fulfil. This reflects the original object-oriented paradigm of a software program: it has methods, data and an interface to other objects. The methods and the data are encapsulated by the object and only accessible via the interface [6]. There are three types of agents in the BADIS system: Product Agent: A mobile agent that represents a manufacturing order from the centralised ERP system. Each is a piece of code consisting of methods (tasks calculation, security, negotiation mechanism etc.) and the specific product data (work order, execution plan), sufficient to successfully control and carry out the execution of the working order assigned. In this process, it may migrate in the network independently when needed. Finally, the task for each product agent is composed from several subtasks with all possible mutual dependencies (time dependence, sequence, priority, etc.) represented as an ordered graph. Residential Agent: Provides the connection between the plant network (including other agents) and the particular resources offered by the. If we think on the agent as a piece of software, then it has effectively two independent interfaces, one on either side. Hence, the residential agent is in fact a gateway between the abstract and well-defined agent community on the one hand and a large variety of concrete production facilities on the other. The purpose of a PMA is to provide an interface between the Agent Community (s and s) and the operators in the plant. Basically, this means the ERP/SCADA system operators, who must have a possibility to control and to observe the plant automation system during the system execution. Additionally, some MES functions can not be implemented completely without the human control. Hence, PMAs become necessary and they are responsible for gathering in the system the appropriate information needed by the ERP, MES or SCADA system and for giving the responses back
to the operators that initialised the requests. The human control is optional and might sometimes be replaced by an automatically initialised request. Nevertheless, the most important task for PMAs is to fulfil appropriate MES functionality, such as Maintenance, Document control and Genealogy and Product tracking, where the human factor is important. Finally, there is a special type of PMA, so-called SCADA PMA that provides an interface not to the ERP system, but to SCADA, a single independent unit, performing the SCADA functionality. Apart from s and agents, there are two more components in the system: The first one is the Agency. It acts as an interface between the ERP System and the agent community. It receives the working orders and converts them into Product Agents. The Agency also includes a data collector, where the reports from the s are stored after finishing the work order execution and the agent fabricator, which creates the agents. The second one is the Look-up service (LUS), which provides two services: the plug-and-participate feature necessary to achieve re-configurability and a centralised system to announce the services that each offers. After been plugged into the system, the of a informs the LUS about new functions, joining the - BADIS community. Afterwards, the s use the LUS to look for machines that match their requirements and then, they start a leasing procedure. BADIS PRODUCTION RUN The production run in BADIS can be described in the following sequence of actions: 1. ERP System creates a manufacturing order including an accurate description of the necessary operations to create the product. 2. Agency converts the manufacturing order in a set of work orders understandable by the agents. 3. The Agent Fabricator of the Agency creates one product for each work order. 4. The contacts with the adequate s and negotiates with them the processing of the product. 5. The executes its work order, migrating in the plant to control it closely. 6. When the work order is completed (or when the finishing of the work order is impossible) the returns to the agency to report about the process. 7. The is terminated by the Agency or it terminates itself. 8. Agency sends a report to the ERP System, so the production cycle starts in the ERP System and finishes there. III. MULTI AGENT SYSTEM IN BADIS BADIS provides a product-oriented Multi-Agent System (MAS), which also achieves to decentralise the plant structure. This orientation leads to a more flexible model in both development of production systems and the actual manufacturing process with respect to the individual products. One of the characteristics of the BADIS model is that Residential Agents (opposite to s), do not communicate with each other via the network. That is necessary in order to provide independence between s and not to allow them communicate between each other. The production is done in respect to a single product, which uses available resources and not to the machines, which are necessary only to execute the tasks needed by the s. This prohibited communication between s over the network is a main difference between the BADIS concept and other object-oriented technologies like the Holonic Manufacturing Systems All the intelligence of the BADIS system is concentrated in s, while in HMS the intelligent modules are machine-dependent. Fig. 2 shows the relationship between the different agents in BADIS. It is important to note that all s work in concurrence to other agents (either other s or PMAs) and that their behaviour is in strong accordance with common rules. The result is an optimisation of the s own visions and, of course, of the whole manufacturing process of the entire plant as well. PRODUCT AGENT This section is devoted to extend the explanation about the most essential element of the BADIS multi-agent PMA Agency PMA LUS Fig. 2: MAS in BADIS SCADA
system: the Product Agent. The code of the includes standard methods (coinciding with the life-cycle states), such as Live, Create, Terminate, Action, and specific methods concerning the concrete agent and depend on the functionality of the agent. Additionally, a presents mobility mechanisms, which are specific for different agent platforms used in the application (see section IV). The data of a consist on the standard part (including a status and a history data), a product data (an XMLfile), a special MES data (where collects data of a product manufacturing), and the work order. Hence, every knows all the tasks, which have to be carried out in order to manufacture the product. Furthermore, all possible dependencies between the tasks are also included and described the XML document. Creation of the Product Agent A uses the work order to create its own execution plan, where all tasks are assigned to the appropriate resources (including time dependencies). Created by the Agency, a starts an initiation procedure that checks all possible paths to choose the best way of production. The work order includes a list of functions that a requests to the LUS. Using this list, it communicates to the appropriate s in order to get additional information of the function (). Afterwards, it creates a list of best s and tries to allocate these resources. At the end of this allocation, the completes its execution plan with exact s of each task of work order in respect to the time of task performing (Resource allocation and scheduling procedure is shown below). Migration Afterwards, a migrates to the agent container of the where the first task will be executed. The safety of migration is a due of an agent platform. Every of the evaluated platforms provides a safety mobility mechanisms. A moves to the destination all data and code of an agent where a new instance of the is created. All data and methods depending on the is located on the appropriate and accessible to a. When the task execution is completed a migrates to the next destination. During the performing the task a does not communicate to any other components of the system outside of the. It means that the can work autonomy. Termination The termination of a is the process when all components of an agent are removed from the system. Code and data are logically and if it is necessary physically deleted. It depends on a concrete agent platform mechanisms and hardware requirement of the system. The termination of a happens in two cases: Work order completed: In this case the moves to the Agency and dies there. Hence, the initiates its removing from the system by itself. Impossible to complete the work order: In this case the informs the Agency about the reason that prevents from a right termination. In case of an error or a non-possible termination, the reports the Agency and it is terminated in the usual way. Obviously, the Agency notifies the ERP System on the error and, after its correction, it can create a new containing the work order generated based upon the new manufacturing order. The reason for this is that the system cannot use the old because the work order cannot be changed after the agent s creation. Communication in the BADIS System As it is shown in the Fig. 2, there are different communications types between and other components of BADIS network: : negotiations between s become necessary if conflict situations occur. This may happen, if more than one wants to use the functions provided by a specific. PMA: A PMA is always an active partner in this communication. A only responses for requests. This communication is normally used for MES functionality distribution such as Document Control, Product Tracking and Genealogy or for the ERP System/SCADA manual control LUS: Every time that a needs information about a function, it requests the LUS about all available s that implement that functionality. : The and the are both active in this communication it is always started by the. It is necessary for resource allocation and scheduling procedure and for other MES functions as well, but the mechanism of communication in these cases is simpler, because it does not need a re-scheduling and negotiations. RESOURCE ALLOCATION, SCHEDULING AND DISTCHING One of the main functions of MES is the resource allocation and related to it, scheduling and dispatching. In BADIS, this function is distributed by the negotiations between s and s (scheduling is done by a and dispatching is done by a. A contains all
data concerning necessary tasks and operations that have to be done in order to produce a product. In contrast, a contains information about the available resources in a single. The scheduling is performed in two ways: Horizontal fashion: The s collect the incoming requested tasks and generate a schedule of tasks of different s. Vertical fashion: The s generates a list with the possible s where its task could be carried out. The combination of both tables forms a matrix, where the whole schedule is represented. Finally, there is still a problem related to scheduling and resource allocation: the re-scheduling. This occurs when a with higher priority intends to use a in the time-slot that was already assigned to other. When the informs the affected s, they have two possibilities: Either to search for a new with the same function or to use a different time of execution at the same. In both cases, a has to recalculate its execution plan. This fact obviously influences the further execution plan in other s. In case of hundreds of agents and s, it may result in a snowball effect. To avoid that, the depth of scheduling could be decreased. The rescheduling is a responsibility of the, whereas it is passive element in the preliminary scheduling. The following sequence of actions describes the mechanism: 1. If the receives a request from a, it checks its own status and sends response concerning the availability of execution. 2. If the receives the new allocation request for execution from a, it puts this allocation request in a queue and waits for further requests. If the queue is not empty, the checks the priorities of the requests. 3. If the received request has a higher priority, the needs to re-schedule the queue. This may include sending a notification to the, which previously reserved the time slot for execution. This decides if the task has to be put down or to be kicked off from the queue. 4. The checks its own scheduling and makes a decision, whether the delay is acceptable or not. If it is impossible to shift the execution down, the starts its own scheduling procedure from the beginning. Otherwise, the informs the appropriate that the new scheduling is accepted. 5. If the depth of the scheduling is more than one task, the also re-schedules the depending tasks from other s, notifies it and waits for the answer, as in the point 4. IV. AGENT PLATFORMS ANALYSIS The following section presents the result of the agent platform analysis that was done inside the BADIS project, to select the one that better fits to the BADIS concept. Since the agent platform is the environment where the agents will work, it has to provide the following facilities: Suitable resources for the execution of the agent Allow agent mobility Implement security mechanism Only three of the few platforms that match these requirements were included in this paper (see Tab. I). The analysis examined diverse aspects, for instance: Migration control: who can initiate the migration of the agent Standards supported: not only agent-specific such as FI (Foundation for Intelligent Physical Agents) or MASIF (Mobile Agent System Interoperability Facilities), but also open-purpose as CORBA (Common Object Request Broker) or XML (extensible Markup Language) External security: if they allow the possibility of implement an extra security mechanism Communication language: which language can be used to the negotiation between agents As mobility is a key issue within the BADIS framework, we only considered agent platforms based on Java. EVALUATED PLATFORMS The more interesting evaluated platforms were Voyager from Objectspace [7], Grasshopper from IKV++ [8] and finally Lana from the University of Geneva [9]. Tab. I shows the result of contrasting the requirements of - BADIS with the features of the two more adequate platforms, Grasshopper and Lana. Grasshopper is the platform selected for the implementation, since it supports more standards than all the other evaluated platforms (for instance MASIF), it is free software, it is supplied with a lot of technical support and the agent model fits perfectly in the BADIS concept (as it will be shown in the next section). LANA will be used in further implementations because it constitutes a lightweight product, ideal for embedded and real-world product, and it is an open-source with high-level security mechanisms. The current status is, however, still under development.
Name Grasshopper Lana Voyager Availability Free software Open source Commercial Migration Control Agent itself, other agents, Agent system, application Agent itself, other agents, GUI, application application Concept Yes No No Standards supported Java RMI, MAFIS, FI, Java RMI Java RMI, HTTP, CORBA, XML, CORBA, Security Complex Sufficient Not Sufficient External security mechanisms X.509 certificates, SSL Lana Security Mechanisms No (RSA/DES) Communication Method invocation Method invocation Method invocation Multicast Yes No Yes Event service Yes Yes Yes Message forwarding Yes No Yes Communication Language Java, KQML Java Java GUI Yes No No Tab 1: Comparison between Agent Platforms THE GSSHOPPER AGENT PLATFORM The Grasshopper Platform was chosen for first implementation of the BADIS model. It consists on several entities: regions, agencies, places, agents, region registries and communication services. Not all of them necessarily must be a part of a system that uses the platform; only agents and agencies are mandatory parts. This strongly depends on the system scenario. Grasshopper also allows to add some external services or even to extend the present components. The following is a list with the most important elements: Agency: Provides the basic platform functionality, such as creation, transmission and execution of the agents. Furthermore, it provides the communication and security mechanisms as well. Region Registry: It is a subsystem maintaining information of resources associated with a particular region. A region registry contains the current location, identifiers, and descriptions, of all the registered objects. Hence it works as a directory service and provides various look-up operations and search criteria. Region: A region consists on the gathering of agencies and a region registry where agents are automatically registered. It facilitates the management of agencies and agents. Agent: An agent can be one or more Java classes. There are two kinds of agents, mobile and stationary. Mobile agents can migrate autonomously between different locations in contrast to stationary agents, which permanently reside in their creation agency offering services to other agents or nonagent based entities. The BADIS model components can be represented by Grasshopper entities as is shown in Tab. II. Continuing with the description of the Grasshopper model, the states in the life cycle of an agent may be: Active: In this state, an agent is executing its task. After an agent has accomplished the task, the agent remains active and it is still accessible by other entities as a passive object. Suspended: If an agent is interrupted by the hosting agency for some reason while it is in active state and executing its task, the agent switches to suspended state. In contrast to the active state, where accessible methods of agent can be invoked by other components, methods of suspended agent cannot be accessed by other entities. Furthermore, an agent in suspended state cannot reactivate itself. Flushed: The data status of the agent is locally stored and its instance is removed from the agency. In this state, an agent can also not reactivate itself. The reactivation happens when another component tries to access it. Not active/undefined: A binary code of a particular agent is present in the system, but there is no active BADIS components PMA Look-up Service Grasshopper components Mobile Agent Stationary Agent Stationary Agent Region Registry Tab. II: Equivalencies between Grasshopper and BADIS terminology.
Interface IAgent live() action() log() copy() remove() getinfo() setproperties() getproperties() setproperty() getproperty() Agent beforecopy() aftercopy() init() getregion() getname() getdescription() beforeremove() getagentsystem() agent instance created. An active agent may switch to this state if it was deleted from the hosting agency. Finally, another important aspect that Grasshopper provides is the multiple facilities for programmers as a Graphical User Interface or intuitive usage of methods and properties. For instance, creating a mobile agent is as easy as declaring a new instance of the class MobileAgent, whose class diagram is shown in Fig. 3. V. CONCLUSION Interface IMobileAgent MobileAgent move() beforemove() aftermove() gettype() Fig. 3: Class diagram in of a Mobile Agent in the Grasshopper Platform. We have presented the solution proposed by the - BADIS project to deal with the current problems in the plant automation area: in order to achieve flexibility and a higher fault tolerance, the BADIS approach designs a distributed system based on intelligent agents that represent machines (Residential Agents) and products (Product Agents). The Product Agent may migrate to better control the development of the process. We also described the structure of the agents and their relationship with the environment (agent community, agency and ERP) and how they collaborate to distribute the allocation of resources and tasks in the plant. The evaluation of available agent platforms showed that the BADIS concept could be mapped to existing technologies. Currently, the agent concepts are being implemented on the Grasshopper system. As a next step, the demonstrator will be set up to prove the applicability of the BADIS idea.... ABBREVIATIONS Co-operative Manufacturing Unit DAI Distributed Artificial Intelligence ERP Enterprise Resource Planning FI Foundation for Intelligent Physical Agents GUI Graphical User Interface HMS Holonic Manufaturing System HTTP Hipertext Transport Protocol ISO International Organisation for Standardisation KIF Knowledge Interchange Format KQML Knowledge Query and Manipulation Language MASIF Mobile Agent System Interoperability Facilities Product Agent PMA Product Management Agent OOP Object Oriented Programming Residential Agent RMI Remote Method Invocation SCADA Supervision, Control and Data Acquisition SSL Secure Socket Layer XML extensible Markup Language REFERENCES [1] M. Wooldridge and N. R. Jennings, Intelligent Agents: Theory and practice, Knowledge Engineering Review, vol. 10, no. 2, 1995, pp. 115-152. [2] J. M. Bradshaw (ed.), Software Agents, MIT Press; ISBN: 0262522349, 1997. [3] L. Bongaerts, P. Valckenaers, H. Van Brussel, and J. Wyns, Schedule execution for a holonic shop floor control system, in Preprints of the Advanced Summer Institute '95 of the Network of Excellence in Intelligent Control and Integrated Manufacturing Systems, 1995, pp. 15-124. [4] M. Fletcher and S.M. Deen, Fault-tolerant holonic manufacturing systems, Concurrency and Computation Practice & Experience, vol 13, no.1, 2001, pp. 43-70. [5] BADIS, IST-1999-60016, http://www.pabadis.org [6] S. Abeck, A. Koppel, and J. Seitz, A Management Architecture for Multi-Agent Systems in Proc. of the IEEE Third International Workshop on Systems Management, 1998, pp. 133-138 [7] www.objectspace.com/products/voyager/ [8] www.grasshopper.de [9] C. Bryce, C. Razafimahefa, and M. Pawlak, Lana: an approach to programming autonomous systems, http://cui.unige.ch/~bryce/lana.pdf