Integrating physical and software sub-systems in a manufacturing environment through agentification

Jonatan Trulls-Ledesma and Llus Ribas-Xirgo Departament de Microelectrnica i Sistemes Electrnics Universitat Autnoma de Barcelona (UAB), 08193 Bellaterra, Barcelona, Spain E-mail: Jonatan.Trullas@campus.uab.cat, Lluis.Ribas@uab.cat
In the following we shall describe the motivation of this work and, in the next section, the problem to be solved is described in detail. Before describing the agentification process, with the limitations before-mentioned, a review of the state of the art of MAS is done. The last section is devoted to present the conclusions of this work. A. Motivation This work was motivated by the problems that exposed a small company that wanted to put its manufacturing plant to date. This real case shows how incorporation of heterogeneous software and hardware systems leads to the need of integration and standardized communications. Furthermore, cooperation and decentralized control are desirable features to be achieved. We shall use this real problem as an example of how agentification might be done. In this example there are about 250 people working with a set of manufacturing tasks that produce product parts from metal sheets. As this company works outsourced by thirds, it must produce a wide variety of final product for different costumers, with some of those products being produced at the same time in a concurrent manufacturing. This also implies another important need: the plant must be easily and quickly adapted to produce new products. As a result of the inclusion of technological innovations in different fields of manufacturing, the plant which we're dealing with has become a complex system composed of heterogeneous hardware and software components. It includes, for example, an enterprise resource planning (ERP) solution, several CAD/CAM tools, some machine-tools for manufacturing processes (punching, cutting, bending, etcetera), control modules (software and hardware), computer numerical control modules, NC program servers [13], automated warehouses, automated guided vehicles (AGVs), robots, etcetera. As those elements are not integrated, human operators are needed in order to, for example, achieving some kind of information transfer between them, monitoring manufacturing status, selecting CN programs for an special machine/control combination, or starting processes in a machine tool. Hence, this transfer of information between non integrated modules makes a first distinction for manufacturing stages, that is, tasks or steps that must be done in order to produce a final product.

Abstract In manufacturing environments, embodiment of new technologies during last years, has leaded to manufacturing systems with a high level of heterogeneity and, therefore, to a lack of integration. It is difficult to fulfill the need of the new requirements of fast reconfigurability, openness, and interaction with human operators. In this context, transforming those physical and software sub-systems of the plant into agents, by means of an agentification process, allows the adoption of the multi-agent paradigm. In this paper we present a theoretical model, and our practical experiences in the agentification of a small manufacturing plant.. Index Terms agentification, manufacturing, integration, simulation, ontology.
I.

INTRODUCTION

ncorporation of different technological advances during the last 40 years has led to the existence of heterogeneous systems, where software and hardware components are not always connected. Some of those sub-systems are highly specialized or ad-hoc implemented for performing concrete manufacturing tasks. This lack of integration results in difficulties for fulfilling requirements of openness, scalability and fast reaction against unexpected events in plant. Furthermore, in some small plants, different stages of manufacturing process (control, scheduling, planning, etc.) are organized in a classical hierarchical organization, which makes it less flexible to changes and reorganization. Therefore, some of those problems could be solved adopting the multi-agent paradigm by means of agentification of the plant components, so to have a more flexible, adaptable and easily updateable plant. This work is about creating a multi-agent system model for an small and medium sized enterprise manufacturing plant, so to be able of gradually transform its subsystems into agents. This is a less ambitious solution than agentifying the entire plant. This solution is been adopted because a full agentification of the plant would imply significant changes in the plant that may not be acceptable to the company due to its limited capability to assume failure risks. In our approach, different components are agentified according to our model, having a minimum impact on the plant operation.

Moreover, it is clear a distinction between main software modules (for example ERP or CRM) and hardware/software modules (for example a cutting machine-tool, with its specific control software and g-code generator). These main stages for a product production, shown in Fig. 1, are [2]:

