Scheduling in Holonic Manufacturing Systems
7.4 An Approach: the Fabricare Holonic System
7.4.3 Negotiation Protocol
The objective of a resource holon is to control the physical equipment, provide information about its abilities and status to the system and manage the scheduled activities. Its lifecycle is very long, since it is expected that a resource is fully operational for long periods of time. During its existence, the resource holon executes the commands sent by the resource controller and negotiates with task holons the scheduling of manufacturing orders.
During initialisation, the holon builds its initial agenda, registers in the directory service and joins the several holarchies it belongs to (e.g. scheduling, process planning). The negotiation process of the holon is guided by the execution of the CNCPP state machine (Figure 7.5) for each conversation currently taking place with task holons. Upon receipt of a service request (for the possible execution of one or more operations), the resource holon will check its availability and engage in negotiation with other resource holons for propagating constraints between the operations. After calculating its feasible intervals for each request, it will send a bid and wait for the task holon’s reply (accept or decline). There is a cost mechanism associated with operations and resources such that a resource holon replies to a task holon with a bid specifying the price (in abstract units) of performing that operation.
start
wait FW E
end A
F
check FW
wait BK
I J
check BK
wait answer
C B
H
K G
L
N M
D
Figure 7.5. State diagram of a resource holon for one negotiation
holons will use constraint propagation in order to guarantee the relationships among different operations that aim at the same task. This new protocol is called Contract Net with Constraint Propagation Protocol (CNCPP) [7.45][7.46].
First, when a new task arrives at the system (via task launcher), it will obtain information from the process planning holon about the product’s alternative plans and will choose one based on a set of criteria given by the scheduling holon based on the plant current status. The task holon will then announce the job by broadcasting each individual operation to every holon able to perform that operation.
This information is obtained by querying the directory service, thus the set of resources participating in a specific negotiation is built at runtime considering the available resources at that specific moment. This gives the system a certain degree of dynamism in what concerns the system’s geometry (number and type of running holons).
After receiving a request, each resource holon will be “forward influenced” by its predecessors and will forward influence its successors. Likewise, each resource holon will be backward influenced before making its bid, and will backward influence its predecessors. The forward- and backward-influence operations make adjustments to the beginning and end of each resource’s agenda of free-time intervals in accordance with the agenda of predecessor and successor resources; i.e.
remove from the list of free time intervals that overlap with busy intervals (for the same order) of other resources [7.51]. The set of resources participating in a specific negotiation is built at the beginning of that negotiation by the task holon. If new resource holons are added to the system they will not be considered for running negotiations but will enter future ones.
Figure 7.6 shows the messages exchanged, during forward influence, for a process plan with 3 operations done in sequence using different resources for each operation and having an alternative resource for the first operation.
Resource A1
Resource A2
Resource C Resource
B Forward influence (A1)
Forward influence (A2)
Forward influence (A1-B)
Forward Influence (A2-B)
Figure 7.6. Forward influence
The sequence of steps performed by a resource holon is: (i) analyse its agenda and determine free-time windows to execute that operation; (ii) wait for a “forward influence” from predecessor resources and use that information to eliminate time windows and adjust the lower limit of other time windows in order to cope with precedence relationships; (iii) send that new list of time windows to the successor resources; (iv) wait for a “backward influence” from successor resources in order to
adjust the upper limit of its time windows; (v) send this final list (the resource’s bid) to predecessor resources and present a bid to the task holon (containing the list of free-time intervals and the cost of performing that operation).
Each resource is able to make a final bid (feasible in its own agenda and respecting the constraints) to the task holon. If there are alternative resources, a bid is made for every combination. Figure 7.7 shows the backward-influence and bidding phases of the protocol.
Resource A1
Task Bid (A1-B-C)
Resource A2
Resource C Resource
B Bid (A2-B-C)
Bid (A1-B-C)
Bid (A1-B-C)
Backward influence (A1-B-C)
Backward influence (A2-B-C) Backward influence (A1-B-C)
Bid (A2-B-C)
Bid (A2-B-C)
Backward influence (A2-B-C)
Figure 7.7. Backward influence and bidding
After receiving all the bids from resource holons, the task holon will evaluate them. The evaluation of bids is performed by taking into account a prioritised list of criteria. The following criteria have been implemented: first valid solution; least- costly solution; and greatest slack until due date. The cost of a solution is determined by the cost of performing the specified operations in a specific resource.
Since multiple tasks can be negotiated at the same time, conflicts may arise if some resources are used in the same time interval for different tasks. In these scenarios, resource holons have an indecision problem [7.45] since they cannot guarantee the delivery of both tasks. In order to overcome this problem, a solution is proposed that involves a pre-negotiation step in the protocol (Figure 7.8). Before starting negotiation, each task holon will ask for authorisation from the scheduling holon, which maintains a list of negotiating resources and respective time windows.
Only in the case of non-overlapping, will a “green light” be given to the negotiation.
The system is prepared for overlapping functionality on the resource holons, i.e.
different resource holons can perform the same operation (e.g. drill). A task holon will receive the production plan for a product with an indication of the necessary operations, and will request them to every resource holon able to perform each operation. This causes a combinatorial explosion in the number of exchanged messages between holons (with a O(rn) complexity, where r is the number of resources and n the number of operations). To decrease the number of messages, a modification was made in the protocol, in which combinations from predecessor resources are clustered before sending them to successor resources [7.49], thus
changing the complexity of the problem to class O(n), which respects the number of exchanged messages. However, the problem of a combinatorial explosion in the search space still exists (possible solutions for this problem are being addressed).
The same protocol can be used for renegotiating the task in the case of machine breakdowns or other unexpected events. In that case, the task holon will be informed by the resource holon where the event originated, and will begin negotiations for the operation(s) previously contracted to that resource with other resource holons following the same steps previously described. At this time, if rescheduling is not possible, the task will be completely abandoned, and a manual scheduling of that task must be engaged.
Scheduling Task
launcher Task Process
planning Task announcement (1)
Resource list (4)
Green light (5)
Get plans (2)
Plan (3)
Figure 7.8. Avoiding conflicts in CNCPP