Proceedings Template - WORDpeople.cis.ksu.edu/~binti/MASEOrgModel.doc · Web viewINTRODUCTION. Recent trends in multiagent systems are toward the explicit design and use of social

Technical Report: Engineering Multiagent OrganizationsLast printed 1/12/2004 09:45:00 AM,

Page 1 of 32

Engineering Multiagent OrganizationsScott DeLoach Eric MatsonMultiagent and Cooperative Robotics Laboratory

Department of Computing and Information Sciences, Kansas State University234 Nichols Hall, Manhattan, Kansas 66506, USA

(785) 532-6350

{sdeloach, matson}@cis.ksu.edu

ABSTRACTIn 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.

1. 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

Page 1 of 32


Page 2 of 32

centralized/distributed 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 2 presents a review of relevant background research.

We then discuss our approach to modeling multiagent organizations in Section 3 and our approach for analyzing

and designing general purpose multiagent systems in Section 4. In Section 5, 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.

2. BACKGROUND

2.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

Page 2 of 32


Page 3 of 32

organization. The interaction function allows the organization to interact with, and affect its environment. The

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.

2.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

Page 3 of 32


Page 4 of 32

action or pursuing a state, the team member may not drop that commitment without just cause. Acceptable

causes 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”

Page 4 of 32


Page 5 of 32

message is sent. In agree-and-execute, the team leader sends a request that potential team members agree to play

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.

2.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


Page 6 of 32

2.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].

Page 6 of 32


Page 7 of 32

2.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 actual

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.

3. 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.

Page 7 of 32


Page 8 of 32

O = <Ostructure, Ostate, Otrans>

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).

Organizationocf()

Rolercf(Agent) Agent

Law

related coord

Capabilities

assigned

requires

Possesses- capabilityScore

AchievesgoalSatScore

Capable- roleScore

Assignment- score constrains

Goalconjunctive : Boolean

precedes

subgoal

Figure 1. Organizational Model

Formally, we model the organization structure as a tuple.

Ostructure = <G, R, L, C, achieves, related, requires, subgoal, precedes>

where

achieves: R, G 0 .. 1related: R, R Booleanrequires: R, C Booleansubgoal: G, G Booleanprecedes: 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

Page 8 of 32


Page 9 of 32

a 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 .. 1capable: A, R 0 .. 1assigned: A, R, G 0 .. 1coord: A, A Boolean

Page 9 of 32


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 that

Otrans(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)

where

Otrans(state)(O). Ostruct = O.Ostruct Otrans(state)(O). Ostate.A = Ostate.A

Page 10 of 32


Page 11 of 32

Otrans(state)(O).Ostate.possesses = Ostate.possesses Otrans(state)(O).Ostate.capable = Ostate.capable (3)

3.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.

3.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


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)

3.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


Page 13 of 32

3.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.

}0),(|{)( capossessescaCa (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.

(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

(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.

(7)

(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).

3.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


Page 14 of 32

3.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

Page 14 of 32


Page 15 of 32

occurred, and (2) deal with the consequences. We plan to investigate both “time out” periods and intermittent

polling for this case.

3.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.

3.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 assigned4. 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.

3.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 by

Page 15 of 32


Page 16 of 32

(9)

where assigned(a,r,g) = 0 if that agent is not assigned to play a specific role to satisfy a goal.

3.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).

Figure 2. Organization Example

The 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 Function

R1 R2 R3 R4 R5A1 0.5 0 0.6 0 0A2 0 0 0.7 0 0A3 0 0 0 0.6 0.6A4 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


Page 17 of 32

assigned(A1,R1,D) = 0.25

assigned(A2,R3,E) = 0.56

assigned(A3,R5,G) = 0.42

Os = 1.23

4. 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.

Figure 2. MaSE Methodology

Page 17 of 32


Page 18 of 32

MaSE 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

model 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.

4.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

Page 18 of 32


Page 19 of 32

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.

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.

Figure 3. Role Model

Figure 4. Concurrent Task Diagram

Role 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

Page 19 of 32


Page 20 of 32

trigger(args1) guard / transmission(args2)

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.

4.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.

Figure 5. Agent Class Diagram

Once 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

Page 20 of 32


Page 21 of 32

to be received by the other with reaching deadlock. The syntax for Communication Class Diagrams is similar to

that of 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.

Figure 6. Agent Conversation Diagrams

In 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.

5. EXTENSIONS TO MASE

To 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

Page 21 of 32


Page 22 of 32

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

MaSE modeling concepts shows that MaSE already captures most of the information needed to create a valid

organizational model.

Figure 7. Deployment Diagram

Table 1. Organizational Model - MaSE Mapping

Org Model Entities MaSE Concepts

Required Modifications

Goals GoalsRoles RolesLaws MaSE Rules Proposed in [10], not formalizedAgent Agent classCapabilities New requirementachieves Goal – role mappingrelated Role to role protocolsrequires New requirementpossesses New requirementcapable Role to agent class mapping Current fixed – needs to be adaptivecoord Conversations

Page 22 of 32


Page 23 of 32

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 laws2. Integration of capabilities and the relationships between capabilities and roles and agents3. Modification of the relationship between roles and agent classes

The requirements for of these modifications will be discussed in the following sections.

5.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).

However, as discussed earlier in Section 3, 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


Page 24 of 32

Figure 8. Domain Model

Associations 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:

Thus, 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.

5.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 3.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


Page 25 of 32

Figure 9. Modified Role Model

We 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).

Figure 10. Modified Agent Class Diagram

It 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 3.2.

Page 25 of 32


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.

5.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 Interface

Modifying 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

Page 26 of 32


Page 27 of 32

artifacts defined by MaSE diagrams, organizational concepts, and domain model concepts. This language may be

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.

Figure 12. Current Generated Architecture

Adding 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

Page 27 of 32


Page 28 of 32

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 architecture 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.

Figure 13. New Generated Architecture

6. 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.

7. 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


Page 29 of 32

8. REFERENCES

[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.

Page 29 of 32


Page 30 of 32

[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

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.

Page 30 of 32


Page 31 of 32

[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.

[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

Page 31 of 32


Page 32 of 32

[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.

[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

Documents

Proceedings Template - WORDpeople.cis.ksu.edu/~binti/MASEOrgModel.doc · Web viewINTRODUCTION. Recent trends in multiagent systems are toward the explicit design and use of social