between scheduler and ERP consists only in a few text files exported from the ERP, which contain only information representing the state of the production in a concrete moment. Manufacturing: Tasks coming from each manufacturing order, in a sequence given by manufacturing plan of the manufacturing order, are processed in its assigned resource. During this stage parts are created by means of a very heterogeneous group of machine-tools, robots and human operators. In addition, other elements also take part in the process, such as AGVs and automated warehouses. Organization is hierarchical in the sense that resources assignment is given in the previous step (scheduling), information for machine tools is downloaded from the ERP to local terminals by human operators, and there is not realtime bottom-up information, that is, changes in current status of manufacturing orders only are due to certain actions as finishing a process or operators signals. II. PROBLEM STATEMENT Main conclusions drawn from the example, which are summarized next, are useful for showing the main problems, and bottlenecks, that there are to be solved. The lack of complete subsystems integration, at manufacturing plant level, makes impossible a fast reaction in case of unexpected events (machine-tools malfunction, changes in manufacturing plan, et cetera). For example, the lack of an automated connection between the first two stages and the ERP in the product production flow becomes a bottleneck due to the time that users must spend introducing the same data twice, for both subsystems. Furthermore, the subsystem controlling manufacturing cycle does not interact directly with machine-tools. Instead of this, human operators are in charge of downloading NC programs from database and starting each sub process of manufacturing orders. Previously, CRM system assigns these NC programs to each operation in the manufacturing plan of each manufacturing order, but it can not send them directly to each CNC controller due to their heterogeneity [13] in terms of protocols, communication network (RS-232, LAN-net, wireless land,...) and storage capacity. Data losses and other errors during transfer process of the NC data are not recognizable. The plant is a heterogeneous system, formed by hardware and software subsystems, which have progressively been incorporated along the last years. These include some CNC machine-tools, robots, AGVs, automated warehouses, specific control hardware, distributed software and databases, all of them with different programming languages, protocols and specific software tools. This heterogeneity represents an additional complication to the lack of integration seen before. The whole system should be open and scalable. Openness requires the before mentioned integration and capability of including new heterogeneous subsystems. New components should be dynamically incorporated without any interruptions in the manufacturing cycle, or resetting the entire system. Complete system structure is excessively hierarchized and

Fig.1.: Enterprise organization

Design: Plans and technical information as 3D geometry, physical parameters and user requirements, provided by customer, are introduced in the system database using CAD software. Materials optimization: Specialized nesting software helps in material optimization. It disposes of diverse parts over a metal sheet in a manner that maximizes the sheet surface coverage by the parts and, subsequently, minimizes material waste. This optimization is based on geometrical data introduced on stage 1, and nesting software can also generate computer numerical control (CNC) programs for machine-tools. Transference of manufacturing data into manufacturing control software: Product structure and manufacturing information are entered into the ERP. This information mainly consists of a bill of materials (BOM), a manufacturing schedule, i.e. a sequence of parameterised processes required to produce the part, and a list of available resources (for example, a list of machine-tools for each process). This software is integrated in the ERP but not with components used in stages 1 and 2. Management: This stage includes all management tasks that are integrated in the ERP, and leads to the generation of manufacturing orders as, for example, receiving customers orders, stock management as, for example, launching of purchase orders for metal sheets if material buffers are not enough. Scheduling: During this stage, another software component is in charge of assigning resources to processes of manufacturing orders. This assignment is planned in such a way that fulfils constraints as delivery dates, parts priorities, machine-tool usage, et cetera. These constraints can be changed in order to optimize the production costs, time usage, or any other user criteria. In this case, integration

