Entrevista dirigida al Gerente de la Vidriería Wal-Vid.

Although the collaborative reasoning assumes the set of agents to be fixed, during runtime agents may join or leave the system, e.g., during initial system set up or changes to the larger

MAS that uses DAREC2 _{to aid its functionality. In addition, in a dynamic MAS environment,}

agents must be able to update their knowledge. In order to guarantee the collaboration as- sumptions and maintain the consistency during collaborations, the changes to the set of agents and the agent knowledge must not occur when the system is engaged in any global abduc- tive reasoning tasks. Thus, agent joining/leaving and knowledge update must follow a set of pre-defined protocols, which are described next.

System Leader

As briefly discussed earlier in the Chapter, our implementation ensures that there is always a leader (agent) in the system. The leader behaves in the same way as other agents during collab- oration, but has extra responsibilities, such as handling the changes to the system and receiving external queries (i.e., initiating a global abductive task for each received query). In order to make sure that the set of agents and the agent knowledge do not change when the system is engaged in any collaborative reasoning, the leader maintains a numeric variable OngoingTasks for counting the number of global abductive tasks being performed by the system. This vari- able, initially being zero, is incremented whenever the leader initiates a global task, and is

decremented whenever a task is finished (see Section 5.5.5). Thus, an agent is allowed to join,

leave or update its knowledge only when OngoingTasks is equal to zero.

The leader in a system can be either appointed or elected. Leader appointment occurs in two cases. At the initial system set up, the first agent to come alive in the system will be assumed (to be appointed) the role of being the leader. At the system runtime, the administrator can send a control message to the current leader, asking it to abdicate the role and to pass it to a specified agent in the system. Leader election often occurs when the current leader has to leave the system. The current implementation adopts a very simple algorithm: the agent aliases are

assumed to be lexicographically sortable, and the agent (other than the leaving leader) with the smallest alias is “elected” as the next leader. Note that the changing of leader can only take place when the system is not engaged in any global reasoning tasks. The process is illustrated

in Figure 5.2.

Figure 5.2: Changing of Leader

The main responsibilities of a leader include:

• deciding whether a new agent can join the existing system (see Agent-Joining Protocol) • handling the departure of an existing agent (see Agent-Leaving Protocol)

• deciding whether an existing agent can commit knowledge update (see Knowledge-Update Protocol)

• coordinating agent collaboration in a Global Abductive Task, e.g., receiving queries and aggregating solutions (see ST and WT executions).

Agent-Joining Protocol

When a new agent wishes to join the system, it first needs to report to the system leader, and then synchronise its advertisements with others if it is allowed to join the system. Upon receiving a joining request, the leader makes two checks: it makes sure that the new agent

alias does not clash with any existing agent’s alias, and that the system is not too busy (i.e., OngoingTasks > 0) to accept the new agent. If the two checks are passed, the leader will inform the new agent, and initiates the Directory synchronisation between all the agents. The

detailed protocol is shown in Figure 5.3

Figure 5.3: New Agent Joining the System

Agent-Leaving Protocol

Similar to the agent-joining protocol, any existing agent wishing to leave the system needs to report to the leader. However, the leaving agent does not need approval from the leader, as its departure may not be controllable by the leader (or any other agent) in the system. Upon receiving the agent departure signal message, the leader needs to check whether the system is engaged in any global reasoning task. If this is the case, in order to guarantee the consistency of the answers (for the tasks), an exception handling procedure must be invoked to cancel

any computation involving the leaving agent. In DAREC2 _{a global abductive answer must}

be involved at one time or another. Any computation of a global abductive task before the leaving agent actually gets involved does not need to be cancelled. However, identifying these computations can introduce computational overhead although it is easy to implement. In the current implementation, this procedure simply terminates any ongoing tasks, and informs the query issuer(s) about the computation failure due to changes to the system. The query issuer(s)

can then decide whether to query again. The detailed protocol is shown in Figure 5.4.

Figure 5.4: Existing Agent Leaving the System

It is worth pointing out that such an agent-leaving protocol can be used for implementing an agent failure (due to crashing or loss of communication connection) handling protocol:

• Each agent regularly pings others.

• If a no longer reachable non-leader agent is detected, the leader will be informed and will execute the agent-leaving protocol for the non-reachable agent.

• If the leader is no longer reachable (this is more serious), the leader election algorithm will be invoked (by the first agent who detects the leader failure), and the elected agent will execute the leaving protocol for the ex-leader.

Knowledge Update Protocol

Agents may update their local expertise at system runtime. However, such knowledge update must not occur when the system is engaged in any global task, in order to guarantee consistency.

Thus, each agent wishing to update its local expertise must first report to the leader, and the leader will check whether the system is busy. If there is no ongoing global task, then the leader will inform the requesting agent of the approval, so that it can commit the update. Note that the knowledge update request message may also contain the changes of the agent advertisements (e.g., what to add or delete). Thus, if the update request is approved, the leader will also inform all the agents to synchronise their Directory about the advertisement changes.

The detailed protocol is shown in Figure 5.5.

Figure 5.5: Update of Agent Knowledge