This chapter presents an approach to organizational-self design (OSD), a method of designing organizations at run-time in which the agents are responsible for generating their own organizational structures. OSD is especially suitable for environments that are dynamic, albeit slowly changing. Such environments preclude the use of static, design-time generated, organizational structures, and yet contain certain characteristics and conditions that change slowly, if at all, and these characteristics can be harnessed for the purposes of creating stable organizational structures. This chapter extends the existing approaches to OSD by applying them to worth-oriented domains – that is, domains in which problems are represented using TÆMS based task structures. This chapter presents our OSD primitives and framework and discusses some interesting future lines of research.
Multiagent systems are increasingly being used to solve a wide variety of problems in a range of applications such as distributed sensing, information retrieval, workflow and business process management, air traffic control and spacecraft control, amongst others. Each of these systems has to be designed at two levels: the micro-architecture level, which involves the design of the individual agents, and the macro-architecture level, which involves the design of organizational and social aspects of the system. In this book, we are primarily concerned with the macro-architectural, organizational design of the multiagent system.
At the organizational level, the multiagent designer is primarily concerned with issues such as the number of agents needed to solve the problem, the task structure (i.e. the breakup of the problem into subgoals), the task and resource assignments to the individual agents and the coordination mechanisms to be used. These issues can be resolved by choosing an organizational structure and by instantiating that structure with actual agents. The organizational structure consists of roles that the agents play and the manner in which they interact with other agents in the system. The instantiation consists of selecting the number of agents needed in the system and the assignment of roles and resources to the individual agents.
The organizational structure employed directly influences the effectiveness of the organization in solving the problem at hand, the resources needed by the agents and the cost of coordinating the activities of the individual agents. Hence, the organizational design is a very important part of the multiagent system design. However, there are few good rules and formal mechanisms for designing effective organizations for computational agents that are general enough for a wide range of agent systems. For example, consider the question of the number of agents needed in the system. If too few agents are available, the system will be overloaded and will not be able to perform optimally. If too many agents are used, resources may be wasted and contention for the limited resources amongst the agents will increase.
The macro-architectural design is further complicated by the fact that there is no best way to organize and all ways of organizing are not equally effective (Carley and Gasser, 1999). Instead, the optimal organizational structure depends both on the problem at hand and the environmental conditions under which the problem needs to be solved. In some cases, the environmental conditions may not be known a priori, at design time, in which case the multiagent designer does not know how to come up with the suitable organizational structure. In other cases, the environmental conditions may change requiring a redesign of the agents’ macro-architecture. Hence, it is not obvious that a static design-time approach to an organizational structure is feasible in a significant number of cases. At the opposite end of the spectrum, systems may be designed to create a new, bespoke organizational structure for every problem instance. The most popular example of such a one-off task allocation approach is the Contract Net protocol (Smith and Davis (1978)). Such an approach brings with it a different set of inefficiencies and belies the fact that while many real environments have dynamic components, there are also commonalities in the structure of problem instances that can be taken advantage of through proper organizational structuring.
Organizational Self-Design (OSD) (Corkill and Lesser, 1983; Ishida et al., 1992) has been proposed as an approach to designing organizations at run-time in which the agents are responsible for generating their own organizational structures. We believe that OSD is especially suited to the above scenario in which the environment is semi-dynamic as the agents can adapt to changes in the task structures and environmental conditions, while still being able to generate relatively stable organizational structures that exploit the common characteristics across problem instances.
Key Terms in this Chapter
Teamplan Petri Net: A Petri net representing the plan of a team.
Team: A set of agents that are put together as a necessary structure to pool skills and resources in order to satisfy the goals of a mission through collaboration.
Hierarchical Teamplan: A hierarchical Petri net featuring the different subteams within the team. As the marking of the hierarchical teamplan evolves, the dynamics of the subteams is highlighted.
Petri Net: (P, T, F, B): A bipartite graph with two types of nodes: P is a finite set of places and T is a finite set of transitions. Arcs are directed and represent the forward incidence function F: PT IN and the backward incidence function B: P T IN respectively. An interpreted Petri net is such that conditions and events are associated with places and transitions. When the conditions corresponding to some places are satisfied, tokens are assigned to those places and the net is said to be marked. The evolution of tokens within the net follows transition firing rules. Petri nets allow sequencing, parallelism and synchronization to be easily represented.
Local Teamplan Repair: Aims at repairing the plan of the team as locally as possible.