not much flexible. As seen previously, the scheduler makes resources assignment depending on some user constraints and on the manufacturing plan for each manufacturing order, thus when and where each manufacturing process is executed depends strongly on this global plan. In this top down flow of information, there is a queue for each machine-tool containing the sequence of tasks to be processed. Human workers are in charge to supervise correct processing of those queues and sending requests of material to automated warehouses, so problems or unexpected events at this low level of the organization must be resolved by them. As in this kind of manufacturing plants these unexpected situations are frequent, a long term scheduling is not possible. That is why a distributed control, based in local decisions, but with a global coordination, should improve substantially the global system's performance. There is little tolerance to faults. As noted before, in a hierarchical organization, any unexpected situation or bottleneck can cause the collapse of the entire system. In addition, lack of integration and heterogeneity of systems leads to data consistence problems. This means that redundancy, contradictions and loss of information can appear in such kind of systems. For example, different drivers [1] must translate communications information into concrete machine-tools controller languages, NC program servers are not notified of program changes by CAD/CAM modules, and there can be data loss during transfer process. Finally cooperation and interaction between human operators and the system should be desirable too, in order to get more real-time information and a fastest access manufacturing data [13]. Having in mind than in this small plant we can not simply stop manufacturing process and replace the old system, nor disturbing the plant operation, the approach taken in this work to solve the problems described before must be incremental and progressive. This means that the plant will be transformed gradually, without stopping the system, only concrete sub-systems will be replaced or transformed in order to achieve their integration. Doing this there is a gradual improvement of the entire system performance. Multi-agent paradigm fulfils the requirements of this approach. As all the agents in a MAS share a common communication infrastructure it can be used for system integration, so any agent must accomplish with the requirements that stem for its usage. The common language used in communications between the agents helps in standardization of data, especially if messages are composed according to an ontology. Thus, agents may be totally heterogeneous as long as they fulfill the communication specifications of the systems. This is a key feature of MAS, since it allows the progressive integration of the existing sub-systems (so-called legacy systems) into the overall system. In the following sections, we shall first review the related state of the art and then describe the agentification of the plant.

III. STATE OF THE ART This revision of the state of the art is been done considering that it is mainly a multidisciplinary problem. Models, paradigms or works in different fields as artificial intelligence, robotics or networks can be adapted to solve our problems. A. Next Generation Manufacturing Systems Problems as those shown in our example have become common in manufacturing industries. That is why these industries are aimed to change their manufacturing strategies in order to adapt them to the need of a fast adaptability. In this context appeared the Next Generation Manufacturing Systems international project (NGMS), coordinated by the Consortium for Advanced Manufacturing [14]. Its main objectives are to develop better ideas and concepts in manufacturing systems (under the context of the Digital Factory). Different phases of this project have provided definitions, algorithms and methodologies. For example, Task 1.1 [14] introduces main concepts as fractal company, autonomous distributed manufacturing systems, task plan, agent notion, social ability, agent types, scheduling, XML, et cetera, and Task 1.2 describes requirements of a NGMS. The list of requirements of a NGMS includes: system composed of integrated, autonomous and cooperating subsystems, integration of humans in the system, being reconfigurable, flexibility and modularity, adaptability to changing environment conditions, being scalable and fault tolerant. One of the paradigms provided by NGMS project partners is the one of Reconfigurable Manufacturing Systems (RMS). Systems implemented following this model must be fast designed, able to be quickly adapted for the production of new products and integrate new technology. A RMS can be defined as a manufacturing system formed by the addition of basic process modules (hardware and software), which can be replaced, changed or reconfigured fast and easily [12]. This means that, instead of replacing the system, we can add or remove modules, or modify their functionality. RMS flexibility not only refers to the capability of producing a variety of products, but also to the capability of reconfiguring the system itself. Although RMS, and some requirements of NGMS, are still more a theoretical model than a practical implementation, they offer useful paradigms. Moreover, there are also some reported experiences in the field, and exist a few implementations that fulfill particular requirements for NGMS, and that can be used as a middleware, libraries or design tools. For example the usage of the MAS paradigm as a model for manufacturing systems has been proposed within the NGMS project. B. Agents and Multi-Agent Systems There is not a universally accepted definition of agent in literature. There are different definitions with contributions from artificial intelligence, philosophy, engineering and social science. As a consequence, agents are described in terms of communications, mental state, reactivity, et cetera, depending on the author and his research field. However, the

