Revenir à la page d'accueil
Plan du site   |   Plan d’accès   |   UTBM
  
Projets Européens
Réseaux d'Excellence
Projets Nationaux
Contrats Industriels
Projets thématiques
    ASPECS Methodology
       Introduction
       A quick overview of ASPECS
       System Requirements Analysis
       Agent Society Design
          Solution Ontology Description
          Communication Ontological Description
          Role Behaviour Description
          Protocol Description
          Organisation Dependencies Description
          Role Constraints Identification
          Holarchy Design
       Implementation
       Deployment
       References
       Comparisons with existing Agent-Oriented Methodologies
Conférences
Séminaires
Accueil > Activités et projets > Projets thématiques > ASPECS Methodology > Agent Society Design > Holarchy Design
Holarchy Design

Holarchy Design

Two very important elements of the MAS metamodel are newly introduced in this activity; there are Agent and Holon. An Agent is an entity which can play a set of roles defined within various organisations; these roles interact each other in the specific context provided by the agent itself. Several AgentRoles are usually grouped in one Agent. The Agent context is given by its knowledge, its capacities and its environment. Roles share this context by the simple fact of being part of the same agent. This mean for instance that an agent can play the role of Buyer in an organisation and later the same agent can sell the goods it had just acquired thus playing for the same organisation a different role (Seller); conversely, the same agent can also play roles belonging to another organisation (for instance devoted to monitor businesses), i.e. it can play the role (AffairMonitor) to trace the results and the performance exploited during the first acquisition process. It is worth to note that the agent is still not an implementation-level element (platformdependent) but rather it needs further refinements. Figure ?? depicts the context defined by an agent as an interaction space for the roles it plays. These roles, in turn, belong to different organisations, each one defining its own context.

The concept of Holon is specialized from the Agent one. Two overlapping aspects have to be distinguished in the notion of Holon:

  • Administration and Holon Government: the first is directly related to the holonic nature of the entity (a holon, called super-holon, is composed of other holons, called sub-holons or members) and deals with the government and the administration of a super-holon. This aspect is common to every holon and thus called the holonic aspect. It describes the decision making process and how members organize and manage the super-holon.
  • Goal dependent Interactions: The second aspect is related to the problem to solve and the work to be done. It depends on the application domain and is called the production aspect. It describes action coordination mechanisms and interactions between members to achieve the objectives of the superholons, the tasks to fulfill, or to take a decision.

Agent and Holon symbolic representation
Figure 23: Agent and Holon symbolic representation

Naturally our definition of holon integrates these two aspects and it merges them within an organisational approach. An holon is thus a set of roles that can be defined on various organisations interacting in the specific context provided by the agent. An holon can play several roles in different organisations and it may be composed of other holons. A composed holon (super-holon) contains at least a single instance of a holonic organisation to precise how members organize and manage the super-holon and a set (at least one) of production organisations describing how members interact and coordinate their actions to fulfill the superholon tasks and objectives. An atomic (non composed) holon is an AtomicAgent. Figure ?? illustrates this definition of holon. Figure 24 details the missions attributed to these two different aspects of a super-holon.

 

 

 

 
Goal Strategy

Gouvernement

Administration 

  • Assigning goals and tasks
  • Control Self-organisation
  • Supervise decision process
  • Filter and/or translate information
  • Include/Exclude member
  • One role
  • Election
  • Comitee
Production Production Product services
  • one capacity
  • orchestrates n elementary services / capacities
Figure 24: The two overlapping aspects of a super-holon


 

 

Depending on the level of abstraction, a super-holon can be considered as an atomic entity (let’s say level n) or as an organisation of holons (let’s say level n-1). At the same way, several different holons could be seen as interacting individuals, parts of some organisation or as parts of a super-holon. Interactions usually happen in form of communications; interactions between layers, instead, can happen in two ways:

  • i) (internal) interactions of roles of the same agent (if the same agent plays different roles within a holon). For instance, an agent can be the Head delegated to accept some contract (a role of the holonic organisation, played at level n) but also the worker which will do part of the work related to that contract in the production organisation at level n-1; the Agent existence in this case enables interactions among different roles.
  • ii) (external) interactions (mostly communications) between roles belonging to different layers and to several agents. For instance the Head (layer n) responsible for accepting a contract asks worker roles (layer n-1) to provide the service.


Goal

