The Supply Chain Demonstrator is the first COOL setup related to the supply chain. It is a very simple setup. It is not meant as a model of a supply chain, but is implemented for the purpose of demonstrating the use of agents and conversation classes, as well as the COOL user interface. In this section the Supply Chain Demonstrator will be described in some detail, including state diagrams for some of the conversation classes. The objective is to give a first description of a COOL application.
The Customer agent is only involved in one conversation, the Customer Conversation. The customer agent transmits the orders to the logistics agent, which is the customer agent's only interlocutor. The customer agent will also accept or reject counter proposals that may come from Logistics, or it may transmit its own alternative orders in discussion with the logistics agent.
The logistics agent is the central player in the Supply Chain Demonstrator, communicating with all the other agents. It receives the orders from the customer agent and notifies it of the progress of the order processing. It decomposes the orders into tasks and schedules, finds contractors for, and monitors the execution of the tasks through conversations with the transportation and plant agents.
An example of a COOL definition of an agent, that of Logistics:
(def-agent LOGISTICS
conversation-classes (FIND-CONTRACTOR-CLASS
KICK-OFF-EXECUTION-CLASS
FORM-SMALL-TEAM-CLASS
FORM-LARGE-TEAM-CLASS
LOGISTICS-EXECUTION-NET)
conversations NIL
continuation-rules (CONT-0 CONT-1 CONT-2 CONT-3)
continuation-rules-incomplete NIL
continuation-control AGENT-CONTROL-KA
input-queue NIL
history NIL
)
The transportation agents decompose, schedule, and monitor the execution of the transportation tasks related to each order when asked by Logistics to participate in the order execution.
The plant agents decompose, schedule, and monitor the execution of the assembly and paint tasks related to each order. The Plant1 agent represents a painting facility, while the Plant2 agent represents an assembly line. (Plant3 is not currently in use.)
Figure: The customer-conversation
Table: Conversation Rules for the customer-conversation-class
The customer-conversation-class defines how Customer (agent) interacts with Logistics. The entire supply chain process starts with Customer sending an order proposal to Logistics (see CC-1, table 
). After sending the order, Customer is in state proposed where it may receive further questions from Logistics regarding the order. If there are no questions, Logistics will send a message informing that it is working on the order and the Customer will go to state working. In this state, Logistics may refuse the order (the Customer goes to final state rejected), accept it (Customer goes to accepted), or counter propose (Customer goes to counterp). In the accepted state, the Customer waits for Logistics to report success of execution (and goes to satisfied) or failure (going to failed). In the counterp state, the Customer may reject the latest counterproposal (and go to rejected) or propose something else (and go back to proposed). Also in counterp the Customer may ask questions about the latest proposal from Logistics and expect to get answers (state asked).
Figure shows the state diagram for the customer conversation class. Each arrow is given the rule number corresponding to the transition. The table in table shows the conditions for the rules to match, and the actions done when applied.
Figure: The Logistics protocol
Table: Converstion Rules for logistics-execution-net-class
The logistics-execution-net class defines how the logistics agent interacts with the other agents when decomposing, scheduling, finding executors, and monitoring the execution of an order. The process starts with the Customer agent sending a request for an order (according to customer-conversation shown above). Once Logistics receives the order, it goes to state order-received (see fig. ). There, it checks that the order is completely specified, in the sense that it contains all required information. If this is not the case, it will ask specific questions to Customer to fill in the missing parts. If this is not possible, the conversation ends (fail). When the order is complete, the conversation goes to the order-decomposed state. Here, Logistics tries to decompose it into activities like manufacturing, assembly, transportation, etc. and to determine which agents will execute these activities. This is done by running an embedded constraint based logistics scheduler. A rule attached on this state prepares an input file for the scheduler, runs it and then parses the produced output file to extract the activities required to complete the order and the agents that are supposed to carry them out (note that both activities and potential executors are determined by the logistics scheduler - for each activity there can be several potential executors). If this decomposition fails, Logistics will try to negotiate a slightly different contract with the Customer (by going to state alternative-needed). If decomposition succeeds, the protocol will go to contractors-ranked, and Logistics tries to form the team of contractors that will execute the activities. This is done in two stages.
First, a large team is formed. The large team contains all ranked contractors previously determined by the logistics scheduler that have expressed interest to participate by executing the activity determined previously by Logistics. Membership in the large team does not bind contractors to execute their activity, it only expresses their interest in doing the activity. If the large team was successfully formed (at least one contractor for each activity), the protocol goes to large team formed, and we move on to forming the small team (crn-9). This contains exactly one contractor per activity and implies commitment of the contractors to execute the activity. It also implies that contractors will behave cooperatively by informing Logistics as soon as they encounter a problem that makes it impossible for them to satisfy their commitment. In both stages, team forming is achieved by suspending the current conversation and spawning team forming conversations.
For example, in state contractors-ranked we form the large team by having Logistics start conversations with each contractor ranked for each activity, in the ranking order. First, the rule (crn-6) makes sure that the team forming conversation has not been already spawn. If this is the case, a new conversation named form-large-team-conv, of class form-large-team-class is created. Then the action in the rule marks team forming as taking place, initializes the result variable of the new conversation and transfers some data from the current conversation to the newly created one (this is how new conversations receive the data they need to operate). The transferred data consists of the list of ranked-contractors. The new form-large-team-conv conversation will contact each ranked contractor to inquire if they are willing to join the team (see form-large-team class section below). A :wait-for slot of the rule informs the system that the current conversation will be suspended, waiting for the named conversation to reach some state.
Forming the small team is similar, Logistics will discuss with each member of the large team until finding one contractor for each activity. In this case the negotiation between Logistics and each contractor is more complex in that we can have several rounds of proposals and counter-proposals before reaching an agreement. This is normal, because during these conversations contractual relations are established, while the large team forming conversations had the purpose of only expressing or confirming interest. How the dialogue between Logistics and each contractor takes place when forming the small team is illustrated in figure where we show the form-small-team-class conversation class used by Logistics and the answer-form-small-team-class conversation class used by the contractors.
If team forming is successful, then we resume the suspended main conversation and move to the next state. This is done by rules like that shown in figure . This particular rule, tried after the form-large-team-conv terminates, applies a test (in slot :waits-for-test) on the form-large-team-conv conversation. The test checks that the form-large-team-conv has produced the required team in one of its variables. There is a similar rule checking the formation of the small team.
Figure: Definition of rule CRN-7 of the logistics-execution-net class.
In the small-team-formed state we continue with other newly spawned conversations (according to the same pattern) with the team members to kick off execution. After having started execution (which every team member in part acknowledges), we move to state contractors-committed where Logistics monitors the activities of the contractors. If contractors exist that fail to complete their activity, Logistics will try to replace them with another contractor from the large team. The large team contains contractors that are interested in the activity and are willingly forming a reserve team, hence it is the right place to look for replacements of failed contractors. If replacements can not be found, Logistics tries to negotiate an alternative contract (alternative-needed) with the Customer. To do that, Logistics relaxes various constraints in the initial order (like dates, costs, amounts) and uses its scheduling tool to estimate feasibility. Then, it makes a new proposal to the Customer. Again, we may have a cycle of proposals and counter-proposals before a solution is agreed on. If such a solution is found, the protocol goes back to the order-received state and resumes execution as illustrated.
Figure shows the state diagram for the logistics-execution-net class. Each arrow is given the rule number corresponding to the transition. The table in table shows the conditions for the rules to match, and the actions performed when applied.
The form-large-team class defines Logistics' interactions with Transportation and Plants with the purpose of creating a large team of contractors (at least one contracted per task). In the start state, if Logistics has contacted all the contractors on the its contractor ranking list it will, if a large team is formed, move to ok, or if there is not at least one contractor for each task in the large team, go to failed. If there are contractors remaining on the list, Logistics will proposes the order to the first listed, and the protocol moves to the proposed state. In proposed Logistics my be asked for further information, and will answer with a tell: messages. Upon receiving an accept (flt-4: the contractor is added to the list) or reject (flt-3) from the contractor, the protocol goes back to start.
The answer-form-large-team class defines Transportations' and Plants' interaction with Logistics when requested to enter the large team. The conversation is created upon receiving an order proposal from Logistics with the intent of creating a large team, and the protocol goes to the proposed state. In the proposed state the agent may ask for more information, going to asked and returning to proposed when receiving the answer. It may accept the order, by sending an accept message and going to the accept state, or reject the order in the same way.
The form-small-team class defines Logistics' interactions with Transportation and Plants with the intent of creating a small team of contractors (exactly one contractor per task). The from-small-team protocol works much the same way as the form-large-team protocol described above. The difference being that when in the proposed state, a counterproposal might be received from the contractor. The protocol will then move to counterp. When in this state Logistics can the ask for more information (moving to asked), counterpropose (moving back to proposed, reject (fst-7; moving to start), or accept (fst-8; moving to start, contractor entering the team).
Figure: Conversation classes for forming the small team
The answer-form-small-team class defines Transportations' and Plants' interaction with Logistics when requested to enter the small team. The start of the protocol is analogous to that of answer-form-large-team above. When in proposed the contractor will try to schedule the received order. If the scheduling is a success, an accept message is sent to Logistics and the protocol moves to accepted. If the scheduling does not succeed, the contractor may send a reject message, moving to reject, or send a counterproposal, moving to counterp. In counterp the contractor is waiting for a message from Logistics. Upon receiving accept it will move to accepted and join the small team for the current job, if it receives reject the protocol will move to rejected, and upon a counterproposal the protocol will go back to proposed. Logistics can also ask for more information in which case the contractor will return a tell: message, and the protocol will stay in counterp.
In the kick-off-execution class Logistics requests each contractor in the small team to start execution. The contractor, each creating an answer-kick-off-execution conversation, answers with "started" or "failed" and the protocol goes to the corresponding state. The kick-off-execution protocol will go to failed if a "failed" message is received, if not it will return to start, and go to end when the whole team has answered.
The monitor-execution-class is created by the contractors when either the execution is finished or an error occurs in the execution. The protocol has the three states start, ok, and failed. The contractor sends a satisfy or fail message to Logistics and moves to the corresponding state.
The find-contractor-class is used by Logistics to find a new contractor if one of the contractors failed in executing its task. First, Logistics tries to find an appropriate contractor from the large team. If such a contractor exists, a proposal to join the small team is sent to it (going to state proposed). The contractor may accept (going to state ok), counter propose (going to state counterp) or reject (in which case Logistics goes back to start where it takes the next candidate from the large team). Clarification dialogues are allowed in two places to allow each side to ask questions. If no member of the large team accepts, the conversation fails (in state failed). To respond to this conversation class, contractors use the answer-form-small-team-class conversation class, because this is a small team forming interaction.
When a message is sent a trace of the message is saved to a file. As an example we consider the rule fst-1 as defined in figure . The :transmit slot in the rule transmits a propose message for a plant or transport agent with the intention of forming a small team. Figure shows an example of a trace saved when the rule is executed, and a message is sent. In the trace we recognize the all the slots of the message pattern defined in fst-1. The variables ?agent, ?current-agent, ?current-activity, and ?convn are replaced by their values.
Figure: Definition of rule FST-1 of the form-small-team-class.
Figure: Trace recorded when message in fst-1 is sent.
Figure: Simplified illustration of information exchange in the demonstrator.
Figure illustrates the most important flows of information among the agents. Customer sends a customer order to Logistics, and get back acknowledgment messages, which can be accept or reject. Logistics can also counterpropose or ask for more information. The same messages go between Logistics and the transportation and plant agents. Only the order proposals and counter proposals contain any supply chain information (i.e. product, quantities, dates, destinations, etc.). The information content of the customer orders can be seen in the :content slot of figure .