concept of autonomy is a common factor in most of the definitions. Therefore, a quite satisfactory description of an agent is as an entity that has the characteristics of autonomy, social ability, reactivity and proactivity [22]. Also significant to our problem is the characteristic of situatedness [17] of agents. Particularly, the agents in the example plant of this work are located in a real or virtual environment (in this case, the manufacturing plant or the computer systems within). In our context, proactivity is a key concept because, as seen in previous sections, one of our problems is the lack of local automated decisions. For example, a machine-tool agent, without any tasks in its queue, could request to another machine-tool for more jobs. The example plant consists of a group of heterogeneous and distributed elements, and fragmented information. The four principal techniques more frequently used to solve these kinds of problems are modularity, distribution, abstraction and intelligence [7]. Thus, using the agent paradigm as an abstraction model for our subsystems (the level of abstraction or granularity depends on further analysis) we can take advantage of its modularity and some kind of intelligence. Doing this we shall have a group of distributed agents that need to interact by using mechanisms as cooperation, competition, or even both of them. Therefore, it is possible to construct a view of the plant as a MAS. The design of MAS refers to the analysis and implementation of systems composed by more than one agent. It is an approach in which problems are solved by means of the combination of entities that are good solving partial, local, or minor problems, but not capable to solve the global problem. Design may start at the bottom level, by designing first the components of the system and constructing the whole system in what would be a bottom-up approach. But it can also start from the upmost level, in a top-down fashion, or in an intermediate manner. The latter is the only possible approach when agentifying existent systems, as agents encapsulate the already existent components and the whole system behaviour cannot be changed. Consequently, the design starts by both encapsulating components into agents and re-defining component relations at the system level so the system is rebuilt in a what would be a sort of meet-in-the-middle approach. C. Agent Communication Languages and Protocols Assuming that, in our manufacturing environment, agents can make use of a communications network, a standardized Agent Communication Language (ACL) is needed in order to allow them passing explicit messages. There are a few basic requirements for ACLs [11]: they must be syntactically simple (easy parsing), declarative, and with an extensible syntax (adaptable to some systems) and a layered content, so that they could be attached to other systems. It should be made a distinction between Communications Language itself, i.e. basic communications acts, and its contents, i.e. information about problem domain. ACL semantics must have a good theoretical base, and be unambiguous, providing a good communications model, useful for modeling and functional verification.

Furthermore, although agents can share information by means of simple messages, without any semantics associated with them, their deliberative and social capabilities lead to the need of more complex information interchanging, as plans, negotiations, long term strategies, et cetera. In order to achieve this complex information interchanging by using communications, two or more agents should accept the same pattern of message interchanging, which we can refer as conversation. In fact, a conversation is an interaction or coordination protocol. Therefore, implementations of ACLs or MAS development platforms must provide support for conversation specification (finite state machines, semantic restrictions, message dependences, et cetera) and standardized interaction protocols. This complexity of interactions makes that we can see the ACL as a communications layer, which is upper to simplest mechanisms as Remote Method Invocation (RMI) or Remote Procedure Call (RPC) [9]. D. FIPA-ACL Foundation for Intelligent Physical Agents [6] (FIPA) was formed in 1996 to produce software standards specifications for heterogeneous and interacting agents and agent based systems, and joined to the IEEE Computer Society in 2005. FIPA specifications are supported by most used MAS development platforms, so it should be desirable to use FIPA compliant models in any approach for our problem. Main specifications provided by FIPA are [5]: Abstract architecture: Instead of making variations in specifications to include new technologies (XML, messaging, et cetera) FIPA decided to provide an abstract architecture in which main used mechanisms could be accommodated. In order to achieving interoperability between systems, FIPA identified which elements are key and common to these systems, and they were used to define this model of abstract architecture. It specifies, for example, message transport, agent directory services, an ACL, et cetera. Particular implementations of this abstract architecture are called FIPA compliant. FIPA-ACL: ACL messages are based on Speech Act Theory [19] for wrapping their content. This content depends on domain of application, and is wrapped in a performative which reflects the intentionality of this communicative act. FIPA-SL (Semantic Language): These languages, and its associated semantics, are proposed as a content language for FIPA-ACL, although it does not require any particular content language. Interaction protocols: Abstract architecture includes a set of abstract objects which allow an explicit representation of a conversation, that is, a set of messages between partners, related logically with some interaction pattern. These protocols are: Query, Request, Contract Net, Iterated Contract Net, Brokering, Recruiting, Subscribe, and Propose. E. E. Simulation The usage of simulation can be an interesting tool in an agentification context, because MAS is built on an existing system and changes must be properly validated beforehand.