Based on this knowledge, this activity aims at refining the solution architecture. This activity is decomposed in four main tasks:

  • a. firstly the agentification task consists in identifying all the required agents/holons and associating them with the set of roles they have to play. To achieve that, each previously identified organisations are specialized into Group. It is used to model groups of Agents that cooperate in order to achieve a goal. The association between Agents and AgentRoles allows the identification of the set of capacities that each agents has to possess to play these roles. It provides precise indications on the architecture that should be adopted for agents. Indeed the agent architecture is at least defined by the set of roles that the agent should play, the minimal set of services that implement capacities required by these roles.
  • b. The second task focusses on composed holons and aims at identifying a government type for each of them. The objective consists in describing the various rules used to take decisions inside each super-holon.
  • c. Then, all the previously described elements are merged in order to obtain the complete set of holons (composed or not) involved in the solution. In this way, the complete holarchy of the system at the instance level is described.
  • d. The description obtained with the previous tasks is just the initial structure of the system, the last objective is now to specify rules that govern holons’ dynamics in the system (creation, new member integration, specific self-organisation mechanisms, scheduling policies for roles) in order to support a dynamic evolution of the system holarchy.

This activity is the final one of the agent society design phase. It aims at summarizing all the informations resulting from this phase in a single work product describing the initial structure of the system.


Input

The major inputs of this activity are the work products of organisations dependencies description and role constraints identification activities. These results will allow to determine for each holon its set of roles and the associated set of required services.


Output

The output of this phase describes the initial structure of the complete designed system. Each level of the holarchy and its set of groups have to be described. Each holon and agent with its associated set of roles is also reported on it. The suggested notation consists in a static structural representation of a holarchy; it is inspired by the cheese-board diagram proposed in [27] adapted to better represent the holonic perspective. in this type of diagram, a Group is represented by an oval associated to its name in the form g[Id]:[OrganisationName]. Agents (and non composed Holons) are represented as skittles that cross groups ovals. An agent can belong to several groups and thus cross various group ovals. Roles are represented by rectangle crossing agent and its related group. Composed holons are represented by a skittle at a given level n linked with its set of internal organisations of level n − 1 (holonic and production ones) with dashed lines. An agent can play several roles in the same group. The example section of this activity gives more details on this notation.


MAS Metamodel Elements

Define(Agent), Define(Holon), Define(Group), Relate(Agent, AgentRole), Relate(Holon, AgentRole), Relate(Holon, Holonic Organisation), Relate(Group, Agent), Relate(Group, Holon), Define(Holonic Role), Define (Government rules).


Work to be done

A super-holon is a community of holons that cooperate to achieve a commonly agreed objective. In order to allow a fruitful evolution of the super-holon structure at runtime, certain rules have to be defined. These rules will govern the evolution of the entire holonic structure. Such rules may deal with member’s inclusion (recruitment) or exclusion (banishment), tasks acceptation and attribution, holon destruction, etc. Describing holon internal structure and dynamic is thus a complex task. Three main aspects may be distinguished: Holon Member’s modeling, Holon Government, Holon Dynamics. Each of them will be briefly detailed below.


Holon Member’s modeling

This section deals with holonic related aspect of the notion of holon. The goal is to clarify how members holons are internally organized to generate and manage a super-holon. The Holonic organisation is defined to describe the government of a holon and its structure (in terms of authority, power repartition) thus it is the basis of the holon government and it represents a moderated group (see [34]) in terms of roles (called holonic roles) and their interactions. This management structure was adopted due the wide range of configurations it allows. In a moderated group, a subset of the members will represent all the sub-holons in the outside world.

Four roles are defined to describe the status of a member inside a super-holon:

  • Head, decision maker: it represents a privileged status confering a certain level of authority.
  • Representative, interface of the holon : it is an externally visible part of a superholon, it is an interface between the outside world (same level or upper level) and the other holon members. It may represent others members in taking certain decisions or accomplishing certain tasks (i.e. recruit member, translate information, etc). The Representative role can be played by more than one member at the same time.
  • Part: Classical members. Normally in charge of doing tasks affected by head, a Part can also have an administrative duty, and it may be employed in the decision making process. It depends on the configuration choosen for modeling the super-holon. The Part role represents members belonging to only one super-holon.
  • Multi-Part: extension of Part. This role is played by sub-holons shared by more than one super-holon.
    The holonic organisation is instantiated into a holonic group. The Holonic-Group element is a specialization of group, and it is devoted to contain roles taking care of the holon internal decision-making process (composed holon’s government).


