Implementing a Contract-based Multi-Agent Approach for Shop Floor Agility José Barata New University of Lisbon – FCT Quinta da Torre, 2829-516 Caparica Portugal
[email protected] Abstract This paper describes implementation approaches for a multiagent shop floor control architecture supported by cooperation contracts and designed to support agile manufacturing. The architecture being proposed is based on the concepts of cluster, consortium, manufacturing components, manufacturing resource agent, agent machine interface, and contracts, which are used to govern the skills brought to the consortium or cluster. The basic architecture for each agent is indicated and analysed as well as the knowledge model and ontologies used. Finally the development environment is presented and some practical results are shown.
1. Introduction Manufacturing companies are facing radical challenges. Worldwide competition, customers desire for exclusive product variety in small quantities (mass customisation), demands for higher quality and lower prices, product complexity, faster delivery times, shorter product life cycle as well as fast technological evolution and new environment protection regulations, are just examples of demands facing up by manufacturing companies. Some of these changes have been foreseen before [1]. However, the pace of change is much bigger and more challenging. Therefore, companies are recognising the need for fast reconfiguration or adaptation (agility) as an important requirement in their daily life operations. To be more responsive and cost effective companies are creating collaborative networks with both customers and suppliers (Virtual Enterprises). However, the side effect of this strategy is an increasing complexity on the whole system that requires changing the business models and re-engineering the processes.
L. M. Camarinha-Matos New University of Lisbon – FCT Quinta da Torre, 2829-516 Caparica Portugal
[email protected] A key facet in this context is agility, which is defined as the ability to thrive and prosper in an environment of constant and unpredictable change [2]. The challenges imposed by Agile Manufacturing cannot be achieved without preparing the shop floor to accommodate change. This must be stressed because most of the research works on agility have only addressed new organisational forms including methods and tools for the managerial aspects of companies. Despite the FMS (Flexible Manufacturing System) work done in the eighties [3], much less attention has been devoted to the agility aspects of the shop floors. From the shop floor point of view, agility extends the concept of flexibility by adding the ability to change under uncertainty or adapt to a changing environment. Further details can be found in [3, 4]. This paper describes implementation approaches for a multiagent shop floor control architecture supported by cooperation contracts and designed to support agile manufacturing. In this architecture, shop floor controllers can be interconnected and/or grouped in different ways (dynamic operation of the shop floor), forming different control structures, with minimal programming effort.
2. Problem Statement Coping with change under uncertainty involves continuous shop floor adaptations/transformations. A global methodology to support the different phases of the system life cycle, where individual methodologies and tools in turn support each individual phase is an important contribution to increase the level of agility. However, this paper is only focused on one of the activities of the life cycle: re-engineering of the control architecture. The main reason for concentrating the work on the controllers is because changing/adapting them accounts for a big share on the global effort of changing/adapting the production system as well as on the whole agility level. A more flexible, easier and faster process of
Proceedings of the 13th International Workshop on Database and Expert Systems Applications (DEXA’02) 1529-4188/02 $17.00 © 2002 IEEE
generating the control system will turn the process of change/adaptation faster and consequently more agile [5]. An agile shop floor control re-engineering methodology should ideally satisfy the following requirements: Requirement 1. Departing from a manufacturing cell, with its set of manufacturing components, it should be possible to create dynamic control architectures in order to generate different functional structures. Requirement 2. The addition or removal of any manufacturing component should be done smoothly, with minimal programming effort or side effects in the others’ components. Requirement 3. Legacy and heterogeneous controllers should be considered in the global architectures and a process should be found out to integrate them in the new agile architecture. The complexity of the implementation of an approach to satisfy these requirements is further increased because the shop floor is generally composed of various and heterogeneous controllers that must be integrated.
3. The Architecture Some similarities can be found between this complex problem and what happens in the area of networks of collaborative enterprises (virtual enterprises). Therefore, looking at the approaches being taken in that domain can act as a source of inspiration for the shop floor reengineering problem [4]. In the Virtual Enterprises area, a new consortium (group of companies) may be established whenever a business opportunity exists. The companies can add or leave the consortium whenever they want and when the business opportunity terminates the consortium is extinguished. The relationships among the members of the consortium are regulated by contracts. To facilitate consortia formation companies may be associated in clusters, i.e. groups of manufacturing companies that are willing to co-operate and that have arranged for interoperable infrastructures and common business practices. Similarly, whenever a new shop floor functional structure is needed because of a re-engineering process the required manufacturing components can be chosen from the set of existing components whose basic infrastructures were made interoperable (cluster) and grouped together (consortium). This group is maintained while the opportunity exists. If a manufacturing component needs to be removed due to, for instance, a malfunction, this should be possible without damaging the working group (consortium). The same should happen if a new component is added. Comparing the two worlds (shop floor and business) the similarities are evident.
The basic components of the proposed implementation are clusters, consortia, contracts, brokers, manufacturing components, Manufacturing Resource Agents (MRA), and Agent Machine Interfaces (AMI). A shop floor is regarded as a micro-society, made of manufacturing components. The components have basic core capabilities and, through co-operation, can build new capabilities. A robot, for instance, is capable of moving its tool centre point and setting different values for speed and acceleration (Figure 1). When this same robot co-operates with a gripper tool, it is possible to have pick-and-place operations. Move_ptp() Move_ref() Set_Acc() Set_Speed() In() Out()
Open() Close() Tool
Robot
Figure 1. Basic Components and Competencies
In the proposed approach every component is associated to an agent that represents its behaviour. These agents must interact in order to generate aggregated functionalities that in some cases are more complex than the simple addition of their individual capabilities. A set of agents working together towards a common goal is called a consortium. The consortium is the basic organisational form of co-operation. To facilitate the organisation of consortia they are classified in two types: simple consortium (SC) and complex consortium (CC) (figure 2). A SC is composed of a Manufacturing resource Agent (MRA), an Agent Machine Interface (AMI) and the manufacturing component controller. A simple consortium corresponds to a manufacturing component extended with agent skills like negotiation, contracting, and servicing. A complex consortium (CC) can be composed of simple and/or other complex consortia creating in this way a hierarchy of consortia. In order to participate in consortia any manufacturing controller must be agentified. The agentification process could be done by developing an agent that could simultaneously interact with the controller and participate in consortia, which is very demanding in terms of contractual negotiation and composition of skills. This agent would be the basic unit to create consortia. However, the requirements imposed by the interaction with the controller (short response time, interaction protocol specificities, ...) advise for the use of a dedicated agent to interact with the controller. Therefore the approach was to separate the functionalities and to have one dedicated agent to interact with the controller and a generic agent specialised on contractual negotiation and skills composition, which could be used in any situation. This is why the basic unit to create consortia is the SC, composed of the controller, the AMI, and the MRA.
Proceedings of the 13th International Workshop on Database and Expert Systems Applications (DEXA’02) 1529-4188/02 $17.00 © 2002 IEEE
The MRA is a generic agent that is used to both coordinate simple and complex consortia. The set of potential skills (operations) of a consortium led by a MRA is composed of the basic operations brought by the consortium members plus the generated complex operations that can be composed using the basic ones [5]. When the MRA is leading a simple consortium the basic operations are those supported by the AMI. In this case the MRA co-ordinates the AMI. When leading a complex consortium the basic operations come from the set of operations brought to the consortium by all members. In this case the high-level MRA co-ordinates each of the other lower-level MRAs that are leading a consortium. Therefore a MRA does not play only the role of coordination. It co-ordinates lower level MRAs and is coordinated by a higher-level MRA. In figure 2 MRA C and MRA B are simultaneously co-ordinators and members of the consortium led by MRA A. The AMI is the agent wrapper of a manufacturing component and exports all the functionalities existing in its physical controller. Therefore a consortium represents a group of interacting manufacturing agents with a common goal that as a whole can provide more complex skills than just the sum of the individual skills brought by each member. AMI
Tool
Tool Warehouse Robot
Tool Tool
Robot
T ool Warehouse
Agentification & Creation of Simple Consortia (SC)
AMI
MRA
MRA
Simple Consortium (SC)
Join the Cluster
Robot
SC
Tool
SC
Tool Warehouse
Lathe SC
Conv SC
Tool
Tool
SC
SC
Tool Warehouse
SC
AMI
Simple Consortium (SC)
Robot
CONSORTIUM FORMATION
MRA C Complex Consortium
Robot
SC
Lathe SC
Tool
CONSORTIUM FORMATION
Simple Consortium (SC)
Robot
1. relevant relationships 2. facilitate search of SCs 3. harmonisation of ontologies 4. ...
Cluster
SC
MRA A
AMI
Simple Consortium (SC)
Tool
CONSORTIUM FORMATION
MRA B
because they constrain the generation of complex operations by a MRA that are dependent on the basic operations expressed in the contract. It is possible to generate different complex operations by just changing the terms (skills) of the consortium contract. Consequently the requirement 2 of the problem statement section is answered. In the proposed implementation there are two kinds of contracts: cluster adhesion contract to regulate the interaction with the cluster, and multilateral consortium contract to regulate the behaviour of the consortium [5].
Figure 2. Hierarchy of Consortia
Creating different consortia is just creating different organisational structures with its different skills. This answers requirement 1. The skills of any co-ordinating MRA are dependent on the contracts established between it and its consortium members. The contract each agent has established with the consortium regulates its behaviour. The terms of the contract are mainly the type of skills each agent is bringing in and the reward they will get from their participation [5]. The value that is exchanged (consideration) in the contract is important during the formation of the consortium (those with better curricula will be chosen first) and when the contract is finished by breach, where penalisations might apply. When an agent is added to a consortium the capabilities or capacities of the consortium co-ordinator (MRA) might be increased, and the contrary happens when the agent leaves it. However, this update of skills or capacities can be automatic using only contract renegotiation, which simplifies the process of addition/removal of an element. Contracts are important
Complex Consortium
Complex Consortium Complex Consortium
Figure 3. Consortia Formation
Before creating a consortium it is necessary to search for candidate agents. Then they must be checked to guarantee if they have spatial relationships (or any other relevant relationship) with the other elements. Finally it is necessary to find out if the agent “speaks the same language” as the consortium to be joined. Therefore, if agents are grouped on a structure, called cluster, which contains all the agents that can establish relationships or share some concepts [5], the process of creating consortia will be easier and faster. The relationship between the candidate agent and the cluster is also governed by a contract. To participate in consortia every manufacturing component needs to be agentified (extended with agent skills), which results in the creation of simple consortia
Proceedings of the 13th International Workshop on Database and Expert Systems Applications (DEXA’02) 1529-4188/02 $17.00 © 2002 IEEE
(SC). Therefore SCs are the basic unit from which the consortia can be generated and consequently the cluster is formed by these basic units, instead of pure manufacturing components. The creation of a consortium will not be automatic but rather done with the help of another entity: a broker. The broker will interact with the candidate agents and with the user to create or change a consortium. The broker main advantage is to simplify the negotiation process whenever the consortium is being changed or created. Figure 3 shows how manufacturing agents are related to the cluster and consortium.
4. MultiAgent System Implementation The developed system is based on the agents already referred to in the architecture section: broker, cluster manager, agent machine interface (AMI) and manufacturing resource agent (MRA). These agents are described by indicating their basic behaviours and the agents with whom they are interacting. In this context, behaviour is the aggregate of actions and interactions with other behaviours in response to events to achieve some task. For now nothing is said about the implementation of these behaviours because if they are simple they can be implemented as a normal executing thread within the agent. However, if complex they can be delegated to another slave agent working in the framework of the global agent.
4.1 Behaviours
informed. The second behaviour exists only for user interface purposes (Figure 4). Manufacturing Resource Agent. This is the core agent when creating consortia and is in all cases the coordinator of the consortium. However, when the consortium led by a MRA participates in another consortium as a member it has another complementing role, which increases its complexity. As a result two types of contract roles must be managed by the MRA: membership and co-ordination roles. This justifies the existence of two behaviours related to contracts: one to manage the contracts led by the MRA (Co-ordinating Contracts Management) and the other responsible for the contracts where the MRA participates as a member (Membership Contracts Management). It should be pointed out that co-ordinating contracts are the source for the skills of the MRA. At least the MRA has the skills brought in by the members of the consortia it manages. However, it can increase this set of skills by generating new ones from the basic set. This is the objective of the behaviour SkillGenerator. The rules to be applied in the composition of skills are modelled using the Prolog language. Higher Level MRA
Broker
Manufacturing Controller
User
AMI MRA Servicing
KB & Ontologies
User Interface
Figure 4. AMI Behaviours
When the command is executed the enquirer MRA is
Broker
MRA
Servicing
User Interface
GetInfo Cluster
Skills
Higher Level Agent
Agent Machine Interface. The AMI is always connected to a physical controller (Robot, PLC, …) and implements the services (skills) supported by the physical component [5]. The generic AMI agent is a simple agent composed of two simple behaviours. The first behaviour accepts requests for services from the MRA and then calls the wrapper to execute the requested service. An example of request for a robot move using world coordinates is: ((requestService serviceName moveWcService arg1 (5DofType alfaArg 45.0 vel 80.0 xArg 34.0 yArg 12.0 zArg 10.0))). The service asked is moveWcService and the argument is a frame from the class 5DofType. This message is coded using the FIPA SL0 language.
User
Lower Level MRA
Cluster Contrac Management
Membership Contracts Management
Consortium Members
Existing Skills
Skill Generator
New Complex Skills
Coordinating Contracts Management
Broker
KB & Ontologies Contracts
Figure 5. MRA Behaviours
An example of this situation occurs when the MRA leads a consortium formed by two other consortia, which bring the skills move and change tool (from a robot), and grasp (from a gripper). With these skills the MRA’s set of available skills can be increased by pick&place, which is a composition of move, changeTool and grasp. The following Prolog rule allow the automatic generation of a new complex skill: pickPlace(A,B) :- moveSkill(A,X), grabSkill(B,Y), changeTool(X,_,_,_). Another behaviour related to contracts is the Cluster Contract Management that deals with the cluster contract. The three contract-related behaviours, although complex, are very similar in operation. These behaviours include the negotiation, the contract validation
Proceedings of the 13th International Workshop on Database and Expert Systems Applications (DEXA’02) 1529-4188/02 $17.00 © 2002 IEEE
(signature), the performance of the contract, and finally the contract termination phases. Each of them is composed of several actions (sub-behaviours) with different complexity levels. The contract termination phase, for instance, includes different types of termination, which apply for different types of actions. Terminating a contractual relationship by performance (expiration) is different than terminating it by breach which involves different types of interactions.
methodology that transforms a manufacturing component into an agent entity (agentification). Further details in [5]. User
Broker
User Interface
GetMembersList
ClusterManager MRA
Servicing
Cluster Contrac Management
New Complex Skills
REFUSE
MRA
Skills
Existing Skills
AGREE & DONE (to broker)
Skill Generator Broker Refuse
WaitForReqSer WaitForSubscription
KB & Ontologies Contracts
Regist/Change Consortia REQUEST subscribe (from broker)
Figure 7. Cluster Manager Behaviours SubscribeCoordinationContract REQUEST Service (from coordinator)
AGREE & DONE (to broker)
WaitForStart INFORM StartContract (from broker)
ConsortiumChangeNegotiation
Figure 6. Coordinating Contract Mgmt Behaviour
Figure 6 shows an example of an AUML behaviour diagram for the coordinating contract management. The servicing behaviour is the execution central point, because it is where the commands are executed and where the global behaviour of the consortium and hence of the global system is carried out. The most important aspect of this “machine” lies on the fact that its operation is completely dependent on the relations established by its MRA. It transforms a request from a higher level MRA (higher level operation) into a set of lower level operations that must be requested to lower level MRAs. It can be seen as an independent machine that operates based on the available lower level operations (expressed in the coordinating contracts). Every received high-level request has to be validated by checking if it was offered in the consortium contract led by the sender MRA. The order by which the sub commands that compose the complex one are sent depends on the graph that describes that specific high-level command. The executing machine is based on a Petri Net executor and consequently the commands are described as simple Petri Nets [6]. The behaviour Get Info when requested by the broker supplies it with information about the agent skills. Cluster Manager. As it was mentioned before the cluster is composed of simple consortia that are created using a
The resulted SC must then join the cluster, which is done by establishing a cluster contract, which defines what are the skills to be brought to the cluster by the consortia and what services from the cluster can be required by the consortia. The behaviour Cluster Contract Management is responsible for this contractual negotiation with the MRA of the candidate consortium. The behaviour Servicing is similar to the same behaviour in the MRA but less complex. It executes the commands provided by the Cluster Manager. The behaviour Skill Generator is similar to the MRA one. The skills in the Cluster Manager just represent the potential capability of the whole members of the cluster. The behaviour Register/Change Consortia updates the cluster with information about new consortia that were formed by the broker (consortia of type 2). The behaviour Get Member List gives to the broker, when requested, the list of all the members of the cluster. User Cluster Manager
Broker MRA Get Member Info
User Interface
ReqMembersList
MRA
Cluster Manager
MRA Coordinating Contracts Membership Contracts Management Management
Update Consortia
KB & Ontologies Contracts
Figure 8. Broker Behaviours
Broker. The broker agent is responsible for creating and changing consortia, in interaction with a user. Because this agent is described in [5], its behaviours are very
Proceedings of the 13th International Workshop on Database and Expert Systems Applications (DEXA’02) 1529-4188/02 $17.00 © 2002 IEEE
similar to the ones already defined, and due to space restrictions, only the figure of the behaviours is presented (Figure 8).
4.2 Knowledge & Ontologies Communication and interaction among individuals and about a domain can only take place if some conceptualisation of that domain exists. The world of computers, and particularly agents is not different. In the case of this specific architecture all the agents need to share some basic concepts, such as skills, contracts, credits, arguments, requests, services, and agent. The explicit specification of these concepts is called an ontology [7]. All the agents of the proposed architecture share at least one basic global ontology that models the basic concepts.
kind of value (revenue). An agent joins a consortium in exchange for some value, which is in this case a score that will be assigned when the consortium is terminated. This score (consortiaAverageScore attribute) rewards the agent for its work.
Figure 10. Credits Concept
The agent curriculum (credits) also includes other attributes that are used to qualify the reliability and experience of the agent as it is the case of clusterParticipation, badBehaviourPenalties (the agent did not execute properly), dateOfBirth, nBreakdown (number of malfunctions) and breakDownTime. When an agent wants to join a cluster the cluster manager asks immediately for its credits. The credits are classified in a hierarchy because not all the agents share the same type of attributes to represent their credits. Some attributes are based on the type of work the agent does. The other concepts have been also modelled in this way. It should be noted that all required knowledge beyond ontological has been modelled using Protégé, which allowed to program the agents using a frame based paradigm that is more flexible. Figure 9. Skill Concept
There are other concepts that are particular to some agents, which are modelled by specialised ontologies. The ontologies were developed using Protégé-2000 [8]. The main advantages of using this tool is its knowledge model (frame-based), friendly user interface that speeds the process of creating domain knowledge, and extensible architecture that enables easy integration with other applications. In this way the operational part (the agent) can be separated from the knowledge domain (Protégé). Part of the skill concept can be seen in figure 9, which shows two simple skills (grabSkill and moveSkill) and one complex skill (pickPlace). An instance for each of these skills is also shown. A skill is a talent or ability, which is different from an order or request to put in action that skill. Credits (Figure 10) are an important concept because they are a kind of agent curriculum, which includes some
Figure 11. Commands concept
The agents use FIPA SL0 language to communicate, which is a standard already supported by several Multiagent development environments, as it is the case of the one used in this work. To validate the semantics of the communication an ontology of commands was developed and each message content is composed using the respective concept in the ontology. In the receiver the content is extracted and validated against the model in the ontology. When the agent is negotiating with the cluster it starts the process by sending the following message:
Proceedings of the 13th International Workshop on Database and Expert Systems Applications (DEXA’02) 1529-4188/02 $17.00 © 2002 IEEE
(REQUEST :sender (agent-identifier :name robot@mac-jab:1099/JADE) :receiver (agent-identifier :name cluster@mac-jab:1099/JADE)) :content ((joinCluster type robot)) :language FIPA-SL :ontology cmd-ontology :protocol fipa-request )
through the API supplied by Protégé. Jinni Prolog was used and integrated with JADE to develop the generateSkill behaviour.
6. Conclusions
The cluster replies asking for the credits: (QUERY-IF :sender (agent-identifier :name cluster@mac-jab:1099/JADE) :receiver (agent-identifier :name robot@mac-jab:1099/JADE)) :content ((askCredits what objectiveCredits )) :language FIPA-SL :ontology cmd-ontology :protocol fipa-query )
If the contents of both messages are compared to the frame description of the joinCluster and askCredits frames (Figure 11) the similarity can be seen. Figure 12 shows the interaction messages that are generated when a consortium receives a request for servicing.
0000 0000 00 0000 0000 0000 0000 0000 00
higher-level MRA
MRA
REQUEST Serv()
Done()
0 0 0 0 0
0000 0000 00 0000 00 0000 00 00
member 1
AMI 1
member n
This paper described implementation approaches for a multiagent architecture supported by cooperation contracts for shop floor control. The main behaviours associated to the cluster, broker, and MRA concepts were described and explained. The knowledge base to support the agents was described and the concepts of skill, service, credits, and commands were presented.
7. Acknowledgments This work was supported in part by the European Commission through the ASSEMBLY Net and THINKCreative projects.
AMI n
References
0000 00
00 REQUEST Serv-1() 00 00 00 00
REQUEST Serv()
Done-1()
Done()
00 00 00 00 00
[1] National Research Council . Committee on Visionary Manufacturing Challenges, Visionary Manufacturing Challenges for 2020. Washington: National Acad. Press, 1998.
00 00 00 00 00 00
REQUEST Serv-n()
Done-n()
0 0 0 0 0
00 0
[2] S. L. Goldman, R. N. Nagel, and K. Preiss, Agile competitors and virtual organizations: strategies for enriching the customer. New York: Van Nostrand Reinhold, 1995.
00 00 00 00 REQUEST Serv() Done()
00 00 00 00 00
00 00 00 00 00 00 00
Figure 12. Commands concept
5. Development Environment JADE – Java Agent Development Platform was chosen as the development platform for several reasons: 1) it is open source, 2) has good support and documentation, 3) implements the FIPA Architecture including the FIPA Agent Communication language and FIPA protocols that saves programming time, 4) and finally the behaviour abstraction model, which is used to model the tasks that an agent is able to perform. Agents execute their behaviours according to their internal status and the messages (external events) they receive from other agents. The behaviours described in the previous section were implemented using this abstraction model. The connection between these behaviours and the knowledge base (Protégé) is done
[3] P. Leitão, J. Barata, L. M. Camarinha-Matos, and R. Boissier, "Trends in Agile and Co-operative Manufacturing," presented at LCA 2001 - 6th IFAC Symposium on Cost Oriented Automation, Berlin - German, 2001. [4] L. M. Camarinha-Matos and J. Barata, "Contract-Based Approach for Shop-Floor Re-engineering," presented at LCA 2001 - 6th IFAC Symposium on Cost Oriented Automation, Berlin - Germany, 2001. [5] J. Barata and L. M. Camarinha-Matos, "Contract Management in Agile Manufacturing Systems," in Collaborative Business Ecosystems and Virtual Enterprises, L. M. Camarinha-Matos, Ed. New York: Kluwer Academic Publishers, 2002. [6] R. Zurawski and M. C. Zhou, "Petri Nets and Industrial Applications - a Tutorial," IEEE Transactions on Industrial Electronics, vol. 41, pp. 567-583, 1994. [7] T. R. Gruber, "Toward principles for the design of ontologies used for knowledge sharing," International Journal of Human-Computer Studies, vol. 43, pp. 907-928, 1995. [8] N. F. Noy, R. W. Fergerson, and M. A. Musen, "The knowledge model of Protege-2000: Combining interoperability and flexibility," presented at Knowledge Engineering and Knowledge Management (EKAW'2000), Juan-les-Pins, 2000.
Proceedings of the 13th International Workshop on Database and Expert Systems Applications (DEXA’02) 1529-4188/02 $17.00 © 2002 IEEE