Simulation, thus, helps in verification, design, and decision taking. Despite of the valuable help of a simulator, notice that, depending on the detail level of the simulator, the implementation of it might be unaffordable within a reasonable budget, especially in case of simulation of manufacturing plants. Therefore, if objectives of simulation are not clear, or modeling costs are high, we will have to contemplate the usage of alternative techniques as analytical solutions, prototypes, et cetera [3] In the following, we shall describe some of the advantages of simulation. Help in design: Modelling the entire manufacturing plant before its construction allows taking decisions referring to chain distribution, manufacturing cells, buffers, et cetera. Verification of control strategies and decisions taking: It allows answering to questions as what would it happen if we change the buffers managing system? Manufacturing tasks scheduling: We can simulate in a few minutes an entire day of work, so we can detect possible situations as lack of resources, or delayed tasks due to a bottleneck. Verification and incorporation of new products: In order to giving a fast answer to the need of producing new models, we can validate manufacturing data (plans, specifications, bill of materials, CNC programs, et cetera), related to a new element, by means of simulating its manufacturing. This simulation ensures that we have enough information, and, for example, there are not undetected problems in CNC programs (cycles, collisions, geometry errors, et cetera) [20]. Robot and multi-robot systems (MRS) simulation: We have some robotic elements in the plant, which is a dynamic environment where unexpected situations can occur frequently, thus we can take advantage of MRS simulation tools, and their methodologies. Depending on abstraction level, we can distinguish between two kinds of simulators [10]: the physical and the abstract ones. Physical simulators, with physical conditions of the environment modelled, help in taking decisions about robotic elements design (sensor type, robot model, et cetera). Abstract simulators are useful for experimenting with aspects not related with the environment. They use a high level of abstraction and can be used, for example, for testing cooperation strategies, evaluating emergent behaviours from a collective of robotic elements, detecting deadlocks, et cetera. Integration of simulation and modularity support: Until now, simulation has been used as a stand-alone tool for analysis and scheduling, but its efficiency grows if it is connected to the manufacturing system. There are few experiences of connecting the manufacturing plant to a simulated model (for example, using events). This allows to monitoring certain tasks, make a replay when certain conditions occur, retrieve plant status in case of a complete fail, et cetera [4]. And, beyond the integration of the simulator in the system, introduction of simulated (or virtual) elements in the system can help us with the system

verification, or during the stage of integration of heterogeneous elements [21]. For example, a simulated machine-tool could be introduced in the real system in order to verify integration between stock managing and the manufacturing system. IV. SYSTEM AGENTIFICATION STAGES The approach to transform an existing system into a MAS that we propose in this work consists of a progressive, incremental agentification [1] of system components that takes into account that the system operation should be minimally disturbed. Note that, in the example case, we are dealing with a plant of a small enterprise, so it is not feasible to apply the conventional solution of stopping the production, removing the old system (and the internal organization), and implementing a new system. Consequently, the proposed solution is a procedure that gradually transforms the plant. It is expected that the progressive implementation of the solution leads to a gradual improvement of the entire system performance, as the different steps of the system transformation process are executed. The adoption of the multiagent paradigm to rethink the plant implies that the system changes include agentification of subsystems, i.e. that existing subsystems (also called legacy systems) are encapsulated into wrapper agents. However, when the usage of wrapper agents is not possible, intermediating agents are used. Intermediating agents act as interfaces between the legacy system and the other agents, i.e. they translate messages in ACL format into the legacy systems native format. Summarizing, main steps for the agentification process that proposes this work are: A. Create a MAS view of the plant In this structural view, the entire system is viewed as a MAS, in which the agents are the sub-systems of the plant (physical and software). Agent roles and attributes are clear after this step. During agentification process, sub-systems will be transformed into agents according to this model. B. Derive a high-level ontology: In a system transformed into a MAS, all subsystems share information by means of the usage of an ACL. Furthermore, agents are able to understand the intentionality of these messages, which express basic actions as request, inform, or reply. But this basic intentionality does not necessarily allow agents to understanding the content of those messages, due to the heterogeneity of the system. Although the results of the analysis stage in the transformation flow, as in each software design problem, depend on each particular case, there are some common features for manufacturing systems like the one we are dealing with [2]. Thus, the usage of ontology, specific for manufacturing domain [18], will provide a semantic context for all subsystems. This means that the outcome of this stage is a set of objects and methods that developers can use in the ACL content language and as common data representation. The ontology designed during this stage of the system transformation can be converted, using open source tools, to a set of classes in any programming language, or XML