Holon Government: Decision Making Process

The different rules introduced previously often require a decision making process. For instance when an external holon is requesting its admission as a member, the decision to accept or refuse him with a specific decision making mechanism should be defined (a voting mechanism may be used). This section does not intend to present an extensive discussion about decision making procedures and patterns; the reader interested on the subject may refer to [75]. Trying to enumerate all possible issues would probably result in an incomplete or domain dependent list.

Two aspects of the decision making process should be analyzed:

  • (i) who is in charge of taking the decisions and how this happens (head, vote, etc);
  • (ii) how the requesting process could be started (who is to be contacted by the external holon
    who wants to enter the super-holon to play a role within it).

The decision process for the admission of a new member can be done according to several different internal policies representing different levels of involvement of the holon members community: federation is positioned at one side of the spectrum; in this configuration, all members are equal when a decision has to be taken. Opposite to that there is the dictatorship, where heads are omnipotent; a decision taken by one of them does not have to be validated by any other member. In this government form, members loose most of their autonomy having to request permission of the head to provide a service or request a collective action. Even if these configurations may be useful in specific domains, generally an intermediate configuration will be desirable. In order to identify the right choice, it is firstly necessary to analyse the functionalities that will be provided by the holon, and then define the level of authority that the Head must have.

A versatile solution to this problem consists in establishing a voting mechanism for each functionality. In order to parameterize a voting mechanism, three elements have to be defined: Requester, Participants and Adoption Mechanism.

 

 

Parameter Description Options
Vote Requester Who can ask for a vote? Any member, a group of members
Vote Participant Once a vote has been called, who can participate in it? All members, heads only
Adoption Mechanism When a vote is adopted? Consensus, two-thirds, etc.
Table 3: Voting process parameters

 

 

The vote Requester defines which members are allowed to request for a vote; Participants are members that are authorized to participate in the voting process, and finally the adoption mechanism defines how a proposal is accepted or rejected. This scheme can be easily modelled as an organisation as shown in figure 25. The judge is incharge of gathering votes. It also determine the outcome of the vote according to the adoption mechanism (i.e. majority, unanimity).

Voting Organisation
Figure 25: Scenario of the Team Simulation Organisation

For selecting members that will play the Requester and Participants roles three possible options are available: all members, heads only, subgroup of holons.

About adoption mechanism, for the purposes of this paper it is sufficient to remark that several options could be considered, e.g. consensus, two-thirds, etc. An useful summary of the proposed options can be found in Table 3.

Specific and interesting configurations can arise from the number of voters and the percentage of heads and parts involved in the decision-making process, because of their relevance it is worth to analyse them in details:

  • Monarchy (one Head, one Voter, no voting Part) : the command is centralized and an Head is in charge. Monarchy, here, doesn’t refer to the process of Head’s nomination/election. The nomination process is a different issue from the decision-making process. Monarchy here describes the situation where only one head controls the entire decision-making process.
  • Oligarchy (n Heads, n Voters, no voting Part) : A little group of heads share the command without referring to the Part members.
  • Polyarchy (n Heads, n+k Voters, k voting Parts) 8: A little group of heads share the command but they have to refer to the Part for some decisions (i.e. when members unanimity is required).
  • Apanarchy (Everybody votes) 9: command is completely shared between all members of the super-holon. Everyone takes part in the decision-making process.


Holon Dynamics

