What you will build

In this Practical Session you will implement some basic mechanisms for interaction-centric coordination among agents. This implementation will enable agents to deal with delays in the tasks to build a house. You will program this multi-agent system, situated in a simple environment.

What you will need

Code

You can download the initial code from here

1. Preamble

In this practical session, you will have to design and implement a coordination process based on the communication among agents for dealing with delays during the building of a house.

The use case is the same as in the Agent-Centric Coordination. Thus, we assume that Client and Company agents have the same objectives. We also assume that the construction has started (i.e., the Contracting phase has ended) and one Company is allocated to each task. We will add a coordination mechanism for dealing with delays in the execution of the tasks (i.e., Execution phase).

In the initial implementation, two families of agents are defined. Here, we consider the same types of agents, but we deal only with the behavior related to the management of delays. We abstract away the actual action to construct the house.

Important
 The implementation of the agent types companyQX and clientQXy is part of the Practical Session.

2. Deliverable

Single document in PDF format containing the answers to the questions in the Practical Work Part I and Part II.

The document must be uploaded via eCampus (Assignment Interaction-Centric Coordination) no later than December 20, 2024 at 23h59.

The answers to the Part I and Part II questions are worth 10% of the total marks.

3. Interaction-Centric Coordination: Protocol Definition

We assume there is a delay limit for each type of task instead of a general delay time like in Part I.

Here, clients and companies adopt the FIPA-ACL Request Protocol (Figure 1) to coordinate their activities.

The company (i.e., the Initiator) send a request to the client (i.e., the Participant) for delaying the task. The client receives the delay request, which will be accepted or refused depending on the delay limit associated to the task. This task delay limit decreases after each new accepted request. If the delay is refused, then the contract between the company and the client is broken and the relation between the two agents is interrupted.

FIPA-ACL
Figure 1. FIPA-ACL Request Protocol

In the FIPA-ACL Request Protocol, the request interaction is translated to an achieve message, while all other interactions are translated to tell messages. Achieve means to complete the goal requestManagement(Action, Knowledge, Skill, Value) where:

  • Action is the nature of the requested action (e.g., update)

  • Knowledge is the name of the value that is related to the request (e.g., delay)

  • Skill is the name of the skill concerned by the request (e.g., plumbing)

  • Value is the name of the new value (e.g., 10)

This requestManagement plan generates a new goal depending of the content of the request received and reply to the requester agent with an agreement (agree message) if the agent’s skill is part of the tasks in the house building and the action is known by the client; this agreement just means that the request will be taken into account, but if the skill is not present then a refuse is sent (~agree message).

Finally, the client proceeds with the modification of the information. If the modification succeeds then a message inform_done is sent, otherwise a message failure is sent.

3.1. QUESTIONS

  1. What are the pros and cons of coordination with protocol? Consider

    1. the autonomy of the agents

    2. the openness of the system, i.e., agents entering and leaving the system.

3.2. [PRACTICAL WORK 2] Request Protocol

The request protocol implementation must be generic enough to consider other requests in addition to the request for updating the delay with the minimum of modification (see Q5).

Q1. Add the clientQ2.asl and companyQ2.asl in the project; update the MAS definition file (the client and company implementation) with the new agent types

Q2. Update the clientQ2.asl to handle the requestManagement(A,K,S,D) replying if it agrees or not with the update. To agree, the action, the knowledge, and the skill must exist in the client’s belief base.

Q3. Update the clientQ2.asl to decide to accept or not the update. The limit_delay should be updated if the value is greater than the current value. If updated, the agent sends a inform_done message to the company, otherwise it sends a failure message.

Q4. Update the companyQ2.asl to handle the inform_done and failure.

Q5. Implement the same thing to handle the update of penalities. Penalties are updated if the proposed value is less than the current value.