schemes (for document representation), forming a set of common libraries that programmers and developers must use. In this real example, a domain specific ontology can be created using Protg [16], this tool allows exporting the ontology to some formats as XML, HTML, OWL, RDF Schema, et cetera. Another advantage of using Protge is that we can use a plug in called ontology bean generator [15], which generates a set of Java files representing the ontology that can be used with JADE [8] multi-agent environment. C. Deploy a suitable middleware As we have seen before, adopting and standardized multiagent requires the usage of a standard ACL (in this case FIPA-ACL) and standard interaction protocols. We could use the existing communications network as a transport layer for our messages, but it requires the implementation of libraries for encoding/decoding of FIPA compliant messages and protocols. Instead of this, a better solution is the use of an existing FIPA compliant multi-agent platform as a middleware between our applications. We are dealing with small manufacturing plants, thus we can use the JADE [8] plat-form in our first experiences of agentification. JADE is an open source and FIPA compliant platform (supports ACL and interaction protocols). It is implemented in Java programming language, and it provides the runtime environment where agents can be run and the corresponding libraries that programmers can use. In our case this is an added advantage as it can be connected to the multi-agent simulator that we created for the ANTSYS architecture [21]. Even so, once the ontology is been created, and main agent roles are clear, this multi-agent platform can be replaced. In our approach, we only use the multi-agent platform as a middleware which provides methods for sending and receiving messages. D. Create system agents Once a multi-agent platform is been deployed as a communications middleware, begins the agentification of legacy systems. This stage consists in selecting a component (usually a legacy system) and transforming it into an agent. This selection and transformation must be done according to the MAS model than has been created during step A. As this is an iterative step, with more iteration more overall system is converted into a MAS, and more overall performance of the system is achieved. As this step consists in the integration of a legacy system, two main agent types are created: wrapper and translators. Wrappers are used when a clear interface or controlling methods are available for the legacy system. In this case the agent controls directly the legacy system ("wrapping" it). When a direct control or interface with the legacy system is not available (for example in the case of old and ad-hoc solutions) translators agents can interact with inputs and outputs of the legacy system , becoming, in fact, an interface of it. E. Simulate the system This is an optional stage. As a model, although is partially agentified, multi-agent system can be simulated, and formal

analysis methods can be applied. Furthermore, simulated (virtual) agents can be introduced in the system interacting with real (and sometimes physical) agents. F. Further creation, adaptation, reuse of agents In a fully, or partial, agentified system new kinds of agents can be introduced, not only wrappers or translators for legacy systems. Reusing of agents from applications of a similar problem domain can be considered. Translator and wrapper agents can be adapted in order to include new applications. The complete scheme of an agentified system is shown in Fig. 2. The progressivity of the approach is clearly illustrated as the system contains components that are not agents at all and that communicate to others that have been agentified either because they use intermediating agents or because are completely wrapped within an agent.

Wrapper agent Legacy system 1

Legacy system 2

Jade container

Translator agent

Nonagentified components

JADE platform RMI JAVA VME

Simulator

Communications network Fig.2.: Complete agentified system

V. A REAL IMPLEMENTATION EXPERIENCE First agentification steps for the real example manufacturing plant are shown here. In this case Nesting Software is the first component that was integrated by using the methodology described up to here. It is in charge of optimizing the wasting of metal sheets by means of optimal distribution of parts over the sheet surface. This software generates CNC code and nesting information (surface usage, number of parts, material type, et cetera). In this theoretical model (shown in Fig. 3) the Nesting Software can be viewed as a simple agent that modifies the environment, that is, its database. Thus we implemented a Controller agent in order to detect those changes. After detecting changes, Con-troller agent decides when they are important enough to be reflected in the global system. In this case, the Controller notifies to the Nesting Software Adapter agent that a con-version must be performed. Doing this, we can use Controller agents for integrating different subsystems in a similar way, only specific Adapter agents must be implemented for each subsystem (for example a CAD tool).