Only the most common and important rules governing holon dynamimc are discussed in this part, especially ones dealing with members recruitment and holon creation. The first rule is about managing Inclusion/Exclusion of holon’s members. Once a super-holon has been created, new members may request to join it or the super-holon itself may require new members to achieve its goal/task (the new member admission process is called Merging). In order to support the integration of new members, a “standard” interface should be provided to external holons to request their admission. A specific organisation with two roles StandAlone (played by the candidate) and Representative (played by at least one of the representative of holons members) has been designed to manage this recruitment process. Another important aspect of the holon creation mechanism regards the motivations for the birth of a holon; these can in fact either depends on the need of satisfying in a collective way a requirement that cannot be accomplished by the single entities alone or on the need for improving the internal structure of an existing holon that is become too big and whose tasks are too complex to be managed. Concerning holon creation, it is therefore possible to distinguish two different mechanisms:

  • i) A top-down mecanism, sub-division: a super-holon whose tasks are too complex, decides to create a set of internal organisations that are able to execute these tasks thus distributing the computational cost and breaking down organisational complexity. This case could be reduced to a specific case of the initial creation process, because newly created holons are configured to satisfy the integration constraints with the super-holon.
  • ii) A bottom-up mecanism, fusion: (merging process): a set of holons decides to merge and create a super-holon to satisfy a common goal. In this case, all rules that will govern the life of the super-holon have to be defined. From an Engineering point of view, different approaches can be used:
    • a) Predefined: The holons were conceived so that the rules for the superholon are predefined and known by members in advance. This approach may be usefull when developping closed application. The adaptivity of these types of system will remain constrained to the anticipated cases only, and will probably prove impossible to use in large open environments.
    • b) Negotiation: The Merging process foresees a mechanism to negotiate the configuration of the super-holon. This approach allows a wider range of applications, and improved adaptive capabilities. But the negotiation process may induce important overheads. A mix between the previous approach and this one could help reducing the overhead. Even if the negociation might be qualified of “generic” approach, other problems are to be considered: for instance, the communication language used in the negotiations. In addition, trying to define all rules of a super-holon may prove to be a consequent task, introducing an enormous overhead to the creation of the super-holon.
    • c) Evolutive: The super-holon is created with a minimum of engagements of the members. The members can then increase their commitment toward the super-holon when they consider it useful. The minimal rules set contains only one rule: Add new rules. Using this rule with a voting mechanism, any new rule or modification of it can be obtained.

The FORM framework proposed by [65] describes such a method for task-oriented systems.


Methodological Guidelines

Solution Ontology gives important information for the definition of the holonic structure, rules and constraints are generally described in the ontology. Normally at this step, these constraints have been already associated to each organisation. In our example these constraints have been represented using OCL, placed in UML note and linked to the corresponding organisation. Table 4 also provides a set of question that may guide the design of holon government and the determination of rules that govern holons dynamic. Answer to these question facilitates the definition of the future super-holons functioning: not authorized process, decision are made by a vote, the heads take the decision...

 

Related aspects
Questions to answer
The addition of a new functionning rules
  • Is it possible to add new rules ?
  • By what process can we add of new functioning rule ?
Integration/Exclusion of a member
  • How are integrated the new members ?
  • How to exclude a member ?
New tasks Acceptance How are the new tasks accepted or refused ?
Choice and Acceptance of new objectives for the super-holon
  • Is it possible to add new goals to the super-holon
  • If yes, how ?
Super-holon actions Who take the decisions about the action selection ?
Multi-Part authorized
  • Are the members authorized to join other holons?
  • If yes, under which conditions ?
Leaving of one the members
  • Is it possible that a part leaves the super-holon without implying its destruction ?
  • If yes, under which conditions ?
Table 4: A part of the Holon Government Description Template


Example

The final structure of the holonic solution dealing with our Robot Soccer simulator is presented in figure 26. At the level 2 of the holarchy two superholons 1 and 2 plays the role Team in the group g0 : Game Simulation. This denomination indicates that group g0 is an instance of the Game Simulation organisation. As such, members involved in the group play one of the roles defined in this organisation. Each of them contains an instance of the Team Simulation organisation g2 and g6. Each composed holons (1, 2, 3, 7) constains a holonic group defining its governmental structure. Each Team Holon dispose of a simple government type inspired by the monarchy government type. The rule is that the holon playing the Strategy Selector role is automatically promoted Head and Representative of others members. The part holons 3 and 7 playing the Players Simulator role are decomposed, and each of them contains an instance of the Player Simulation organisation. Their government is inspired by the apanarchy government type where each member is involved in the decision process (everybody is head). The atomic holon 6, playing the MultiPart role, is shared in two couples of super-holons (1, 2) and (3, 7). This holon consitutes the environmental part of the application and plays all the boundary roles in agreement with the description made in the Role Constraints Identification phase.

The complete holonic structure of agent-oriented part of the Robot Soccer Simulator
Figure 26: The complete holonic structure of agent-oriented part of the Robot Soccer Simulator

  90010 Belfort cedex - Tél : +33 (0)3 84 58 33 19 - Fax : +33 (0)3 84 58 33 42 - Mentions légales