For example, MQ organizeActivities A represent the motivation to organize activities for user A assume "A" is the identification for this unique user.
When the two personal assistance agent instances are instantiated for user A and B, they have different values for their attributes such as name, user and identification. A brief representation is: MQ name MQ subject. The subject of MQ is a set of entities, which can be defined in one of the following ways or a combination of them:. Such extension makes it possible to support dynamic organization structure. This motivation is created for the agent class in the design phase, agent x is an instance of such agent class.
In the system runtime, agent x joins a group A , it also forms a group B with other agents. According to the motivation to serve the groups it belongs to, agent x is willing to work on goals that serve both group A and B. Under this extended definition, we have the following definition on the relationships of MQs. Definition 3. Dynamic organization structure is very important for multi-agent systems to function efficiently, as other researchers also recognized.
Our framework has this same virtue, though we adopt a quite different approach that combines role-based modeling and quantatitive reasoning. Sensor data refers to the input for the agent.
For robot agents, the sensor data is collected by different sensors, like camera, speedometer, etc. For software agents, sensor data refers to the messages and information the agent receives from the environment including other agents. Each agent is equipped with a set of reasoning mechanisms, which are used for the following purposes:. Decide what goals the agent should pursue at this moment. The agent may take multiple roles and each role may have multiple goals, so the agent needs to decide which goals it need to focus on at this moment based on how the goals contribute to its motivations, how each goal could be achieved given the resource and time constraints.
This issue is related to the next issue. Decide how to achieve a goal given the available alternatives, resources and time constraints. Some planning and scheduling mechanisms are needed for this decision. In general, agents decide what to do using the reasoning mechanisms.
The decisions are made at different levels: selection of roles, selection of goals, and selection of the approach to fulfill the goals. The first issue is resolved by role-agent mapping mechanisms, and the later two issues are inter-related, which are solved by planning-scheduling mechanisms. More details of these two types of reasoning mechanisms are described in Section 5 after the detailed description of role is presented. Execution mechanisms are used to generate the output, which changes the environment.
For robot agents, their actors such as their motors, are the execution mechanisms, which are used to execute some actions to change the environment states. For software agents, the execution mechanisms are the primitive actions to change the environment state. Some of these execution mechanisms are domain-dependent. For example, the personal assistant agent is built with execution mechanism to perform an online purchase, which is not built in a mathematics theorem proven agent. Other execution mechanisms are application-independent but platform-dependent, such as sending a message.
Some common execution mechanisms can be built as toolkits and reused for different applications. Figure 4 shows the definition of role class.
Multiagent Systems for Manufacturing Control. A Design Methodology. Authors: Bussmann, Stefan, Jennings, Nicolas R., Wooldridge, M.J.. Free Preview. Abstract. The ability of production companies to rapidly develop and deploy effective and efficient control systems is critical for success in the.
Same as agent, a role is defined with a set of attributes, such as role name and identification. A role is also defined with a set of goals, each goal is associated with a plan tree, which is a hierarchal description of the alternatives to accomplish a goal. For example, there is a meeting coordinator role, which has a goal defined as:. This goal generates two types of MQs, meaning that the achievement of this goal contributes to two abstract goals: organize activity for any member that belongs to this meeting group and serve this meeting group.
The degrees of the contributions are represented by the units of the MQs, 3 and 5 respectively in this example. It should be noticed that the meeting group is an abstract concept when this role is defined as a role class, this concept represents any group who needs to have meetings. When an role instance is instantiated from this class, this abstract concept is instantiated as a concrete group. Depending on the context when the meeting coordinator role instance is created, a specific group will replace this abstract meeting group in the goal definition.
Assume that two meeting coordinator role instances CA and CB have been created, as shown in Figure 5 , one for group A , and another for group B. Both of them have the goal of the same name but not the same MQPS. All agents who belong to group A are motivated to take the role CA , those agents who belong to group B are motivated to take the role CB , those agents belong to both groups are motivated to take both role instances.
For each goal associated with a role, there is a plan tree to describe the possible alternatives to achieve this goal. This plan tree is part of the domain knowledge and needed to be defined by the user. The attribute role specifies what roles are needed to carry this goal or subgoal. For example, Figure 6 shows the plan tree for the goal Provide Cure , which belongs to the role Physician. The min quality accumulative function qaf associated with the goal Provide Cure specifies the following relationship:.
In other words, the min quality function associated with a goal describes that the success of this goal depends on the success of all of its sub-goals. On the other hand, the use of max quality function represents that there are several alternatives to achieve the goal. Each subgoal can further be decomposed into smaller goals, i. For some non-local goals - the tasks need to be performed by other roles, the specification of the other role is included in the plan tree description.
For example, Clinical Test enables Test Interpretation describes the fact that the first goal Clinical Test needs to be achieved successfully before it is possible to implement the second goal Test Interpretation. In addition, Read Medical History Record facilitates the Clinical Test process because it may provide some useful information about the patient.
For example, the plan tree for the subgoal Provide Care is described in Figure 10 , this information belongs to the role Nurse Assistant. It provides fundamental knowledge for agents to plan and schedule its local activities, and it also supports the collaboration and cooperation among agents. More details are presented in Section 5. In this Section, we will discuss more details on how a multi-agent system will be developed and operated based on the RADE framework that we have presented in  and earlier in this paper.
In RADE framework, agents can dynamically choose the role instances, and role instances can be created dynamically too. In the development phases, roles and agents are designed separately. In the implementing phases, agents are created by users.
In addition, there is a role space component built in the system with the following functionalities:. Keep record of all role instances that have been created and their current status: whether this role instance has been taken and the creator of this role instance. Reply messages from agents for querying the current available role instances. Create new role instances according to the requests from agents or users.
Delete obsoleted role instances according to the requests from agents or users. Monitoring the role-agent mapping processes by verifying the qualification of agents and checking the constraints on role interrelationships, to ensure the new role instance is compatible with other role instances that have already been taken by the same agent. When the system execution starts, one or more role instances are created by a human user. Those agents who are interested in taking a particular role instance send messages to the role space. The role space then checks the qualification of the agents.
The verification process is based on two criteria:. Whether the agent A has the capability to take this role instance R. The following conditions are checked:. Whether this role instance is consistent with other role instances that the agent currently takes.
This condition is checked based on the incompatibility relationships defined in the role organization. After this process, a list of qualified agents is sent to the creator of this role instance in this case, the creator is the human user, it can be an agent too. The creator then selects one agent from this list to take the role instance.
When an agent takes a role instance, it checks the goals that belong to this role instance and decides if more role instances need to be created to carry the subgoals or to achieve some necessary preconditions. If this is the case, more role instances will be created and posted in the role spaces. The process described above is repeated until no more role instances are created.
According to the above definition, there may be multiple role instances an agent is interested at the same time. How much the agent is interested in a particular role instance depends on the following:. The type and number of units of MQ associated with the goal that belongs to this role instance. Similar mechanisms can be adopted here for agent to select the appropriated role instances. Since each goal defined in a role instance essentially represents a task to be accomplished, so the role-agent mapping process is a task allocation process.
In this process, the agent decides which task it would like to take depending on the user-defined preference functions, its previous experience on accomplishment of such tasks and its resource limitation. Kamboj and Decker has proposed an organizational self-design approach in semi-dynamic environment . Agents can be dynamically created or merged together depending on the needs of the system at runtime. It also uses role-assignment to assign a task to an agent.
Additionally, our work proposes an integrated approach for designing and implementing MAS. In our approach, a lot of domain knowledge can be represented in the definition of roles. We also adapt a motivational quantitative measure for agents to evaluate what tasks are interesting. These make our work quite different from theirs. The planning and scheduling mechanisms are used to generate a linear schedule of activities for the agent to execute.
The plan tree associated with each goal consists of all possible alternatives to achieve a goal, it is not a linear schedule. In an open agent society with distributed information, resources and tasks, agents need to collaborate and cooperate on their actions. Efficient collaboration and cooperation mechanisms are important to the performance of the system.
Large amount of effort has been spend on the development of collaboration and cooperation mechanisms in multi-agent systems. Our intention is to develop a set of domain-independent mechanisms for collaboration and cooperation, so that they can be reused in different applications. This need is also recognized by other researchers . In ROPE project , cooperation process is build as separated component from the concrete agents, the ROPE engine provides the execution of the cooperation process, which is described as a high-level petri-net class. However, the implementation of ROPE Engine is based on a shared memory, which is not always feasible for agents widely distributed on different machines.
Additionally, the cooperation process in ROPE project is based on token and transition firing, which is not feasible to support more proactive cooperation and collaboration, i. Agents collaborate and cooperate with each other using this set of mechanisms and also according to the protocols defined in the role, which specify how the interaction between different roles should be proceeded. The automatic agent generation process is based on a component-based agent architecture. The user can select which components to be included in this agent, and the user can also specify a set of attributes of the agent.
Figure 7 shows a general agent architecture.
Each agent has a set of attributes. Its motivation is a set of MQ s it accumulates and tracks, which are mapped into its overall utility through specific utility functions. An agent also receives sensor data from outside environment including events and messages. The designer of the agent decides what reasoning tools should be built in for this agent, the designer also selects the appropriate execution tools for this agent according to the designed purpose of this agent.
It is assumed there are a set of reasoning and execution mechanisms available as toolkit, which can be selected and plugged into the agent seamlessly. Based on this general agent architecture, we developed a tool to support the automatic agent generation process. This tool includes a graphic user interface, which can be used to create new agents, modify existing agents, run agents and delete agents. A screen shot of the graphicial user interface is shown in Figure 8. Agent class is defined by a set of attributes, motivations, utility function, and a set of reasoning mechanisms and execution mechanisms.
Individual users can create their own agent classes through this interface. The user can define a variety of attributes including name, qualification, and other parameters for recording information during the agent execution process such as log file name and log level. Qualification is an attribute that describes a particular capability this agent class owns, which is used in the role-agent mapping process to decide whether an agent is qualified for a particular role.
Currently all available components are created in JAF project, new components can be created and added to this selection list at any time in the future. After an agent class is defined, one or multiple agent instances the executable programs can be created from this class definition. Each agent instance is an independent program and the agent is named after its class with a unique number ID.
For example, when the user creates an agent class X and three agent instances of this class, the three agents are named as X 1 , X 2 and X 3 respectively. The user can run agents from this interface by clicking the "RUN AGENT" menu box on the top, and selecting a number of agents to run from a list of agents that have already been created.
Multiple agents can be created and run on difference machines. We have implemented a prototype system including a role-definition component and an agent definition and creation component. Using this system, we implement a simple health care application as an example to demonstrate this integrated role-based approach for modeling, designing and implementing multi-agent systems, including the definition of role and agent classes, automatic agent generation process and the dynamic mapping process between agents and role instances.
The purpose of this health care application system is to assist health care providers and patients to schedule and coordinate their activities so as to provide feasible and efficient health care services for patients. One advantage of this role-based multi-agent system approach is the support of the separation of concerns principle. We believe that a complicated information system should be developed collectively by both the domain experts and the software experts. For example, in this health care application domain, there are a lot of domain knowledge that is not familiar to the software engineers.
Health care domain experts are the best candidates to engineer such knowledge in the system. Hence we developed a role-definition tool with graphical user interface for the domain experts to represent those domain knowledge through role definition. In this demo example, we pretend ourselves to be domain experts by reading some books  and articles in medical application domain.
We created a simplified system just to verify the feasibility of this approach. In this process, we recognized the difficulty and inefficiency for a software engineer to grasp the vast amount of domain knowledge in a short period of time, which enhance our belief of the separation of concerns principle. In this simplified system, we define the following role classes:.
Physician : who determines whether diagnostics are to be undertaken, provides prescriptions, performs medical and surgical interventions, has the ability to direct patient care and advance a patient to the next step of care. Medical Assistant : a health care professional who performs a variety of clinical, clerical and administrative duties within a health care setting. There are two roles defined as subclasses of this role class:. Nurse : there are two roles defined as subclasses of this role class:. Nurse Practitioner : a registered nurse who has completed an advanced training program in primary health care delivery, and may provide primary care for non-emergency patients, usually in an outpatient setting.
Figure 9 shows the RADE interface for user to create role classes and define the interrelationships among role classes. In this example, the interrelationships include inheritance, association and incompatibility.
Each agent instance is a software entity that performs specific functions and also coordinates and communicates with other agent instances. This base varies an kind to data and connections in Machine Learning. Conclusion; Appendix A. Why already resolve at our decision? He has published several papers on agent-based manufacturing control and has brought into operation the probably first full-scale industrial agent-based manufacturing control system. Marine Mammal Protection Act.
Association is a very common relationship between role classes, it indicates an instance of one role class may perform an action on an instance of another role class. Association relationships exist between Physician and Nurse, Physician and Patient , etc. Incompatibility relationship describes the constraints that the role instances of the two role classes cannot be taken by the same agent for the same interaction scenario. For example, an agent cannot take a Physician role instance for treating a Patient role instance if the agent is taking this Patient role instance right now, however the agent can take another Physician role instance for treating another Patient role instance that is not taken by this agent.
The definition of such relationships depends on the domain knowledge, so we feel the domain experts are the best candidates to use this interface to define the role classes and their interrelationships.
Each role is defined with a goal, a plan tree, a motivational quantity production set MQPS , a certificate and other attributes. A goal is a task that this role needs to accomplish, and the plan tree specifies the domain knowledge of how to accomplish this goal in terms of decomposing it as sub-goals. For example, Physician role is defined with a goal to Provide Cure. The plan tree shown in Figure 6 provides.
Detail explanation of the plan tree is in Section 4. The MQPS specifies the type and the number of units of motivational quantities that can be collected by the agent after it accomplishes the goal defined in the role. The Certificate defined in the role describes the qualification requirement for this role. This role can only be taken by an agent who has this specified certificate. Agents are the real programming entities running in the system. In this example, each agent represents a personal assistant for a human user in the real world. The agent is also responsible for coordinating with other agents when coordination is needed between its own user and other users.
As Figure 8 shows, a user creates an assistant agent named Adam. The user specifies his preference on choosing tasks by defining the motivation 2 of this agent as:. This specifies three long-term goals this user has: professional achievement, moral achievement and experience achievement, as a physician, which are represented by three types of MQs shown in Table 1.
Since the function can be a non-linear function and is also context sensitive, the initial amount of this type MQ is also important. The user also provides this agent with his qualification MD so that this agent can be qualified for a Physician role. Next we present a runtime scenario to describe how the system works including how the dynamic task allocation is accomplished through the role-agent mapping mechanism. This system is modeling a hospital organization. A special role space agent is created. This agent is not taking any active role in the system, rather, it is mainly responsible for maintaining and managing the role instances in the system, as we described in Section 5.
Due to the limited implementation effort and time available, we make the following simplifications in this implementation, compared to the process described in Section 5. The role space checks the plan tree of a role instance when this role instance is taken by an agent and recognizes the needs to create new role instances, rather than the agent sends a request to the role space to create new role instances. This simplification is valid when the goals and plan trees are simple and there is no need for the agent to choose from different plans.
The role space selects the appropriate agent for the role instance after verifying the qualification and consistency of the candidates, rather than sends a short list to the creator of this role instance and let the agent who creates this role instance to make selection according to the criteria defined by its user. This simplification is valid when there is only a few candidates. When the system is initialized, the system administrator creates several Patient role instances to express the expected service requirements from patients.
The number of Patient role instances depends on the capability of this hospital. These patient role instances are posted on the role space and are not active until they are taken by agents. When a real patient Bryan enters in this hospital for service, a personal assistant agent named Bryan is created for this patient, and this agent takes one Patient role instance. When agent Bryan takes the Patient role instance, it has one goal to achieve: Get Cure. The plan tree of this goal describes that two subgoals Assist Patient and Provide Cure must be achieved so that the goal Get Cure can succeed.
Three other agents, Adam, Cathy and David that represent three medical professionals have already been created and are active in the system. They have been idle and sent requests to the role space for available role instances. After receiving this message, the agent looks at the goal associated with this role instance, especially the MQPS and to see if it matches its own motivation.
If the MQPS contains the same type of MQ the agent has in its motivation, the agent is interested in taking this role instance. So Adam is interested in this role instance. How interested Adam is for this role instances depends on the actual values of p1, p2 and p3, the exact structures of the mapping functions with index 0, 1, and 2, and the current accumulation of these MQs for agent Adam. Email Address.
Sign In. Access provided by: anon Sign Out. Designing cooperating multi-agent systems — An extended design methodology Abstract: Within production systems various control decisions have to be taken to ensure a proper system behavior in a distributed but consistent way. Multi-agent systems can be considered as an efficient implementation mean for distributed control architectures. However, an agent-based control system cannot be implemented in a single moment, following a one-shot approach, within a complex production system. To overcome this problem this paper is presenting a step wise engineering approach for agent-based control systems to design multi-agent systems solving special control problems and combining them in an appropriate way to a larger agent-based control system.