Although in our first experience we did not implement this feature, the Controller may be implemented with the capability to find an appropriate Adapter agent for a specific subsystem by means of a yellow pages service and/or some interaction protocol. In our case, Nesting Software Adapter agent deals with the conversion of the Nesting Software information to a standardized format. Therefore, heterogeneous data is converted to XML format according with our ontology and with our application domain). Finally, the ERP Adapter updates the ERP database from this standardized data regardless of where they come from. Achieved this integration, nesting information is accessible by manufacturing control modules inside the ERP, only a few seconds after it is been generated. Until now, operators in charge of manufacturing control modules had to be informed by technical office workers about new (or modified) nesting programs. Note that, only one ERP Adaper agent is needed in order to integrate some legacy systems into the ERP because, as seen before, adapters for specific legacy systems are in charge of "translating" information into a standardized form according to the ontology. Legacy systems MAS

Fig. 4: An extract of the ontology. Punching tools concepts.

VI. CONCLUSIONS AND FUTURE WORK We have presented our experience adapting a small manufacturing plant to the requirements of modularity, integration of legacy systems, and fast adaptability. This adaptation is done through a process of agentification, i.e. of transforming the existing system components into agents and, consequently, the whole into a MAS. The process has been designed to be gradually implanted because of the criticality of disturbing production plans. Although this is a very preliminary work, we have achieved some good results. First benefit has been the saving in time of development cycle of the parts. In our first experience in a real plant we have eight machine tools for cutting and punching tasks. Usually, human operators modify or create about four CNC programs per day using Nesting Software. And, then, they spend about 15 minutes for introducing some of the obtained results into the ERP modules. The implementation of the model seen in the previous example supposes saving about 8 hours of human work per day. There are also benefits in terms of data reliability and coordination between humans and the system, since operators can be notified of changes in NC programs fastly, and they can overview available programs for a certain task/machine combination.. And this is achieved integrating only one subsystem. Furthermore, first step in adaptability has been done since we can deploy new Controller agents and implement new Adapters for more software legacy systems. Benefits in reliability of the global system are clear due to standardization of heterogeneous data (in XML format and according to ontological concepts). This is, all subsystems understand the same language and relevant information is transmitted with the same value for all of them. Our next step is the agentification of machine-tools, a more critical component of the system. If results are good enough, we will be able to provide a verified ontology, Java libraries, and generic agents for this manufacturing domain. Furthermore, if we achieve the goal of having agentified the entire plant, we will work in solving problems that can not

CAD Database

Detecting changes in DB Controller agent

Nesting Software

Adapter agent collection

Nesting SW Adapter agent

ERP software

Ontology compliant data (XML)

ERP Database

XML to DB conversion

ERP Adapter agent

Fig. 3: MAS model of Nesting Sofware sub-system

For this first implementation, a simple ontology was modelled using Protegee. But, due to the requierements of the enterprise , it transformation into Java package was not possible. Instead, the ontology is transformed into a set of XML schemes (XSD files) which can be binded to a package of Microsoft NET framework classes. An extract of this XML ontology is shown in Fig. 4. Although preliminary implementations built in laboratory, and the model, were thought for working over a Jade platform, the communications layer in the real plant was based on Microsoft Operating systems and DCOM distributed components. Thus, a multi-agent platform is not used as a middleware in first implementation. Agents are taking advantage of existing DCOM distributed model [1].

be solved in current situation. For example, applying distributed problem solving techniques to our manufacturing plant, or trying to convert the system to a holonic manufacturing system. ACKNOWLEDGMENT This work has been partially supported by the Spanish Ministerio de Educacin y Ciencia project ref. TEC200508066-C02-02, COCOABOTS, Me Too: Colonies of collaborative autonomous robots. methods and tools. Jonatan Trulls is with G2-Software, for which the work is done, in accordance with the client that required the change in its manufacturing plant.

[6] [7]

[8] [9]

[10] [11]

[12]

