Proceedings Template - WORD s17

Technical Report: Engineering Multiagent Organizations Last printed 1/12/2004 09:45:00 AM, Page 1 of 32 Engineering Multiagent Organizations Scott DeLoach Eric Matson Multiagent and Cooperative Robotics Laboratory Department of Computing and Information Sciences, Kansas State University 234 Nichols Hall, Manhattan, Kansas 66506, USA (785) 532-6350 {sdeloach, matson}@cis.ksu.eduABSTRACT In this paper, we introduce a knowledge-based approach to building multiagent organizations. In this approach, we explicitly model the concepts required for an organization including goals, roles, agents, capabilities, and the assignment of agents to roles. We also define the concepts necessary to allow the teams to autonomously reorganize to achieve their goals. We then examine the Multiagent Systems Engineering (MaSE) methodology to determine which concepts of an organization are currently captured. We then extend the MaSE models to capture the missing information.Keywords: Organization, Capability, Multiagent Systems.INTRODUCTION Recent trends in multiagent systems are toward the explicit design and use of social structures to organize agents. These multiagent structures, termed organizations, allow heterogeneous agents to work together within well defined roles to achieve individual and system level goals. When focusing on team goals, organizations allow agents to work together by using individual agents to perform the tasks for which they are best suited. When emphasizing an individual agent’s goals, organizations provide the structure and rules that allow agents to find and carry out collaborative tasks with other, previously unknown agents, to the mutual benefit of each agent.In multiagent teams, the use of roles and goals allows the agents to perform their duties in an efficient and effective manner that allows the team to optimize its overall performance. This requires some knowledge on the part of the agents of their role on the team and their relationship to other agents. In situations where the nature of the application environment makes teams susceptible to individual failures, these failures can significantly reduce the ability of the team to accomplish its goal. Unfortunately, most multiagent teams are designed to work within a limited set of configurations. Even when the team possesses the sensors, effectors, and computational ability to accomplish its goal, it may be constrained by its own structure and knowledge of team member’s capabilities, which may change over time. In most multiagent design methodologies, the system designer analyzes the possible organizational structure – which determines which roles are required to accomplish which goals and sub-goals – and then designs one organization that will suffice for most anticipated scenarios. Unfortunately, in dynamic applications where the environment as well as the agents may change, a designer can rarely account for, or even consider, all possible situations. Attempts to overcome these problems include large-scale redundancy using homogenous capabilities and centralized/distributedPage 1 of 32 Technical Report: Engineering Multiagent Organizations Last printed 1/12/2004 09:45:00 AM, Page 2 of 32 planning. Unfortunately, these homogenous approaches are not applicable in many complex applications where heterogeneous capabilities are required to reduce individual agent costs or size. To overcome these problems, we propose to let the team design its own organization at runtime. In essence, we propose to provide the team with the organizational knowledge and let the team define its own organization based on the current goals and team capabilities. While the designer may provide some guidance, providing the team with the information necessary to redesign, or reorganize, itself is a more robust and adaptive approach. In essence, we believe that the appropriate knowledge of a team’s organizational structure and capabilities, when coupled with efficient reasoning techniques, will allow multiagent teams to reorganize “on-the- fly” thus enabling them to achieve their overall team goals more efficiently and effectively in the face of a changing environment and team capabilities.The remainder of this paper is organized as follows. Section 1 presents a review of relevant background research. We then discuss our approach to modeling multiagent organizations in Section 2 and our approach for analyzing and designing general purpose multiagent systems in Section 3. In Section 4, we discuss the shortcomings in our current approach to designing multiagent systems and proposed extensions to support the analysis, design, and synthesis of multiagent organizations.1. BACKGROUND 1.1 Computational Organization Theory Computational organization theory uses mathematical and computational techniques to study both human and artificial organizations 4. While most people have an intuitive idea of what an organization is, when asked to define it explicitly, there are large numbers of “correct” answers. From early organizational research, organizations are have typically been defined as including the concepts of set of agents who play roles within a structure that defines the relationships between the various roles 1. Instead of defining the term organization specifically, Carley and Gasser have come up with a general characterization of organizations 5, which describes them as (1) large scale problem solving technologies, (2) consisting of multiple agents, (3) engaged in multiple tasks, (4) goal directed, (5) able to affect and be affected by their environment, (6) have knowledge, culture, history, and capabilities distinct from any single agent, and (7) have a legal standing distinct from that of individual agents.Additionally, Ferber 15 defines six functions of organizations as representational, organizational, conative, interaction, productive, and preservative. The representational function of an organization includes the ability of the organization to model its environment as well as other agents and captures the history, culture and capabilities of the organization. The organizational function relates to the ability of the organization to plan, allocate, monitor, and coordinate tasks. The conative function refers to the decision-making abilities of the organization. The interaction function allows the organization to interact with, and affect its environment. ThePage 2 of 32 Technical Report: Engineering Multiagent Organizations Last printed 1/12/2004 09:45:00 AM, Page 3 of 32 productive function is the primary, application specific, problem-solving part of the organization. Finally, the preservative function performs the preservation and reproduction of organization structure and its resources.While concepts similar to organizations are not exclusive to computational organization theory, results from the field are illuminating. Specifically, they suggest that organizations tend to adapt to increase performance or efficiency, that “the most successful organizations tend to be highly flexible” 4, and that the best organizational designs are highly application and situation dependent 26. It also provides findings about the conditions under which certain organizations work best. For instance, as the number of hierarchical levels in an organization increases, efficiency and effectiveness tends to decrease while decentralized organizations tend to have higher performance. However, hierarchical organizations tend to exhibit higher reliability 3. These insights seem to suggest that allowing teams to determine their organization at runtime, as we proposed, could have positive effects on team performance.1.2 Teamwork While research in both business and management has looked at teamwork, we limit our review to teamwork theories from multiagent systems that are both formal and directly applicable to multiagent systems and cooperative robotics. These theories include Joint Intentions by Cohen and Levesque (with extensions by Jennings), Shared Plans by Grosz, and Planned Team Activity by Kinney et. al. We will briefly review these along with an implementation by Tambe called STEAM, which combines Joint Intentions and Shared Plans.Joint Intentions. Cohen and Levesque developed the Joint Intentions theory of teamwork based on human teamwork using a model of individual mental states to formalize their model 3, 8, 28. The central focus is that being a member of a team involves a responsibility to the team. Specifically, they define the concepts of joint persistent goals and joint intentions. A joint persistent goal, g, is defined in relation to a team that mutually believe that g is false and that they all want g to become true. Additionally, each team member will continue pursuing g until either g is true, g can never be true, or the reason for pursuing g becomes false. Moreover, team members will not drop g independently of their team members; if an agent decides to drop g as a goal, it must ensure that each of its team members also agrees to drop g. A team has a joint intention only if they have a joint persistent goal and that they mutually believe that they will in fact perform the action necessary to achieve the goal. Furthermore, a joint intention leads to individual goals and individual intentions. Cohen and Levesque go on to show that if a team jointly intends to do an action, then this places requirements on the individual team members such that team members privately intend to do their share relative to the joint intention.Jennings 23, 22, 23 extended the notions of Joint Intentions by defining the two separate, yet complimentary, notions of commitment and convention. Commitments are promises to take specific action or to ensure a particular state of affairs and are persistent. Once a team member commits to performing a particular action or pursuing a state, the team member may not drop that commitment without just cause. Acceptable causesPage 3 of 32 Technical Report: Engineering Multiagent Organizations Last printed 1/12/2004 09:45:00 AM, Page 4 of 32 are defined by conventions. Conventions are a means of monitoring commitments and define the circumstances under which they may be re-evaluated as well as measures to be taken in these situations. Shared Plans. Grosz and Sidner 17 originally defined Shared Plans as a model of collaboration planning. Grosz and Kraus 18 extended Shared Plans to include the notion of joint commitments and to allow agents to make commitments before having a complete plan. Shared Plans is an extension of Pollack’s mental state view of plans 35, which states that agents have plans when they have specific beliefs and intentions. Specifically, Grosz points out those joint plans cannot simply be the sum of individual plans but must be planned jointly. Shared Plans requires team members to establish a commitment towards the success of other team member’s action and thus act as a constraint on future planning. Finally, Shared Plans includes the concept of commitment even without a completely specified plan. Two team members with a shared plan have a common mental state. Each member must believe that (1) there is a unique recipe for performing a joint action, (2) each team member is capable of performing their required actions, (3) each team member will actually attempt their actions at the proper time, and (4) each member will perform their actions to contribute positively toward the joint action.Grosz formulation is unique from Cohen and Levesque’s in that it does not include the notion of a joint intention. Grosz defines a shared plan in terms of a common recipe and individual intentions that the joint action be done and the team members do their part in ensuring their particular sub-actions are done. There is also no allowance for an agent to no longer believe that the shared plan is valid or necessary and thus no mention of what to do in that situation (in contrast to Cohen and Levesque who require the team members to inform the team of its beliefs).Planned Team Activity. Kinney et. al. 25, 41 focused its teamwork theory toward team formation. Kinney assumes that all plans are predefined, the skills of each agent are known, and that team formation is proposed by a single team leader. In Planned Team Activity, the joint attitudes of the team are expressed in terms of the joint attitudes of team members, which eventually break down into the individual team member attitudes. When an agent wishes to form a team, it becomes the team leader and solicits other agents to join. This solicitation includes the joint goal, the joint plan to be used in achieving the goal, and the roles to be assumed by the agents. Individual agents can become team members only when they believe the joint goal is currently false, the preconditions of the joint plan are true, the team is capable of carrying out the plan, and that the goal is compatible with their current goals. Planned Team Activity also addresses operational aspects of team formation, proposing two methods: commit-and-cancel and agree-and-execute. In commit-and-cancel, the team leader asks for a commitment from agents to play specific roles. If they all agree, the team is formed and execution begins at once; if not, a “cancel” message is sent. In agree-and-execute, the team leader sends a request that potential team members agree to playPage 4 of 32 Technical Report: Engineering Multiagent Organizations Last printed 1/12/2004 09:45:00 AM, Page 5 of 32 a specific role using a specific plan. If all agents agree, then the team leader sends a specific execute message. If no message is sent, the team members do not begin execution.Planned Team Activity also addresses team member failures, requiring the team member to inform the team of its failure and be responsible for forming a resolution to the problem. However, unlike Cohen and Levesque, who require specific conditions for dropping a joint intention, under Planned Team Activity a team member may abandon a joint commitment simply by announcing that fact to the rest of the team, which does not necessarily affect the beliefs and commitments of the rest of the team.STEAM. STEAM 44 is an implementation of teamwork that is derived from concepts from Joint Intentions as well as Shared Plans. The basic goal of STEAM is to provide team members with a general model of teamwork in order to allow teams to act coherently in a dynamic, uncertain environment where teammates have different views of the environment and can fail unexpectedly. In STEAM, team members have explicit representations of mutual (team) beliefs, plans, and goals, as well as its own individual beliefs, plans, and goals. Reasoning is based on Joint Intentions theory, which allows the agent to reason about coordination and communication and for guiding team monitoring and maintenance activities. The key to STEAM is the concept of team operators, which explicitly represent team operations that require joint intentions. STEAM also implements the notion of failure monitoring and re-planning. STEAM allows the specification of relationships between team operators and roles that contribute to it. Thus, when a team operator is not achieved, the responsible role can be inferred via domain dependent specifications. If the cause for a team operator failure was a critical role failure, the entire team is reconfigured by substituting an existing team member into the failed role.1.3 Social Laws Moses and Tennenholtz 32 introduced the concept of social laws as a way to guarantee the cooperative existence of multiple agents in the same space without resorting to pre-determining all possible interactions. They define social laws as a set of constraints on the actions that an agent is allowed to perform in a state 33. They liken social laws to typical traffic laws that state what should happen when interactions occur. They discuss the tradeoff between very restrictive social laws, which may provide some guarantee of success for specific problems versus more liberal laws that, while not guaranteeing success, allow more autonomous behavior and thus provide a wider range of possible states and better performance 40. Specifically, they claim that social laws can (1) enable an agent to design a plan guaranteed to achieve a specific goal, and (2) simplify the environment in which a plan must work, thus simplifying the plan derivation process. Extensions to the original work 40, 38 looked at the problems of automated, off-line synthesis of these social laws. While they conclude that synthesis of social laws that provide agents guaranteed success is NP-complete, they claim that its NP-completeness makes the verification of the social law design efficient 33. Page 5 of 32 Technical Report: Engineering Multiagent Organizations Last printed 1/12/2004 09:45:00 AM, Page 6 of 32 1.4 Agent Oriented Software Engineering Recently, two conceptual advances in agent-oriented software engineering have had a significant impact on approaches multiagent approaches. The first of these was identification of interaction and coordination as the central focus of multiagent systems design. That is, interaction and coordination play a central role in the analysis and design of multiagent systems and makes the multiagent approach significantly different from other approaches towards building distributed or intelligent systems. This realization lead to several new methodologies for building multiagent systems that focused on the interaction between agents as the critical design aspect. Several agent-oriented methodologies fit this form including MaSE 12, 10, 11, Gaia 47, and MESSAGE 31. The second advancement is the separation of the agents populating a system from the system organization 48, 49. While agents play roles within the organization, they do not constitute the organization. The organization itself is part of the agent’s environment and defines the social setting in which the agent must exist. An organization includes organizational structures as well as organizational rules, which define the requirements for system creation and operation. These rules include constraints on agent behavior and their interactions. There are separate responsibilities for agents and organizations; the organization, not the agents, should be responsible for setting and enforcing the organization rules. Organizational design has many advantages over traditional multiagent systems design methods. First, it defines a clean separation between the agent and the organization in which the agent works, which in turn simplifies each design. In traditional agent-oriented approaches, the rules that govern interaction must be incorporated into the agents themselves, thus intertwining the organizational design in various agent designs. Secondly, separating the organization from the agent allows the developer to build a separate organizational structure that can enforce the organizational rules. This is especially critical in open systems where we do not know the intent of the agents working within the system.While these advances are rather recent, there have been some discussions on how to incorporate them into existing multiagent systems methodologies. For instance, there is a proposal to modify the Gaia multiagent systems methodology to incorporate the notion of social laws 50. Other approaches view the organization as a separate institutional agent 46. However, these proposals are high-level and do not provide guidance on how to use existing abstractions with organizational concepts. In addition, powerful new coordination models, such as hybrid coordination media, have given us new ways to implement organization rules; we can embed organizational rules in the coordination media instead of implementing them internally within individual agents 2.1.5 Other Work in Reorganization Organizational self-design (OSD) 19 by Ishida and Gasser provides strategies for adaptive work allocation and balancing. OSD dynamically varies the number of agents in the organization, but not the actualPage 6 of 32 Technical Report: Engineering Multiagent Organizations Last printed 1/12/2004 09:45:00 AM, Page 7 of 32 organizational structure. OSD uses two main concepts: organizational knowledge, which defines the relationships between agents and their organization, and reorganization primitives. There are two basic reorganization primitives: decomposition, which creates two agents from a single agent, and composition, which combines two agents.In cooperative robotics related research, Parker’s ALLIANCE architecture includes a behavior-based approach to reorganization 34. Task selection is controlled by motivations, which include impatience and acquiescence. Impatience increases based on the failure of other agents to perform a task. Once an agent’s impatience reaches a high enough level, the agent will start working on the task itself. Acquiescence is an agent’s impatience with its own inability to perform a particular task. Eventually, after an agent has attempted worked unsuccessfully on a task for some period, it will acquiesce and give up the task. Use of impatience and acquiescence allows agents to change their organization without explicitly reasoning about teamwork.The work most closely related to our research is the CoDA project at the University of Maine 45. The CoDA project deals with a team of autonomous underwater vehicles that must self-organize and reorganize to complete its long term missions of oceanographic sampling. The CoDA project uses a two level strategy. First, a meta-level organization (containing only those AUV with sufficient intelligence to participate at this level) is formed. The meta-level organization designs a task-level organization to carry out the mission. When a failure occurs, the meta-level organization is reformed and a new task-level organization is designed. The current capabilities are limited to hierarchical organizations and typically require a total reorganization when failures occur.Chaimowicz et. al. 6 have defined a cooperative robotic architecture for tightly coupled cooperative applications, which is defined as tasks that require real-time coordinated control between agents. This work is limited to role reassignment, which only applies to changing the team leader. Role reassignment allows the agent teams to adapt to unexpected events such as obstacles, sensor failures, etc. 2. ORGANIZATION MODEL To implement teams of autonomous, heterogeneous agents, we created an organizational model, which defines and constrains the required elements of a stable, adaptable and versatile team. While most people have an intuitive idea of what an organization is, there are no standard definitions. However, in most organizational research, organizations have typically been understood as including agents playing roles within a structure in order to satisfy a given set of goals. Our proposed organizational model (O) is contains a structural model, a state model and a transition function.O = <Ostructure, Ostate, Otrans>Page 7 of 32 Technical Report: Engineering Multiagent Organizations Last printed 1/12/2004 09:45:00 AM, Page 8 of 32 Figure 1 shows the combined structural and state models using standard UML notation. The structural model includes a set of goals (G) that the team is attempting to achieve, a set of roles (R) that must be played to attain those goals, a set of capabilities (C) required to play those roles, and a set of rules or laws (L) that constrain the organization. The model also contains static relations between roles and goals (achieves), roles and capabilities (requires), and individual roles (related).Organization ocf() subgoal related coordGoal Role Agent conjunctive : Boolean rcf(Agent) Capable precedes Achieves - roleScore goalSatScorePossesses - capabilityScore requires Capabilities assignedAssignment constrains Law - scoreFigure 1. Organizational ModelFormally, we model the organization structure as a tuple.Ostructure = <G, R, L, C, achieves, related, requires, subgoal, precedes> where achieves: R, G  0 .. 1 related: R, R Boolean requires: R, C  Boolean subgoal: G, G Boolean precedes: G, G Boolean The team goals include the goal definitions, goal-subgoal decomposition, and the relationship between the goals and their subgoals, which are either conjunctive or disjunctive. The subgoal predicate defines whether aPage 8 of 32 Technical Report: Engineering Multiagent Organizations Last printed 1/12/2004 09:45:00 AM, Page 9 of 32 goal, g1, is the parent goal of the second goal, g2. In general, a subgoal relationship is 1 to many (0 or more). We can define the children of a goal as children(g) = {g1 : G | subgoal(g,g1)}The children of a goal may either be conjunctive or disjunctive, and is denoted by the conjunctive predicate attached to each goal. If a goal is a conjunctive goal (g.conjunctive = true), then that goal may only be satisfied if each goal in children(g) are satisfied. Conversely, if a goal is disjunctive (g.conjunctive = false), then that goal is satisfied when any goal in children(g) is satisfied. If a goal does not have any subgoals (children(g) = {}), then the goal is a leaf node and is neither conjunctive or disjunctive. There is also a time-based relationship that exists between goals. We say goal, g1, precedes goal, g2, if g1 must be satisfied before any part of g2 can be satisfied. This allows the organization to work on one part of the goal tree at a time. If g1 precedes g2 (precedes(g1,g2) = true), then the organization can put its full effort into satisfying g1 without worrying about g2 until it has achieved g1.Roles define parts or positions that an agent may play in the team organization. In general, roles may be played by zero, one, or many agents simultaneously while agents may also play many roles at the same time. Each role requires a set of capabilities, which are inherent to particular agents and may include sensor capabilities (sonar, laser, or video, etc.), actuator capabilities (movement type, grippers, etc.), or computational capabilities (processing power, algorithms, communications, etc.). Agents are unique in the area of capabilities versus software agents; agent’s physical capabilities may improve or degrade over time, which can often cause the team to reorganize. Organizational rules are used to constrain the assignment of agents to roles and goals within the organization. Generic rules such as “an agent may only play one role at a time” or “agents may only work on a single goal at a time” are common. However, rules are often application specific, such as requiring particular agents to play specific roles. The structural model relations define mappings between the structural model components described above. A role that can be used to satisfy a particular goal is said to achieve that goal, while a role requires specific capabilities and may work directly with other roles, thus being related to those roles. Achieves is modeled as a function to capture the relative ability of a particular role to satisfy a given goal.The organizational state model defines an instance of a team’s organization and includes a set of agents (A) and the actual relationships between the agents and the various structural model components. Ostate= <A, possesses, capable, assigned, coord> where possesses: A, C  0 .. 1 capable: A, R  0 .. 1 assigned: A, R, G  0 .. 1 coord: A, A  BooleanPage 9 of 32 Technical Report: Engineering Multiagent Organizations Last printed 1/12/2004 09:45:00 AM, Page 10 of 32 An agent that possesses the required capabilities for a particular role is said to be capable of playing that role. Since not all agents are created equally, possesses is modeled as a real valued function, where 0 would represent absolutely no capability to play a role while a 1 indicates an excellent capability. In addition, since agent capabilities may degrade over time, this value may actually change during team operation. The capable function defines the ability of an agent to play a particular role and is computed based on the capabilities required to play that role (see Section III). During the organization process, a specific agent is selected to play a particular role in order to satisfy a specific goal. This relationship is captured by the assigned function, which includes a real valued score that captures how well an agent, playing a specific role, can satisfy a given goal. When an agent is actually working directly with another agent, it is coordinating (coord) with that agent. Thus, the state model defines the current state of the team organization within the structure provided by the structural model. The organization transition function defines how the organization may transition from one organizational state to another over the lifetime of the organization, Ostate(n) → Ostate(n+1). Since the team members (agents) as well as their individual capabilities may change over time, this function cannot be predefined, but must be computed based on the current state, the goals that are still being pursued, and the organizational rules. In our present research with purely autonomous teams, we have only considered reorganization that involves the state of the organization. However, we have defined two distinct types or reorganization: state reorganization, which only allows the modification of the organization state, and structure reorganization, which allows modification of the organization structure (and may require state reorganization to keep the organization consistent). To define state reorganization, we simply need to impose the restriction thatOtrans(O).Ostructure = O.Ostructure (1)Technically, this restriction only allows changes to the set of agents, A, the coord relation, and the possesses, capable, and assigned functions. However, not all these components are actually under the control of the organization. For our purposes, we assume that agents may enter or leave organizations or relationships, but that these actions are triggers that cause reorganizations and are not the result of reorganizations. Likewise, possesses (and thus capable as well) is an automatic calculation on the part of an agent that determines the roles that it can play in the organization. This calculation is totally under control of the agent (i.e. the agent may lie) and the organization can only use this information in deciding its organizational structure. Changes in an agent’s capabilities may also trigger reorganization. That leaves the two elements that can be modified via state reorganization: assigned and coord. Thus, we define state reorganization as:Otrans(state) : O  O (2) whereOtrans(state)(O). Ostruct = O.Ostruct  Otrans(state)(O). Ostate.A = Ostate.APage 10 of 32 Technical Report: Engineering Multiagent Organizations Last printed 1/12/2004 09:45:00 AM, Page 11 of 32 Otrans(state)(O).Ostate.possesses = Ostate.possesses  Otrans(state)(O).Ostate.capable = Ostate.capable (3)2.1 Model Validity and Consistency This section describes the concepts of valid and viable organizations. In general, a valid organization is one in which the structure can be reasonably expected to provide an acceptable organizations in a given scenario. A viable organization, on the other hand, is one in which the assignments of agents to roles satisfy all organizational laws and can allow the team to reach its overall team goals.2.1.1 Validity As described above, to be valid, an organization must have a structure that would allow it to form an organization, given the right collections of goals, roles, and agents. Thus, these constraints are further restrictions on the model presented above. First, we deal with the capabilities required by roles and agents. Since the objective of the model is to define teams of agents that can work together, it only makes sense that agents have some capability, even if it is purely computational or communicative. Likewise, each role must have some basic requirements as well. Therefore, we require that all roles require at least one capability and that all agents possess at least one capability, the later being denoted by a capability score greater than zero (# is the cardinality of the set). r : R #{c | requires(r,c)} ≥ 1 (C1) a : A #{c | possesses(a,c) > 0} ≥ 1 (C2)The next set of constraints deal with capabilities of agents and roles as they relate to assignments. To be capable of playing a given role in the current organization, an agent must possess all the capabilities that are required of that role. It also follows that an agent must be capable of playing a specific role before it can be assigned to play that role. a : A, r : R capable(a,r) > 0  {c | requires(r,c)}  {c | possesses(a,c)} (C3)a : A, r : R, g : G (assigned(a, r, g) > 0)  capable(a,r) > 0 (C4)In order to allow the preceding constraints to be true, it is necessary that the set of capabilities in an organization (C) include all the capabilities required by all roles within the current organization. r : R | {c | requires(r,c)}  C (C5)The next constraint concerns the relationship between the related relationship between roles and the coord relationship between agents. Because roles define the part the agents will be playing in the organization and the related relationship defines valid relationships between those roles, agents should only have coordination relationships (coord) if they are playing the appropriate roles. Page 11 of 32 Technical Report: Engineering Multiagent Organizations Last printed 1/12/2004 09:45:00 AM, Page 12 of 32  a1, a2 : A coord(a1, a2)  ( r1, r2 : R, g1, g2 : G ((assigned(a1,r1,g1) > 0)  (assigned(a2,r2,g2) > 0)  related(r1, r2))) (C6)The final validity constraints are straightforward structural constraints that require the related and coord relations to be symmetric. That is, if one role is related to another role, then the second role must also be related to the first role. r, r1: R related(r, r1)  related(r1, r) (C7) a, a1: A coord(a, a1)  coord(a1, a) (C8)2.1.2 Viability Even though an organization may be valid (using the constraints above), it does not mean that there will actually be an instance of the organization that can actually satisfy the goals of the organization. In order to satisfy the organizational goals, the team must have the right mix of roles to satisfy the goals and agents to play the required roles. The viability constraints presented below are only the base viability constraints. Often, viability constraints are application specific and are embedded in the organization in the form of organizational rules.The first viability rule ensures that there is some real organization that actually exists to solve some goal. Thus we require that there must be at lest one element each of the goals, roles, and agents to have a viable organization. However, since this requirement follows for roles and agents given constraint C10 below (which requires at least one role and agent per goal), we can simply require the organization to have at least one goal.# G ≥ 1 (C9)We have also defined the notion of organizational viability. One would expect a viable organization to be one that can satisfy its overall goal. Therefore, we define a viable organization (C10) as an organization that is able to ensure that all goals (and their subgoals) can be achieved by some role that can be played by some agent in the organization. g:G  r:R, a:A achieves(r, g) {capable(a, r)≥ 1} (C10)This definition of viability is actually too strong. If the overall team goal to be satisfied is s a disjunctive goal g, it can be achieved by any one of its subgoals g1, g2, … gn. Such an organization could still satisfy its overall goal, g, without meeting the requirements for viability as defined above. Thus we define the term weakly viable, which allows organization that can only achieve a subset of their overall goals, yet this subset is sufficient to satisfy the overall team goals. However, our formalization of goals is not sufficient to support this definition.Page 12 of 32 Technical Report: Engineering Multiagent Organizations Last printed 1/12/2004 09:45:00 AM, Page 13 of 32 2.2 Capability So far, we have used the term capability generically. However, we must define it more precisely before moving on. A capability’s existence is based on the collective sense in which it is viewed. To specify this we further define capabilities in relation to agent and roles that exist within a self-reorganizing multiagent team. As described above, an agent possesses specific capabilities while roles require particular capabilities, each with specific scores.The capability set of an agent, Ca, varies from the empty set, if the agent possesses no capability, to a complete set of the capabilities that the agent intrinsically possesses. Normally even a simple agent has multiple capabilities. Ca (a)  {c | possesses(a,c)  0} (4)Likewise, the capability set of a role, Cr, is the set of capabilities required to play that specific role. All non-trivial roles must have at least one capability in order to accomplish some task or goal. Cr (r) {c | requires(r,c)} (5)The capability of an agent, a, to play a specific role, r, is basically the average of the agent’s scores for each capabilities required to play that role. If an agent does not possess a required capability (possesses(a,c) = 0), then the agent has no capacity to play that role. Thus, the capability score of an agent playing a particular role is defined as capable(a, r)  r.rcf (a) (6)The agents that form a team have a collective capability. Similarly, the set of roles required to achieve the overall organizational goal also have a set of required capabilities. We define these as team capabilities, CA, and required capabilities, CR. CA (O)  {c | a : A c Ca(a)} (7)CR (O)  {c | r : R  c Cr(r)} (8)To form a viable organization, these sets must be minimally overlapping such that the capabilities required are contained in the capabilities available from the agents such that CR(O)  CA(O).2.3 Reorganization Triggers In general, reorganization occurs when an agent team is incapable of reaching its overall goal, or when it could reach its goal in a more efficient or effective manner.Page 13 of 32 Technical Report: Engineering Multiagent Organizations Last printed 1/12/2004 09:45:00 AM, Page 14 of 32 2.3.1 Goal Failure Failure to achieve a sub-goal often prohibits the team from reaching its overall goal as well. We call this condition a goal failure. Theoretically, this is the situation from joint intentions theory when an agent no longer believes a joint persistent goal is achievable 3. However, instead of simply attempting to get its teammates to believe that the goal is no longer achievable, the agent must now assume the goal of making its teammates mutually believe it is not achievable under this organization. Only after attempting all applicable organizations can the team mutually believe the goal to be unachievable. Unfortunately, is has been shown that achieving consensus (in this case establishing mutual belief of a goal failure) for asynchronous systems is impossible in the presence of node and process failures 7. Therefore, we make certain assumptions concerning the upper bounds in communication and processor speed; we assume an agent is faulty if it does not respond within a designated period. Goal failure often occurs when a goal cannot be achieved due to a lack of agents playing necessary roles. We have currently identified three role-related goal failure scenarios:1. When a required role has not been assigned to an agent; 2. When a required role is relinquished by an agent due to it’s inability to carry it out; and 3. When an agent suffers a failure that keeps it from participating in the organization. The first type of goal failure is based on improper organization of the available agent team members. For instance, in search and rescue, all agents may be initially assigned to the searching role; however, when a victim is found, a rescuer is required. The obvious solution is to reorganize by reassigning a rescue capable agent to a rescuer role. The two remaining sources of goal failures are based on individual agent failures. The second type of goal failure occurs when an agent suffers a failure, but is still able to communicate with the team, possibly continuing to perform useful roles. For instance, if an agent loses use of its grippers for rescuing victims, it may still be capable of playing the searcher role. The third type is when an agent suffers a failure and cannot inform the team of its condition. Scenarios include an agent moving out of communication range or suffering a communication or total system failure. Not only can the agent no longer be part of the team, but it cannot communicate that fact to the team. The team must recognize that the agent is lost and take corrective action.Each type of goal failure requires different techniques to uncover. For instance, agents that require interaction with a particular role may discover improper organization when they are not able to find any team members playing the appropriate role. When a team member fails, it may simply inform the team of its change in capabilities so that each team member may update its internal organization model for that agent. However, when an agent can no longer communicate, the problem becomes difficult. In some situations, the agent may have moved out of communication range to perform some task with the expectation of returning to the group. However, if communication loss is not expected, the team must be able to (1) recognize that the loss has occurred,Page 14 of 32 Technical Report: Engineering Multiagent Organizations Last printed 1/12/2004 09:45:00 AM, Page 15 of 32 and (2) deal with the consequences. We plan to investigate both “time out” periods and intermittent polling for this case. 2.3.2 Efficiency/Effectiveness When a team reorganizes for efficiency, it is still accomplishing its goals; it is just not doing it as efficiently as possible. For instance, in a search and rescue operation, if the team has too many agents assigned to searching and not enough agents assigned to rescuing victims, requests for victim rescues could “stack up”. By reassigning capable agents to the rescuer role, the team could rescue victims more quickly and thus be more efficient. The process of reorganizing for effectiveness is similar to reorganizing for efficiency. While the organization may be efficient in it’s tasking of agents, its effectiveness could be improved. For example, if a team does not assign the best agents to play the required roles, its effectiveness could suffer. The organization model captures the information necessary for effectiveness computation via the agent capability score (cs). To trigger an efficiency/effectiveness-based reorganization requires monitoring of application specific conditions. We plan to capture these using non-functional goals; this way, we can handle efficiency and effectiveness analogously to functional goals. These goals would state how to measure the organization’s efficiency or effectiveness while the agents playing the responsible roles would be responsible for measuring performance and determining if reorganization is needed.2.4 Reorganization Once a triggering event occurs, the team must be capable of deciding whether reorganization is actually necessary. The decision to reorganize is based on whether the team can accomplish its goals with the required efficiency and effectiveness in the current organization. Using our organization model as a basis, we intend to investigate the following team decision process. 1. Determine what goals are not currently not being met (including non-functional goals) 2. Determine what roles may be used to accomplish those goals 3. Determine if all necessary roles have been assigned 4. Determine if agents are assigned useful roles by comparing role assignments to current goals If the answer to Step 3 or Step 4 is no, then reorganization is necessary for the system to achieve its goals.2.4.1 Optimal Reorganization Our research assumes the organization strives to operate at all times using the optimal configuration. To achieve the optimal organization, the assignment of agents to roles and goals, must be maximized. If the organization has a choice in which agents play which roles, it should generally choose the more capable. In terms of agents, the organization will opt to employ the most capable sensors given the current situation. Ideally, an organization will select the best set of assignments to maximize its ability to achieve its goals, which requires maximizing its organizational capability score, Os, given byPage 15 of 32 Technical Report: Engineering Multiagent Organizations Last printed 1/12/2004 09:45:00 AM, Page 16 of 32Os   assigned(a,r, g) (9) a,r,g where assigned(a,r,g) = 0 if that agent is not assigned to play a specific role to satisfy a goal.2.5 Example An illustrative example of the use of our organizational model is given in Figure 2. The boxes at the top of the diagram represent goals (A … G), the circles represent roles (R1 … R5), the pentagons represent capabilities (C1 … C5), and the rounded rectangles are agents (A1 … A4). AB CD E F G.5 .6 .8 .4 .6 .7 Achieves R1 R2 R3 R4 R5Requires C1 C2 C3 C4 C5.5 .6 .7 .5 .5 .6 .7 .5 .4 Possesses A1 A2 A3 A4Figure 2. Organization ExampleThe arrows between the entities represent the achieves, requires, and possesses functions/relations as defined above. The numbers beside the arrows represent the function value (e.g., possesses(A1,C1) = 0.5). Given this example, we can compute the capable function value for each agent – role pair as shown in Table 1.Table 1. Capable FunctionR1 R2 R3 R4 R5 A1 0.5 0 0.6 0 0 A2 0 0 0.7 0 0 A3 0 0 0 0.6 0.6 A4 0 0 0 0.5 0 Combining the capable scores with the achieves score, we can easily compute the organizational capability score, Os, for any set of assignments that might be made. If we make the common assumptions that we can only assign a single agent to work on each goal and that only one of the disjunctive goals F and G can be active at any one time, we can see that the optimal assignments, and thus the maximum organizational capability score is as follows:Page 16 of 32 Technical Report: Engineering Multiagent Organizations Last printed 1/12/2004 09:45:00 AM, Page 17 of 32 assigned(A1,R1,D) = 0.25 assigned(A2,R3,E) = 0.56 assigned(A3,R5,G) = 0.42 Os = 1.233. MASE The general flow of MaSE follows the seven steps shown in Figure 2. The rounded rectangles on the left side denote the models used in each step. The goal of MaSE is to guide a system developer from an initial system specification to a multiagent system implementation. This is accomplished by directing the developer through this set of inter-related system models. Although the majority of the MaSE models are graphical, the underlying semantics clearly and unambiguously defines specific relationships between the various model components. Require- mentsGoal Hierarchy Capturing GoalsUse Cases AApplying Use n a lCases y Sequence s i Diagrams sConcurrent Roles Tasks Refining RolesAgent Creating Agent Classes ClassesConver- Constructing D sations e Conversations s i g nAgent Assembling Architecture Agent ClassesDeployment Diagrams System DesignFigure 2. MaSE MethodologyMaSE was designed to be applied iteratively. Under normal circumstances, we would expect the developer to move through each step multiple times, moving back and forth between models to ensure each modelPage 17 of 32 Technical Report: Engineering Multiagent Organizations Last printed 1/12/2004 09:45:00 AM, Page 18 of 32 is complete and consistent. While this is common practice with most design methodologies, MaSE was specifically designed to support this process by formally capturing the relationships between the models. The two phases of MaSE, Analysis and Design, are discussed in more detail below. 3.1 Analysis The Analysis phase includes three steps: capturing goals, applying use cases, and refining roles. In the Design phase, we transform the analysis models into models useful for actually implementing the multiagent system. Each of these steps is described below.The first step in the MaSE methodology is Capturing Goals, which takes the initial system specification and transforms it into a structured set of system goals. There are two steps to Capturing Goals: identifying the goals and structuring goals. Goals are identified by defining the main purposes of the system. Once the system goals have been captured and explicitly stated, they are less likely to change than the detailed steps and activities involved in accomplishing them 24. After identification, the goals are analyzed and structured into a Goal Hierarchy Diagram, which is an acyclic directed graph where child nodes are subgoals of the parent goal. There is typically a single system goal, which is decomposed into a set of subgoals. These subgoals are assigned to roles, and eventually to agents. Thus agents, based on the role they are playing, become responsible for achieving specific system goals.The Applying Uses Cases step is crucial in translating goals into roles and associated tasks. Use cases are drawn from the system requirements and describe sequences of events that define desired system behavior. Use cases are examples of how the system should behave in a given case. To help determine the actual communications in a multiagent system, the use cases are converted into Sequence Diagrams. Sequence Diagrams depict sequences of events between multiple roles and, as a result, define the communications that must exist between the agents playing those roles in the final design. The roles identified here form the initial set of roles used in the next step. The events are also used later to help define tasks and conversations. The third step in the Analysis phase is to identify all roles, starting with the set defined in the previous step, and to define role behavior and communication patterns. A role is an abstract description of an entity's expected function and is similar to the notion of an actor in a play 24. Roles are identified from the Sequence Diagrams developed during the Applying Use Cases step as well as the system goals defined in Capturing Goals. MaSE ensures that all system goals are accounted for by associating each goal with a specific role, which is eventually played by at least one agent in the final design. Roles are captured via Role Models as shown in Figure 3. The boxes denote roles, which include a list of goals assigned to that specific role. Each role has at least one task, which is denoted by attached ovals. Communications between tasks are denoted by arrows pointing from the initiating task to the responding task. Page 18 of 32 Technical Report: Engineering Multiagent Organizations Last printed 1/12/2004 09:45:00 AM, Page 19 of 32 Once roles have been identified, concurrent tasks are created to define the expected role behavior. Concurrent tasks are captured via finite state models and specify a single thread of control that integrates inter- agent as well as intra-agent communications. Task execution is based on its type. If a task is persistent, it starts when the agent is created and runs until the agent dies or the task reaches and end state. Persistent tasks are identified by having null transitions from the start state another state in the concurrent task diagram. If a task is transient, the task is started in reaction to an incoming event. Transient tasks are recognized by having an incoming event on the transition from the start state. An example of a MaSE Concurrent Task Diagram is shown in Figure 4. Role A Role B Role C goal list goal list goal listTask 1 Task 2 Task 3 Task 4 Task 5 Protocol Protocol name nameFigure 3. Role Model[NOT known] receive(try(y), agent) state1 idle known = check(y) x = action(y) terminate receive(ack, agent) state2Figure 4. Concurrent Task DiagramRole behavior is captured by a set of n concurrently executing tasks (where n > 0). Activities are used to specify actual functions carried out by the agent and are performed inside the task states. While these tasks execute concurrently and carry out high-level behavior, they can be coordinated using internal events. Internal events are passed from one task to another and are specified on the transitions between states. To communicate with other agents, external messages can be sent and received. These messages are specified as internal send and receive events. The syntax associated with state transitions is as follows trigger(args1) guard / transmission(args2)Page 19 of 32 Technical Report: Engineering Multiagent Organizations Last printed 1/12/2004 09:45:00 AM, Page 20 of 32 This is interpreted to mean that if an event trigger is received with a number of arguments args1 and the condition guard holds, then the message transmission is sent with the set of arguments args2. Actions may be performed in a state and are written as functions. Besides communicating with other agents, tasks can interact with the environment via reading percepts or performing operations that affect the environment. This interaction is typically captured by functions executed while in specific states. 3.2 MaSE Design Once the concurrent tasks of each role are completely defined, the MaSE Analysis Phase is completed and design begins. The MaSE Design Phase is used to create agent classes (from which agents are instantiated), the conversations between agent classes, and the internal definition of the agent classes. This is accomplished in four steps: Creating Agent Classes, Constructing Conversations, Assembling Agents, and System Deployment.In the Creating Agent Classes step, agent classes are created based on roles from the analysis phase. Agent classes and the conversations between them are captured via Agent Class Diagrams, Figure 5, which depicts agent classes as boxes and the conversations between them as lines connecting the agent classes. Each agent class is assigned to play at least one role while multiple agent classes may be assigned the same role. Since agents inherit the communication of their roles, any communications between roles become conversations between their respective classes. Thus, as roles are assigned to agent classes, the overall organization of the system is defined.Agent Class 1 Conversation 1 Agent Class 3 Conversation 3 Agent Class 4 Role A Role B Role C Role BConversation 2 Agent Class 2 Conversation 4 Role BFigure 5. Agent Class DiagramOnce the conversations have been identified, the next step, Constructing Conversations, which define coordination protocols between two agents. Specifically, a conversation consists of two Communication Class Diagrams, one each for the initiator and responder. A Communication Class Diagram is a pair of finite state machines that define a conversation between two participant agent classes. Both sides of a conversation are shown in Figure 6. The initiator always begins the conversation by sending the first message. The state machines should be consistent with each other; all messages sent by one side of the conversation should be able to be received by the other with reaching deadlock. The syntax for Communication Class Diagrams is similar to that ofPage 20 of 32 Technical Report: Engineering Multiagent Organizations Last printed 1/12/2004 09:45:00 AM, Page 21 of 32 Concurrent Task Diagrams. The main difference between conversations and concurrent tasks is that concurrent tasks may include multiple conversations between many different roles and tasks whereas conversations are binary exchanges between individual agents.^send(info) send(info) [failed] wait acknowledge ^ failure-transmission validation wait failed = validate(info) send(info) failure-transmission ^ [NOT failed] ^ acknowledge send(info)Figure 6. Agent Conversation DiagramsIn the Assembling Agents step, the internals of agent classes are created. Robinson 37 describes the details of assembling agents from a set of standard or user-defined architectures. This process is simplified by using an architectural modeling language that combines the abstract nature of traditional architectural description languages with the Object Constraint Language, which allows specification of low-level details. The actions specified in the tasks and conversations must be mapped to internal functions of the agent architecture, while a link between actions and conversations must also be made.The final step of MaSE is the System Deployment, in which the configuration of the actual system to be implemented is defined. In MaSE, the overall system architecture is defined using Deployment Diagrams to show the numbers, types, and locations of agents within a system as shown in Figure 7. The three dimensional boxes denote individual agents while the lines connecting them represent actual conversations. A dashed-line box encompasses agents that are located on the same physical platform.The agents in a Deployment Diagram are actual instances of agent classes from the Agent Class Diagram. Since the lines between agents indicate communications paths, they are derived from the conversations defined in the Agent Class Diagram as well. However, just because an agent type or conversation is defined in the Agent Class Diagram, it does not necessarily have to appear in a Deployment Diagram.4. EXTENSIONS TO MASETo effectively create an organizational model, each entity in the organizational model must be able to be derived from concepts modeled in our multiagent analysis and design approach. The only exception is that organizational assignments do not have to be captured directly since they are computed by the organization at runtime. A straightforward comparison, shown in Table 1, of the organizational model entities and the existing Page 21 of 32 Technical Report: Engineering Multiagent Organizations Last printed 1/12/2004 09:45:00 AM, Page 22 of 32 MaSE modeling concepts shows that MaSE already captures most of the information needed to create a valid organizational model.FM1: FM2: FileMonitor FileMonitor LM1: LM2: LoginMonitor LoginMonitorLM3: LoginMonitorUser: Notify: Notifier UserInterfaceFM3: FileMonitorLM4: FM4: LoginMonitor FileMonitorFigure 7. Deployment DiagramTable 1. Organizational Model - MaSE MappingOrg Model Required Modifications Entities MaSE Concepts Goals Goals Roles Roles Laws MaSE Rules Proposed in 10, not formalized Agent Agent class Capabilities New requirement achieves Goal – role mapping related Role to role protocols requires New requirement possesses New requirement capable Role to agent class mapping Current fixed – needs to be adaptive coord Conversations However, since MaSE does not capture all the organizational model entities and relationships, it must be modified. The modifications fall into three categories:1. Formalization of organizational rules and lawsPage 22 of 32 Technical Report: Engineering Multiagent Organizations Last printed 1/12/2004 09:45:00 AM, Page 23 of 32 2. Integration of capabilities and the relationships between capabilities and roles and agents 3. Modification of the relationship between roles and agent classesThe requirements for of these modifications will be discussed in the following sections.4.1 Law Formalization While we proposed organizational rules in 10 to model constraints on multiagent systems, we never defined a formal syntax or context with which to integrate them into MaSE. However, given the organizational model, at least one of the purposes of organizational rules is to constrain the assignment of agents, roles, and goals. However, it is not a simple matter of writing logical statements over agents, roles and goals. We must consider the assignment of agents, roles, and goals in the context of their relationships with other entities within the organization. Thus, at a minimum, the rules must be able to refer to each entity in the organizational model. However, given the formalization of the organizational model above, this is straightforward. Generic rules such as “an agent may only play one role at a time” or “agents may only work on a single goal at a time” are easily modeled at this level using predicate logic (we assume universal quantification over agents, roles and goals). assigned(a, r, g)  (assigned(a, r1, g1)  r  r1) assigned(a,r, g)  (assigned(a, r1, g1)  g  g1)However, as discussed earlier in Section 2, organizational rules are often application specific and may need to refer to entities from the application domain as well. Thus to completely model organizational rules, we must also provide an ability to model the application environment entities. We have explored the integration of domain models into MaSE in both 10 and 13. Essentially, the domain model should be able to model the entities, their attributes, and their relationships. Figure 8 shows a simple example of a domain model using standard UML notation to show the relationships between three concrete entities that might be useful in a search and rescue domain: objects, victims, and locations. The domain model tells us that there are two types of entities in the environment: objects and victims. Presumably, we want to get around the objects to find the victims. Each entity is locatedAt precisely a single location, given in x, y coordinates. Also, the domain model states that only one entity may be at any given location at a time (i.e., victims may not be located inside objects, etc.). This new information, when combined with the information from the organizational model, gives us the ability to specify application specific rules. We use the notation that allows us to reference domain model classes as types, where attributes and associations are functions on those types. For attributes, we use the shorthand instance.attribute to refer to the function attribute applied to instance. For example, in Figure 8, for an instance v of type Victim, the function v.Alive would return a Boolean value.Page 23 of 32 Technical Report: Engineering Multiagent Organizations Last printed 1/12/2004 09:45:00 AM, Page 24 of 32Location Entity X : real 1 locatedAt 0 .. 1 Y : realObject VictimMoveable : Boolean Alive : Boolean Rescued : Boolean Found : BooleanFigure 8. Domain ModelAssociations can be read in either direction, with the result of the association function given by the multiplicity of the association. Therefore, each association name is an overloaded function. In Figure 8, the association locatedAt would generate two functions: locatedAt::Location  Entity {undefined} locatedAt : Entity  LocationThus, we can combine this new information, along with specific information about the actual organization (specific goals, roles, agents, capabilities, etc.) to form application specific rules such as “the number of searchers assigned must be less than, or equal to the total number of unrescued victims”. Here we use # to denote cardinality while Searcher refers to a specific role defined in the organizational model.#{a | a : Agent  assigned(a, r, g)  r  Searcher} #{v | v :Victim  v.Found  v.Rescued}4.2 Capability Integration Adding capabilities to MaSE is relatively straightforward on the surface, but allows significantly greater system adaptivity. Since capabilities are simple entities (they have no attributes except a name), they do not require their own model to define. We simply need to attach the requirement for specific capabilities to roles and the possession of capabilities to agents. In actuality, capabilities are required by the concurrent tasks that comprise each role. Therefore, we simply modify the MaSE Role Model to allow the specification of a list of required capabilities for each concurrent task as shown in Figure 9. In this example, there are four distinct capabilities. The capability set (as defined in Section 2.2) of each role is simply the set of all capabilities required for its set of concurrent tasks. Thus, RoleA would require the set {capability_1, capability_2, capability_3} , while RoleB requires {capability_3}, and RoleC requires {capability_2, capability_3, capability_4}. These values are static and do not change during the organization’s lifetime.Page 24 of 32 Technical Report: Engineering Multiagent Organizations Last printed 1/12/2004 09:45:00 AM, Page 25 of 32Role A Role B Role C goal list goal list goal listTask 1 Task 5 Task 2 Task 3 Task 4 capability_1 capability_3 capabiilty_2 capability_3 capabiilty_2 capabiilty_3 Protocol Protocol capabiilty_4 name nameFigure 9. Modified Role ModelWe can also add the set of capabilities possessed by particular agent types by modifying the MaSE Agent Class Diagram. Instead of having each agent class contain a list of roles it can play, we simply replace it with a list of capabilities, as shown in Figure 10. We also add the ability to specify the default value of the organization model’s possesses function for each agent-capability pair. While this appears to be simply a cosmetic change, its ramifications are significant. Instead of designing agents to perform specific roles, a capabilities based design will focus on providing specific capabilities. This can make the final design more flexible. For example, in the original Agent Class Diagram in Figure 5, Agent Class 4 was specified as only being able to perform Role C. However, after breaking out the capabilities, we can see that Agent Class 4 could also be employed to play Role B as well (assuming it was given the capabilities to respond to the appropriate conversations).Agent Class 1 Agent Class 4 · Capability_1 = 1.0 Conversation 1 Agent Class 3 Conversation 3 · Capability_2 = 0.8 · Capability_2 = 1.0 · Capability_3 = 0.9 · Capability_3 = 1.0 · Capability_3 = 0.5 · Capability_4 = 0.7Conversation 2 Agent Class 2 Conversation 4 · Capability_3 = 0.8Figure 10. Modified Agent Class DiagramIt is important to note that the capabilities listed in the modified Agent Class Diagram refer only to possible capabilities. The actual capabilities – the actual value of the possesses function– of a given agent may be dynamic. For instance, if capability_3 requires access to a local database, the agent will only have that capability if a local database is actually located on the current machine and is accessible to the agent. Thus defining a system in terms of capabilities allows the agents to dynamically determine their capability set and thus, the roles they may play in the organization. The capable function is defined based on the agent’s capability set as defined in Section 2.2. Page 25 of 32 Technical Report: Engineering Multiagent Organizations Last printed 1/12/2004 09:45:00 AM, Page 26 of 32 This dynamic capability computation is especially important in hardware intensive multiagent systems, such as cooperative robotic systems where the agents are physical robots. Capabilities then refer to a robot’s specific set of sensors and effectors. As these hardware systems fail, or are repaired, the capabilities of the robots change.4.3 agentTool The agentTool system is our attempt to implement a tool to support and enforce the MaSE methodology. agentTool implements all seven MaSE steps and provides automated support for transforming analysis models into design models 42. The agentTool user interface is shown in Figure 11. The menus across the top allow access to several system functions, including conversation verification 27 and code generation. The buttons on the left add specific items to the diagrams while the text window below them displays system messages. The different MaSE diagrams are accessed via the tabbed panels across the top of the main window. When a MaSE diagram is selected, the designer can manipulate it graphically in the window.Figure 11. agentTool User InterfaceModifying agentTool to incorporate the proposed changes to MaSE will be relatively straightforward, with the exception of the specification of organizational laws and code generation. Specification of organizational laws will require the definition of a language for specifying constraints that allows the use of artifacts defined by MaSE diagrams, organizational concepts, and domain model concepts. This language may bePage 26 of 32 Technical Report: Engineering Multiagent Organizations Last printed 1/12/2004 09:45:00 AM, Page 27 of 32 derived from existing languages such as UML’s Object Constraint Language or Alloy 20; we will also consider the use of languages with temporal operators 51. Once a base language has been chosen, it will be adapted and its semantics mapped to MaSE and organizational concepts. A parser will be developed to read in and verify the syntax of the organizational laws. Once they are encoded in an internal form, code will be generated to allow enforcement of the rules. Exactly how the laws will be enforced will depend on the type of laws they are and the re-organizational techniques chosen. We have been manually encoding each law as a separate object with a satisfied method that determines if the law is currently satisfied by the current organization. The satisfied method of each law is then used by the re-organizational search algorithm to help prune the search space.The current architecture used to generate Java code is shown in Figure 12. Each agent has an automatically generated Agent Component that handles component instantiation, external and inter-component message routing, and mobility issues. Each concurrent task is mapped to component, which runs in its own thread of control. Conversations, which handle the actual communications, are extracted from the concurrent tasks.Task Control - task instantiation Agent Component - message routing - mobilityComponent 1 Component 2 intra-agent communicationConversation 1 Conversation 2 Conversation 3 Conversation 4 inter-agent communicationFigure 12. Current Generated ArchitectureAdding the organizational model and organizational reasoning algorithms into each agent will, in effect, require an additional, higher-level reasoning level be added to the Agent Component. This organizational level will be responsible for communicating directly with other agents about organizational matters. The organizational level will pass information to the agent about the roles it is expected to play and the agents with which it is required to coordination. We believe that much of the organizational level will be in the form of generic code that can be reused “as is” in most applications. Various configuration options, such as reorganization techniques, will be selected by the designer when the code is generated. Based on our use of agentTool in the development of numerous multiagent systems, we believe that most of the MaSE design stage can be automated by generating code directly from concurrent tasks based on the capabilities available to each agent type. A new architecturePage 27 of 32 Technical Report: Engineering Multiagent Organizations Last printed 1/12/2004 09:45:00 AM, Page 28 of 32 supporting this approach is shown in Figure 13, which includes the organizational reasoning component discussed above, a slightly modified agent component, and a set of concurrent task components, which include the functionality of both the components and conversations from Figure 12.Organizational ReasoningAgent ComponentTask 1 Task 2Figure 13. New Generated Architecture5. CONCLUSIONS We have defined a model of artificial organizations that is useful in a wide variety of multiagent and cooperative robotic applications. In this paper we have shown how most of the concepts required to build this organizational model can be extracted from the existing Multiagent Systems Engineering methodology, and that with a few extensions, all organization model concepts can be included. Thus, not only have we developed a theoretical model for use in building adaptive multiagent and cooperative robotic systems, but by providing procedures and structures for capturing the required knowledge about organizational rules, roles, and goals, users will have been given valuable tools to help them apply the model. While our current research addresses reorganization only within a predefined structure, we eventually plan to study structure-based reorganization, which includes real-time modification of goals, roles, rules, role relationships, and capabilities. For instance, if an organization cannot meet its current goals, it should have the ability to modify its goals, using techniques such as goal relaxation 9. We also plan to investigate user-controlled organizational modification (allowing users to modify the organizational structure) to allow users to direct large cooperative robot teams in complex tasks. ACKNOWLEDGMENTS This research is supported by a grant from the Air Force Office of Scientific Research (AFOSR) under grant number F49620-02-1-0427.Page 28 of 32 Technical Report: Engineering Multiagent Organizations Last printed 1/12/2004 09:45:00 AM, Page 29 of 32REFERENCES[1] Blau, P.M. & Scott, W.R., Formal Organizations, Chandler, San Francisco, CA, 1962, 194-221.[2] Cabri, G., Leonardi, L., and Zambonelli, F. Implementing Agent Auctions using MARS. Technical Report MOSAICO/MO/98/001.[3] Carley, K. M. Computational and Mathematical Organization Theory: Perspective and Directions. Computational and Mathematical Organization Theory, 1995. 1(1): 39 – 56.[4] Carley, K. M. Organizational Adaptation. Annals of Operations Research, 1998. 75: 25-47.[5] Carley, K.M., and Gasser, L. Computational Organization Theory. In G. Weiss, ed. Multiagent Systems: A Modern Approach to Distributed Artificial Intelligence. MIT Press, Cambridge, MA, 1999.[6] Chaimowicz, L., Sugar, T., Kumar, V. and Campos, M. F. M., An Architecture for Tightly Coupled Multi- Agent Cooperation, Proceedings of the 2001 IEEE International Conference on Robotics and Automation, pp. 2292-2297. Seoul – Korea, May, 2001.[7] Cohen, P. R. and Levesque, H. J. 1991. “Teamwork”. Nous 25(4), Special Issue on Cognitive Science and Artificial Intelligence, 1991 pp. 487-512. [8] Cohen, P.R., & Levesque, H.J. “Intention is Choice with Commitment.” Artificial Intelligence, 42(3), 1990.[9] Cox, M. T., Edwin, G., Balasubramanian, K., & Elahi, M. Multiagent goal transformation and mixed- initiative planning using Prodigy/Agent. 5th World Multiconference on Systemics, Cybernetics and Informatics, vol 7, pp 1-6. Orlando, FL: International Institute of Informatics and Systemics. 2001.[10] DeLoach, S. A. Modeling Organizational Rules in the Multiagent Systems Engineering Methodology. Proceedings of the 15th Canadian Conference on Artificial Intelligence. May 27-29, 2002.[11] DeLoach, S. A. Analysis and Design of Multiagent Systems Using Hybrid Coordination Media. Proceedings of Software Engineering in Multiagent Systems (SEMAS 2002). Orlando, Florida. July 18, 2002. [12] DeLoach, S. A., Wood, M. F. and Sparkman, C. H., “Multiagent Systems Engineering”. The International Journal of Software Engineering and Knowledge Engineering, 11(3), pp. 231-258, June 2001.[13] DiLeo, J., Jacobs, T., and DeLoach, S. A. Integrating Ontologies into Multiagent Systems Engineering. Fourth International Bi-Conference Workshop on Agent-Oriented Information Systems (AOIS-2002). 15-16 July 2002, Bologna (Italy).[14] Far, B.H., Hajji, H., Saniepour, S., Soueina, S.O., Elkhouly, M.M., Formalization of Organizational Intelligence for Multiagent System Design. IEICE Trans on Information and Systems. E83-D(4), April 2000.[15] Ferber, J., Gutknecht, O., Jonker, C.M., Müller, J.P., and Treur, J., Organization Models and Behavioral Requirements Specification for Multi-Agent Systems. In: Y. Demazeau, F. Garijo (eds.), Multi-Agent System Page 29 of 32 Technical Report: Engineering Multiagent Organizations Last printed 1/12/2004 09:45:00 AM, Page 30 of 32 Organizations. Proc. of the 10th European Workshop on Modeling Autonomous Agents in a Multi-Agent World, MAAMAW'01. LNAI, Springer Verlag, 2002.[16] Fischer, M. J., Lynch, N. A., and Paterson, M. S. “Impossibility of Distributed Consensus with One Faulty Process,” J. ACM 32, 2 (April 1985), 374--382.[17] Grosz, B. and Sidner, C. Plans for Discourse. In P.R. Cohen, J. Morgan, and M. Pollack, eds., Intentions in Communication. pp 417-444. MIT Press, 1990.[18] Grosz, B. J., and Kraus, S. “Collaborative plans for complex group action”. Artificial Intelligence 86(2): 269- 357, 1996.[19] Ishida, T., Gasser, L., and Yokoo, M. “Organization self design of production systems”. IEEE Transactions on Knowledge and Data Engineering, 4(2): 123--134, April 1992.[20] Jackson, D. “Alloy: A Lightweight Object Modeling Notation.” ACM Transactions on Software Engineering and Methodology (TOSEM), 11(2):256--290, 2002.[21] Jennings, N. R. “Commitments and Conventions: The Foundation of Coordination in Multiagent Systems”. The Knowledge Engineering Review, 8(3): 223-250, 1993.[22] Jennings, N.R. “Controlling Cooperative Problem Solving in Industrial Multi-Agent Systems Using Joint Intentions”. Artificial Intelligence, 75 (2) 195-240, 1995.[23] Jennings, N.R. Towards a Cooperation Knowledge Level For Collaborative Problem Solving. In Bernd Neumann, editor, Proceedings of the 10th European Conference on Artificial Intelligence, pages 224-228, Vienna, Austria, August 1992. John Wiley & Sons Ltd.[24] Kendall, E. Agent Roles and Role Models: New Abstractions for Multiagent System Analysis and Design. Proceedings of the International Workshop on Intelligent Agents in Information and Process Management, Bremen, Germany, September 1998[25] Kinny, D., Ljungberg, M., Rao, A. S., Sonenberg, E., Tidhar, G. and Werner, E. Planned Team Activity. In Artificial Social Systems - Selected Papers from the Fourth European Workshop on Modeling Autonomous Agents in a Multi-Agent World (MAAMAW-92), C. Castelfranchi and E. Werner, Eds. pp. 226--256. Volume 830 LNAI, Springer-Verlag, Heidelberg, 1992.[26] Lawrence, P.R., and Lorsch, J.W., Organization and Environment: Managing Differentiation and Integration, Division of Research, Graduate School of Business Administration, Harvard University, 1967.[27] Lacey, T. and DeLoach, S. A. Automatic Verification of Multiagent Conversations. Proceedings of the Eleventh Annual Midwest Artificial Intelligence & Cognitive Science Conference, pp 93-100. AAAI, 2000.Page 30 of 32 Technical Report: Engineering Multiagent Organizations Last printed 1/12/2004 09:45:00 AM, Page 31 of 32[28] Levesque, H. J., Cohen, P. R., and Nunes, J. On acting together. In Proceedings of the National Conference on Artificial Intelligence. Menlo Park, Calif.: AAAI press, 1990.[29] Matson, E., DeLoach, S. Capability in Organization Based Multi-agent Systems, Proceedings of the Intelligent and Computer Systems (IS ’03) Conference, Information Society. Institute Jozef Stefan, Ljubljana, Slovenia, October 13-17, 2003.[30] Matson, E., DeLoach, S. Organizational Model for Cooperative and Sustaining Robotic Ecologies, Proceedings of the Robosphere 2002 Workshop, NASA Ames Research Center, Moffett Field, California, November 14-15, 2002.[31] MESSAGE: Methodology for Engineering Systems of Software Agents. Deliverable 1. Initial Methodology. July 2000. EURESCOM Project P907-GI.[32] Moses, Y. and Tennenholtz, M. Artificial Social Systems Part I: Basic Principles. Technical Report CS90- 12, Weizmann Institute, 1990.[33] Moses, Y., and Tennenholtz, M. “Artificial Social Systems”. Computers and Artificial Intelligence, 14(3): 533-562, 1995.[34] Parker, L. “ALLIANCE: An Architecture for Fault-Tolerant Multi-Agent Cooperation”. IEEE Transactions on Robotics and Automation, 14 (2), 220—240, 1998.[35] Pollack, M.E. Plans as complex mental attitudes. In Phillip R. Cohen, Jerry Morgan, and Martha E. Pollack, editors, Intentions in Communication, pages 77-- 103. MIT Press, Cambridge, MA, 1990.[36] Richters, M. and Gogolla, M. On formalizing the UML object constraint language OCL. In Proc. 17th International Conference on Conceptual Modeling (ER), 1507:449-464. Springer-Verlag, 1998.[37] Robinson, D. A Component-based Approach to Agent Specification. MS Thesis. Air Force Institute of Technology (AU), AFIT/GCS/ENG/00M-22. March 2000.[38] S. Onn and M. Tennenholtz. “Determination of social laws for multi-agent mobilization”. Artificial Intelligence, 95:155--167, 1997.[39] Shen, W., Chuong, C., Will, P. Simulating Self-Organization for Multi-Agent Systems. International Conference on Intelligent and Robotic Systems, Switzerland, 2002.[40] Shoham, Y. and Tennenholtz, M. “On Social Laws for Artificial Agent Societies: Off-line Design”. Artificial Intelligence, 73, 1995. 47[41] Sonenberg, E., Tidhar, G., Werner, E., Kinny, D., Ljungberg, M., and Rao, A. Planned Team Activity. Technical Report 26, Australian Artificial Intelligence Institute, Australia, 1992.Page 31 of 32 Technical Report: Engineering Multiagent Organizations Last printed 1/12/2004 09:45:00 AM, Page 32 of 32[42] Sparkman, C. H., DeLoach, S. A., and Self, A. L. Automated Derivation of Complex Agent Architectures from Analysis Specifications, Proceedings of the Second International Workshop On Agent-Oriented Software Engineering (AOSE-2001), Montreal, Canada, May 29th 2001.[43] Tambe, M. and Zhang, W., Towards Flexible Teamwork in Persistent Teams. Second International Conference on Multi-Agent Systems, 1996.[44] Tambe, M. “Towards flexible teamwork”. Journal of Artificial Intelligence Research, 7:83--124, 1997.[45] Turner, R. M., and Turner, E. H. A Two-Level, Protocol-Based Approach to Controlling Autonomous Oceanographic Sampling Networks. IEEE Journal of Oceanic Engineering, 26 (4), pp. 654-666, Oct 2001.[46] Wagner, G. Agent-Oriented Analysis and Design of Organizational Information Systems. Proceedings of the 4th IEEE International Baltic Workshop on Databases and Information Systems, May 2000.[47] Wooldridge, M., Jennings, N.R., and Kinny, D. “The Gaia Methodology for Agent-Oriented Analysis and Design”. Journal of Autonomous Agents and Multi-Agent Systems. Volume 3(3), 2000.[48] Zambonelli, F., Jennings, N.R., and Wooldridge, M. Organisational Abstractions for the Analysis and Design of Multi-Agent Systems. In P. Ciancarini and M. Wooldridge, editors, in Agent-Oriented Software Engineering – Proceedings of the First International Workshop on Agent-Oriented Software Engineering, 10th June 2000, Limerick, Ireland. P. Ciancarini, M. Wooldridge, (Eds.) LNCS Vol. 1957, Springer Verlag, Berlin, pp 207-222, January 2001.[49] Zambonelli, F., Jennings, N.R., and Wooldridge, M.J. “Organisational Rules as an Abstraction for the Analysis and Design of Multi-Agent Systems”. International Journal of Software Engineering and Knowledge Engineering. Volume 11, Number 3, June 2001. Pages 303-328.[50] Zambonelli, F., Jennings, N.R., Omicini, A., and Wooldridge M.J. Agent-Oriented Software Engineering for Internet Applications. In Coordination of Internet Agents: Models, Technologies, and Applications. Springer- Verlag, March 2001.[51] Ziemann, P. and Gogolla, P. OCL Extended with Temporal Logic. In Broy and Zamulin, eds. 5th Int. Conf. Perspectives of System Informatics (PSI'2003), pp 351-357. Springer, Berlin, LNCS 2890, 2003.Page 32 of 32

Proceedings Template - WORD s17

Details

Download

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

Support