Scheduling in Holonic Manufacturing Systems
7.4 An Approach: the Fabricare Holonic System
7.4.4 A Prototype
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
The Configuration Designer allows specification of the resource holons in the factory plant, and to some extent, represents graphically the physical layout of the resources. The system description is read by the Deployment tool, which launches resource holons on the desired machines. Each resource holon is composed of a kernel and individual characteristics and behaviours specified in the holon script written in Prolog representing the “mental” state of the holon (e.g. resource’s agenda), as well as specific clauses for the Fabricare holon kernel (e.g. name).
The Control Panel is the interface to the system’s operation, monitoring and controlling running holons. This tool also allows the user to launch tasks (manufacturing orders) in the system by invoking the Task Launcher tool, which prompts the user for data about the order and dynamically creates a task holon for that order. One last tool in the suite is the Product Builder, which allows graphical generation of a product’s process plan. Each operation in a process plan corresponds to a parameterised invocation of a resources’ ability.
Additionally, there are the following support holons:
• Blackboard Server that allows the communication between holons via a shared tuple-space (i.e. shared memory);
• Directory Service Holon maintains an in-memory database of registered holons (their location and capabilities), acting as a yellow pages directory for the system, where each holon can advertise its functions and query for service providers;
• Process Planning Holon is responsible for providing information on a product’s process plans based on a set of selection criteria passed by the task holon and the current executing environment; the production plans for each product are read from the product database generated with the “Product Designer” tool; and
• Scheduling Holon maintains a list of negotiating resources and respective time windows to avoid negotiation conflicts.
SICStus PROLOG’s Linda coordination technology [7.52][7.53] is used for the Blackboard Server. Exchanged messages between task holons and resource holons are Prolog clauses written to and read from the Linda tuple-space. Each clause has identifiers indicating the origin and the destination holon, as well as a tag that makes it possible for each party to identify related messages.
The system is very dynamic in what concerns its holons, i.e. resource holons depend on the system description file; task holons depend on the existing tasks (dynamic events). Each negotiation uses the set of holons that are present and available at that time, thus giving the system a high degree of adaptability to the dynamic nature of the manufacturing arena (e.g. resource in maintenance or overloaded).
The holons are extended logic programs written in Prolog with the ability to handle negative and incomplete knowledge [7.44]. The decision procedure is not yet totally driven by this kind of knowledge; however, real-life scenarios where only partial information is available have been identified [7.44] and modelled (e.g.
resource holons will use this information to generate low-commitment schedules into their agendas).
The New Prototype System
We are currently migrating the Fabricare system to a new platform, in this case the Microsoft .Net 2.0 Framework and using the Microsoft Message Queuing (MSMQ) component of the windows operating system for asynchronous communications [7.54]. The main rationale for this migration is the use of a mainstream development environment instead of Prolog and Linda. Furthermore, the current version of the system uses synchronous communications that involved some tricks and timer-based pooling of messages, as well as a single centralised message board (tuple-space) for all the messages exchanged in the system.
The new implementation offers a more natural way to develop each holon, since each holon owns its own queue (which may be distributed) and the message handling is now done in an event-driven way, allowing the holon’s main thread to execute other operations and be interrupted only when a new message arrives.
The solution (Figure 7.10) is comprised of several projects that have been grouped according to their area of concern: kernel, user interface and management suite.
The kernel of the system has been divided into seven major projects:
• Agents – contains the agent/holon’s object model and interfaces for all the agents/holons in the system (i.e. task, resource, directory service, process planning and scheduling). It also defines the classes used by the notification mechanism for a holon’s lifecycle events.
• AgentsImplementation – contains the implementation of each service defined in an agent interface. These implementations are independent of the communication mechanism.
• Messages – contains the message’s data structures.
• MessageHandling – contains auxiliary classes for building and translating message contracts to agent contracts and vice versa.
• Communications – contains generic interfaces for abstracting the communication mechanism and allowing for the independent evolution/
substitution of the agent’s implementation and communication mechanism.
• Communications.Messaging – an actual implementation of a communication mechanism. In this case using the MSMQ component of the windows operation system.
The current user interface of the system is a simple console application (project Fabricare.Launcher) that is capable of executing the service corresponding to each holon role in the system: directory service; process planning; scheduling holon;
task holon; and resource holon.
In order to show some output and progress information to the user, a notification mechanism is used in which the application registers an event handler to output to the console.
The development of a new graphical user interface or the adaptation of the existing GUI applications to call the new kernel is still being considered. We think the latter approach will probably be taken since the GUI is not the main focus of our work. The adaptation of the existing code will need some wrapper classes to hide the differences between the Prolog representation and the new .Net representation (for
example, the resource’s agenda was returned as a string containing a Prolog list of tuples, while the new version returns a collection of AgendaEntry objects).
As a goal, it was decided at the outset that the system should be flexible to accommodate different communication mechanisms (or at least allow for an easy substation of the underlying communication mechanism). For the moment, we decided to use the MSMQ component of the windows operating system as it provides an asynchronous and reliable way for transmitting messages. The choice of using messaging instead of remoting was due (1) to the ease of use for asynchronous operation and (2) to the fact that the future Windows Communication Foundation subsystem of the .Net Framework will be based on the messaging paradigm (which makes messaging a more secure bet for future evolutions).
We factored out the functionality for low-level MSMQ interaction and the actual message processing in the MessageHandling project. A set of classes called message processors is defined as responsible for the translation of the message contract and agent contract and the routing of the message request to the actual object implementing the agent algorithm. These message processor objects are created by the MSMQ Service objects (e.g. ResourceHolonService). This allows for a reuse of this message-processing functionality independent of the actual communication mechanism in use.
Figure 7.10. Implemented projects for the new prototype