REFERENCES
[1] Barata, J.; Camarinha-Matos, L. ; Boissier, R.; Leito,P.; Restivo, F. and Raddadi, M., "Integrated and Distributed Manufacturing, a Multi-agent Perspective", in Proc. of 3 rd Workshop on European Scientific and Industrial Collaboration, 27-29 June, 2001. Borgo, S. and Leito,P. Foundations for a Core Ontology of Manufacturing, in Ontologies: A Handbook of Principles, Concepts and Applications in Information Systems, R. Sharman, R. Kishore and R. Ramesh and (eds.), ISBN: 0-387-37019-6, 2006, Chapter 6, pp. 751-776, Springer. De Vin, L. J.; Oscarsson, J.; Ng,A.; Jgstam, M and Karlsson,T., Manufacturing Simulation: Good Practice, Pitfalls, and Advanced Applications, published at 21st International Manufacturing Conference, pp. 156-163, Limerick, Ireland. 2004. De Vin, L.J.; Ng,A.H.C.; Oscarsson, J. and Andler,S.F., Information Fusion for Simulation Based Decision Support in Manufacturing, FAIM 2005 Special Issue of Robotics and Computer Integrated Manufacture, Vol 22, pp. 429-436, 2006. FIPA Standard Specifications. Available: http://www.fipa.org/repository/standardspecs.html.

[13]

[14] [15] [16] [17] [18]

[2]

[3]

[4]

[19] [20]

[5]

[21]

[22]

Foundation for Intelligent Physical Agents (FIPA). Available: http://www.fipa.org/. Huhns, Michael N. and Stephens, Larry M. Multiagent Systems and Societies of Agents in Multiagent Systems: A Modern Approach to Distributed Artificial Intelligence. Weiss, G. Cambridge, MA: MIT Press, 2000, pp. 79-118. Jade [Online]. Available: http://jade.tilab.com Labrou, Yannis. "Standardizing Agent Communication", in MultiAgent Systems & Application, Advanced Course on Artificial Intelligence (ACAI-01) proceedings, Vladimr Marik and Olga Stepankova (editors), Springer-Verlag, 2001. Mataric, Maja J., Interaction and Intelligent Behavior, MIT AI Lab Tech Report # 1495, Aug 1994. Mayfield, James; Labrou, Yannis and Finin, Tim. Desiderata for agent communication languages in Proceedings of the 1995 AAAI Spring Symposium Information Gathering in Distributed Environments, March1995. Mehrabi, M. G., Ulsoy, A. G., & Koren, Y. (2000). Reconfigurable manufacturing systems: key to future manufacturing. Journal of Intelligent Manufacturing, 11(3), 403-419. Nestler A.& Dang T. N., "The application of a multi-agent system for process management and NC data transfer aided by a DNC system", in Advances in Production Engineering & Management. Volume 3. Issue 1. March 2008, pp. 13-16. NGMS-IMS Project. Interim Report. Submitted April 2000. Available: http://www.cam-i.org/. Ontology bean generator [Online]. Available: http://protege.cim3.net/cgi-bin/wiki.pl?OntologyBeanGenerator Protege ontology editor [Online]. Available: http://protege.stanford.edu Ross, Robert J. MARC - Applying Multi-Agent Systems to Service Robot Control. MSc Thesis. University College Dublin. 2003. Schlenoff, C.; Denno, P.; Ivester, R. and Szykman, S.: "An Analysis of Existing Ontological Systems for Applications in Manufacturing," in Artificial Intelligence for Engineering Design, Analysis, and Manufacturing, Vol.14, No.4, January, 2000, pp. 257-270. Searle, John. Speech Acts. Cambridge Univesity Press, Cambridge, England, 1969. Shao, G., Lee, Y. T., and McLean C., Manufacturing Data Validation Through Simulation, in Proceedings of the 2003 European Simulation and Modeling Conference, pp 56-60, Naples, Italy, October 27-29, 2003. Trulls, J. and Ribas, Ll. Simulacin de las comunicaciones en el sistema de robots hormiga ANTSYS, in VI Workshop en Agentes Fsicos, WAF2005, pp.75-82, Sept. 2005. Wooldridge, M. J. Intelligent Agents in Multiagent Systems: A Modern Approach to Distributed Artificial Intelligence. Weiss, G. Cambridge, MA: MIT Press, 2000, pp. 27-79.