SCHEDULE EXECUTION FOR A HOLONIC SHOP FLOOR CONTROL SYSTEM
Luc Bongaerts, Paul Valckenaers, Hendrik Van Brussel, Jo Wyns Preprints of the Advanced Summer Institute (ASI) 95 of the N.O.E. on Intelligent Control of Integrated Manufacturing Systems, Lisboa, Portugal, 24-28/6/95
SCHEDULE EXECUTION FOR A HOLONIC SHOP FLOOR CONTROL SYSTEM
Luc Bongaerts, Paul Valckenaers, Hendrik Van Brussel, Jo Wyns Katholieke Universiteit Leuven Mechanical Engineering Department Celestijnenlaan 300B B-3001 Leuven, Belgium tel: 32-16-32 24 80 ; fax: 32-16-32 29 87 e-mail:
[email protected]
Abstract: The control structure of a traditional shop floor control system (SFCS) is built according to a strict multi-level hierarchy. Such a SFCS is very rigid and does not support evolution nor adaptation to the factory needs. Holonic manufacturing is a new approach to deal with these problems. A holonic manufacturing system is a highly decentralised system consisting of co-operative, intelligent, autonomous modules, called 'holons', that together yield an agile and self-organising manufacturing system and support global optimisation. This paper presents a holonic architecture for a SFCS. The architecture supports the use of several control strategies, like hierarchical control, heterarchical control and other holonic control strategies. These intermediate strategies are based on a tight cooperation between scheduler and SFC holon. It is shown that a Gantt chart does not contain sufficient information to execute a schedule while being subject to disturbances. Using partial derivatives of the objective functions to the disturbances, the SFC holon can autonomously react to disturbances while considering global performance. Keywords:
Holonic manufacturing, shop floor control, holonic architecture, reactive scheduling
1. Introduction Problems of CIM When flexible automation entered the manufacturing world, automation was done by replacing the human activities such as shop floor control and scheduling by their automated counterparts. The introduction of CIM in manufacturing was performed via a traditional hierarchical approach. It was believed that CIM would increase flexibility and cost efficiency. However, the hierarchical approach towards shop floor control turns out to be very rigid. As such it cannot satisfactorily cope with new requirements for manufacturing systems as reconfigurability and ability to adapt to disturbances. These abilities are however necessary to support a high variability of products in a manufacturing system, which is identified to be one of the major requirements for next-generation manufacturing systems [VVB+94a]. Current manufacturing technology only works well within a very strict set of conditions. System performance drops drastically and abruptly when these conditions are not met. These problems are even more relevant for the complex CIM-subsystems, such as shop floor control and scheduling.
What is Shop Floor Control? One of the major tasks of a shop floor control system (SFCS) is the execution of a given schedule. Given the order data, the schedule, the product structure and the NC-programs, and having a set of workstations, operators, transport systems and materials at its service, the shop floor control system should make sure all work is executed according to schedule. Meanwhile it has to perform resource management and monitoring and take care of disturbances. Since the manufacturing model used by the scheduler often has only a limited amount of detail, the schedule cannot contain all decisions that have to be made. Therefore the SFCS has to make additional resource allocation decisions. E.g., while schedulers sometimes neglect transportation and/or set-up issues, the shop floor control should maintain consistency in the shop with respect to transportation and set-up.
Problems of Scheduling and Shop Floor Control It is widely understood that there exists a wide gap between scheduling research in the operations research and AI communities on the one hand, and the industrial reality on the other hand [Par91]. Consequently, current approaches to automate the shop floor control and the scheduling process have been quite unsuccessful, for similar reasons as CIM in general has had its problems.
More specifically, the computational complexity of scheduling ‘as such’ has been the primary challenge for researchers during several years. Yet, it has always been difficult to provide a near-optimal schedule on-line. This has pushed research towards the development of faster scheduling algorithms. However, in industry, high performance schedulers currently are hardly used, due to the lack of schedule robustness. When a near-optimal, offline calculated schedule is executed on the shop floor, several disturbances occur. It turns out that the performance of a schedule is very sensible to these disturbances and it is difficult to execute that schedule [Par91]. Investigations in industry have show that 20% to 30% of work is done on other equipment than was originally planned [LSD91]. Therefore, several researchers suggest approaches to bypass the problems of reactivity to disturbances, at the cost of lower performance, e.g., by using heterarchical control [DBW91]. Other researchers are focusing on reactive scheduling. Often they focus on the use of fast scheduling algorithms, e.g., in the extreme case, dispatching rules. More intelligent approaches try to find out how the schedule can be adapted to the feedback of the shop floor, e.g. [KG81] proposed an explicit dynamic formulation of the flow shop scheduling problem; [BSH92] use a rolling scheduling horizon approach; [KCM92] use combine feed-back and feed-forward; [LC94] use Lagrangian Relaxation. In general, there is a trade-off between the performance that a scheduler can give and the reactivity of the system to disturbances. Moreover, this trade-off is very dependent on the specific manufacturing system and its state. This trade-off is reflected in the control architecture of the SFCS, which is traditionally built according to a strict multi-level hierarchy. Such a SFCS turns out to be very rigid. The evolution of the SFCS to comply with the changing company needs is hardly supported and very expensive. The adaptation of the SFCS to the situation on the shop floor is not supported either. Many factories use MRP or MRP-II systems to create a medium-range schedule [Chr92] [BBR+91] [RNS93]. MRP systems’ major disadvantages are rigidity and the lack of feedback from the shop floor, but also the tremendous amount of data that have to be entered in the bill of materials and the fact that the model of the manufacturing system and its capacity are excessively simple [Par91]. For the execution of an MRP-schedule, several approaches are used. Often the MRP system is linked with an automated warehousing and transportation system. The control software for warehousing can under certain conditions be used as a tool for control of the shop floor. Sometimes, the MRP-schedule is executed by printing out all orders for transport jobs and the assembly job list for each machine, on a daily basis. This can be partially automated by self-developed software on an ad-hoc basis. However, the system still is for a large amount operated by humans. Another approach, that also relies on humans for the generation of the schedules, is the use of “leitstand” schedulers. Leitstand schedulers are a collection of graphic toolboxes and GUIs to assist human schedulers. These solutions work, but are sub-optimal, expensive and very hard to change.
Paper Overview To solve these problems, a new approach for the design and operation of the next century manufacturing systems is proposed: holonic manufacturing. A holonic manufacturing system is a highly decentralised manufacturing system consisting of co-operative, intelligent, autonomous modules. The concept of holonic manufacturing is further elaborated in section 2. Section 3 will apply these concepts to shop floor control. This section will present a holonic shop floor control architecture. This architecture considers workstations, transport, orders, scheduling and shop floor control. Section 4 will elaborate how this architecture can be used to obtain holonic behaviour. It shows that hierarchical control and heterarchical behaviour are both possible in a holonic system. Moreover, intermediate control scenarios can be applied and can yield additional benefits in certain situations. The conclusion is that for holonic manufacturing, an architecture is not fixed during the life cycle of a manufacturing system, but is dynamically adapted throughout the life cycle of the manufacturing system. Holonic manufacturing system components and subsystems can even extend beyond the life cycle of the manufacturing system as a whole.
2. Holonic Manufacturing Systems Holonic manufacturing is a paradigm developed in the framework of the Intelligent Manufacturing Systems (IMS) programme. The goal of IMS is the creation a manufacturing science that can meet the needs of the next century. In a feasibility study [VVB+94a], conducted in 1994, six test cases were considered, one of which was ‘Holonic Manufacturing Systems: system components of autonomous modules and their distributed control,' HMS. In compliance with IMS goals, the HMS project aims at a better understanding of the requirements for future generation manufacturing systems and at ways to build systems satisfying these requirements. From the outset, the concept of “holonic systems” has been put forward as the paradigm likely to lead toward this goal. Therefore, a clarification of this concept is given below.
2.1. Historical background Some 25 years ago, Arthur Koestler proposed the word “holon” [Koe89]. It is a combination from the Greek holos = whole, with the suffix on which, as in proton or neutron, suggests a particle or part. Two observations impelled Koestler to propose the concept of holon. The first comes from Herbert Simon and is based on his ‘parable of the two watchmakers’ [Sim90]. From this parable, Simon concludes that complex systems will evolve from simple systems much more rapidly if there are stable intermediate forms than if there are not; the resulting complex systems in the former case will be hierarchic. The second observation, made by Koestler while analysing hierarchies and stable intermediate forms in living organisms and social organisation, is that—although it is easy to identify sub-wholes or parts—‘wholes’ and ‘parts’ in an absolute sense do not exist anywhere. This made Koestler propose the word holon to describe the hybrid nature of sub-wholes/parts in real-life systems; holons simultaneously are self-contained wholes to their subordinated parts, and dependent parts when seen from the inverse direction. Koestler also establishes the link between holons and the watchmakers’ parable from Simon. He points out that the sub-wholes/holons are autonomous self-reliant units, which have a degree of independence and handle contingencies without asking higher authorities for instructions. Simultaneously, holons are subject to control from (multiple) higher authorities. The first property ensures that holons are stable forms, which survive disturbances. The latter property signifies that they are intermediate forms, which provide the proper functionality for the bigger whole. Finally, Koestler defines a holarchy as a hierarchy of self-regulating holons which function (a) as autonomous wholes in supra-ordination to their parts, (b) as dependent parts in sub-ordination to controls on higher levels, (c) in coordination with their local environment.
2.2. Holonic manufacturing systems The HMS consortium translated the concepts that Koestler developed for social organisations and living organisms into a set of appropriate concepts for manufacturing industries. The goal is to attain in manufacturing the benefits that holonic organisation provides to living organisms and societies, i.e., stability in the face of disturbances, adaptability and flexibility in the face of change, and efficient use of available resources. The HMS concept combines the best features of hierarchical and heterarchical organisation [DBW91]. It preserves the stability of hierarchy while providing the dynamic flexibility of heterarchy. The HMS consortium developed the following list of definitions to help understand and guide the translation of holonic concepts into a manufacturing setting: • Hol on : An autonomous and co-operative building block of a manufacturing system for transforming, transporting, storing and/or validating information and physical objects. The holon consists of an information processing part and often a physical processing part. A holon can be part of another holon. • Aut on om y: The capability of an entity to create and control the execution of its own plans and/or strategies. • Co-oper a t i on : A process whereby a set of entities develops mutually acceptable plans and executes these plans. • Hol a r ch y: A system of holons that can co-operate to achieve a goal or objective. The holarchy defines the basic rules for co-operation of the holons and thereby limits their autonomy. • Hol on i c m a n ufa ct ur i n g syst em : a holarchy that integrates the entire range of manufacturing activities from order booking through design, production, and marketing to realise the agile manufacturing enterprise. • Hol on i c a t t r i but es: attributes of an entity that make it a holon. The minimum set is autonomy and co-operativeness. Using these concepts and definitions, we have applied the holonic manufacturing paradigm to the development of an architecture for a shop floor control system. The architecture presented in this paper should be considered as an implementation architecture, not as a holonic reference architecture. However, it guides us in the development of a holonic reference architecture, currently being done. To fully support the system evolution, the architecture itself shall be subject to change. The architecture is a framework to describe how the system is composed of its building blocks. As such, by rearranging the building blocks (not only in the architecture, but also the implementation of the building blocks), the system can evolve to meet the future needs of the company. A holonic implementation architecture should be considered more as a temporal configuration of the system than as the initial blue print of the manufacturing system, limiting its future evolution.
3. A Holonic Shop Floor Control Architecture 3.1 Requirements To build a holonic architecture for a shop floor control system, the following requirements have to be considered. First, the holons in the system shall be autonomous modules. This means that all holons should have a clear function and responsibility. Very often, a holon also has a hardware part, which makes it easier to define modules. This also means that it shall be possible that each holon is developed, built and tested by a separate vendor. During the development phase, it is not known which other holons this holon will co-operate with. Yet the holon should be plugand-play compatible when entering its future system. It also means that the holon can work on a more or less standalone basis, in other words, in a non-holonic system. Second, the holons shall be co-operative. This abstract principle is translated in some basic guidelines for manufacturing. A holonic system shall be able to work as well in a rather hierarchical as in a rather heterarchical environment. In a complex system, some kind of hierarchy is often needed. Moreover, when disturbances are quite low and well-controlled, traditional hierarchical systems obtain a high performance. There is no need to avoid hierarchical behaviour if this yields the best results. If disturbances are very frequent and resources are abundant and homogeneous, heterarchical control works very well. There is no need to avoid heterarchical behaviour either if this yields best results. A holon should contain the abilities needed to perform its duty in as well hierarchical as heterarchical environments. Moreover, for intermediate situations, there will also be a need for intermediate behaviours. It should be a straightforward task to adapt an existing holon for an intermediate situation. For shop floor control, this means that the holonic architecture should support hybrid hierarchical-heterarchical strategies, as described in [VBV+94]. Third, to provide a flexible co-operation schema, a holonic architecture shall support multiple hierarchies. In a strict hierarchy, each parent node can have several child nodes, but each child node can only have one parent node, such that the architecture gets very rigid. If nodes are allowed to belong to multiple hierarchies, parallel control channels can be added as needed, without taking away the child nodes of other holons. However, additional mechanisms shall be constructed to account for the fact that a holon is subject to commands from several other holons. This may include time multiplexing (different holons to obey over time), space multiplexing (different places to operate over time), and functional multiplexing (different functions to perform over time). Fourth, a holonic architecture shall support self-reconfigurability. This means not only that the architecture can be hierarchical or heterarchical, but also that an entire spectrum of new architectures is possible. The architecture supports its own evolution, both on long term, to adapt to the evolution of the system, as on short term, to adapt to the situation on the shop floor.
3.2 General overview of the architecture The architecture we present here, is focused around the schedule execution aspect of a shop floor control system (Figure 1.). It consists of a set of holons, that can be developed independently, and afterwards work together in a flexible self-organised hierarchy. Due to this bottom-up approach, an object oriented approach is a good starting point to identify and develop the holons in the architecture. Moreover, it is possible to focus on one aspect of the problem only: the schedule execution problem. This implies a set of requirements for each holon. Other aspects, such as maintenance or data captation, are considered by other architectures. Thereafter, for each holon, a set of requirements will exist, coming forth from different architectures. Using these requirements, the holons can be further designed and implemented.
Figure 1: Holonic shop floor control architecture.
Figure 1 presents the shop floor control holon, surrounded by scheduler holons, order holons, workstation holons, and a transport system holon. This figure only shows the interactions between the shop floor control holon and the other holons. Interactions among other holons themselves exist, but are not shown. As an example, the figure also shows a possible internal structure of the shop floor control holon. Important aspects are modelling of neighbour holons, the operation of the system and monitoring. First, the holon needs a model of its surrounding holons. Therefore, holons have to register themselves with the shop floor control holon. Second, resources like a workstation and a transport system notify the shop floor control holon when they have spare production capacity. The order holons request production capacity via the ‘Request Manufacturing’ interface. The function of the shop floor control holon is to match the requests of the orders with the offers of the resources on a certain instance of time. The SFC holon therefore uses the schedules it receives regularly from one or more schedulers. Orders and resources are not obliged to wait with their requests and offers until the operation is executable or the resource is free. This enables the holons to foresee future events and consider the consequences of it. This will be used to have, e.g., an idle workstation waiting for an important order, even when work is available. This can also be used to have a workstation setting up for a certain operation when the order has not arrived in the workstation yet. Due to disturbances, the SFC holon has to take its own decisions to execute a schedule. Therefore it has to combine the information given by the schedules with the most recent feedback it gets from the resources and the orders. One may notice that the shop floor control also needs to perform monitoring. This requirement is present of course, but the holonic concept allows focusing on one of the aspects at a time, and temporarily neglect other aspects.
3.3. Holon Description Workstation holon The architecture presented above imposes some constraints on the workstation holon. First, every holon in general contains a continuously running computer process, able to control its own hardware devices and software tasks. As such, it is connected via a communication network with all holons. Holons use the network to exchange messages. For this, e.g., the Manufacturing Message Specification (M.M.S.) protocol could be used. However, every holon needs to be able to be as well an MMS-client as an MMS-server. This reflects the basic properties of a holon, namely the autonomy to be a client and the co-operation provided by being a server. For executing a schedule, the workstation holon has additional requirements. It needs to register itself with the shop floor control holon. Further on, it shall inform the SFC holon when it is available, occupied, or unavailable in the (near) future. When it becomes available again, it notifies this event to the SFC holon. Moreover, it shall also support information services to the SFC holon. The SFC holon can explicitly ask for the availability of the workstation. It can also subscribe to an event notification list to be notified when other events occur, e.g., feeder jamming and an operation that gets unavailable.
The SFC holon, considering all available information, will allocate a workstation to a task. It will inform both the workstation and the order requesting that task. The order holon and the workstation holon will then autonomously settle the details of the task to be executed. This includes setting up the workstation, co-ordinating their activities in time, loading the necessary auxiliary resources and exchanging information like NC-programs. The workstation in principle has the possibility to reschedule the tasks. This can be done to account for small deviations in the predicted processing time; to react to resource breakdowns; or to optimise set-ups that have not been foreseen in sufficient detail on higher levels. The degree to which this autonomy is allowed is determined in the holarchy configuration. For the monitoring function of the SFC holon, it shall perform some additional activities, but these are not considered in this paper.
Transport system holon The transport system holon has a similar role as a workstation holon. However, some significant differences appear. First, the transport system holon often is a complex multi-holon system itself. It has its own management, and usually the internal transportation issues are shielded from the order holon. The clients (order and SFC holon) will ask for transportation from one workstation to another one, but will not know the route taken or the AGV’s used. This problem up to now has got little attention in the research community. A rare exception is [Bus94]. For a workstation, the order holon can give reasonably detailed commands. Instead for a transport system, the order holon has to give aggregated commands to the transport system holon, e.g., “Move order A towards workstation W, preferably before time t”, or “Move order A and B towards workstation W, but A must be there before B”. Second, due to the fact that multiple transportation resources exist, the way in which a transport system holon communicates its capacity is different from the way a workstation does it. A workstation holon thinks in terms of idle periods and busy periods. The information about the capacity of a transport system holon is communicated in terms like: “When can this order reach that machine?” or “Can this assembly reach that workstation before that order?”, etc. Third, since the transport system is already complex by itself, often it will not or not in sufficient detail be scheduled by the scheduling holon itself. This means activities have to be executed which are not explicitly scheduled. Since the route of an order is highly dependent of the scheduling decisions, the order holon cannot foresee the transportation issues either. Therefore, the shop floor control holon should provide the necessary data to the order holon such that the order holon can negotiate in a proper way with the transport system holon.
Order holons In a holonic manufacturing system, it is essential that an order is an autonomous entity. An order is the best representation of the requirements of the client. Moreover, a lot of manufacturing constraints arise from the order. First, it defines the product to be made. Second, it collects all manufacturing data necessary for this order. Third, it manages the precedence constraints between all operations of an order. Notice that different orders can support different models of their precedence constraints, like simply a sequence, or a precedence graph, or a Petri net. Fourth, it contains the order objective, like due date and importance. As a holon, the order holon should provide services to its peer holons and be able to autonomously perform actions. The order holon shall provide information about the order status on request. It also shall support event subscription lists. The order holon shall follow up all events related to the order and, if necessary, take initiative by itself. The order holon registers itself with the scheduling holons and the SFC holon, and requests manufacturing. For every task, the order will request for resource allocation to the shop floor control holon and the SFC holon will then match order and resources. Then order and resource holons will autonomously negotiate about the further finishing of their task. The order requests resources only if previous tasks have been executed. However, it can also do pre-requests to ask for resource reservations. This combines the ability to execute a near-optimal schedule together with the ability to react to disturbances. To execute a schedule, resources sometimes have to wait till an order gets ready. To react to disturbances, it cannot be allowed that resources wait for orders without making any distinction. Therefore, reservations are only possible for order holons if they give and update estimates of the precise time when the resources will be used. If order holons are provided with sufficient intelligence, it is possible in principle to work without shop floor control and without scheduler, and negotiate for its own resources. However, in this way the only possible shop floor control strategy left is heterarchical control.
Scheduling holons The shop floor control holon is an on-line control system and cannot perform optimisation in an appropriate way. Optimisation of an NP-complete problem is to be done by a scheduler. A scheduler needs a specific model of the
manufacturing system, which usually is a substantial simplification of the reality. Often, different aspects of the manufacturing process are optimised by different schedulers. E.g., on a high level, a job shop scheduler optimises the schedule on an overall basis. At the same time, maintenance is scheduled separately. Specific aspects for some machines or shops, like set-up and transportation times, are scheduled by dedicated schedulers on very-short timehorizon. They will probably co-operate with each other, but that is out of scope for this paper. Each scheduler delivers its schedules to the shop floor control holon. Moreover, these scheduler holons are processes that continuously improve their schedule. They adapt themselves to the manufacturing situation on an event-driven basis. This requires that the schedulers are more than implementations of an algorithm. They require a reactive encapsulation of the algorithm, that reads feedback, adapts the scheduling problem according to the feedback, performs scheduling, using the results of the previous schedule and sends the schedule to the SFC holon and continues its work. This implies that parameters of the scheduling algorithm, as well as parameters of the reactive encapsulation (e.g., the calculation time, the identification and filtering of events, etc.) are adapted automatically to the situation on the shop floor.
Shop floor control holon The previous subsections have described the holons the shop floor control holon co-operates with. A possible internal structure of the shop floor control holon is also presented in figure 1. Four functions can be derived from it: holon registration, holon interfaces, the core functionality, and monitoring. To co-operate with other holons, a holon needs to have a model of its surrounding holons. Basic attributes of other holons to be known are the very existence of them and how to contact them (their ‘address’). More elaborate models for other holons are subject to current research. These models are transferred between holons by registration. Second, communication with other holons needs to be flexible. Therefore, the SFC holon is continuously accessible via interface agents. For the resource holons, this interface agent accepts work requests. For order holons, this interface agent accepts manufacturing requests. For scheduler holons, this interface agent reads schedules. The core functionality of the shop floor control holon (with respect to schedule execution) is then to allocate resources to activities asked for by the order holons. The decisions the shop floor organiser takes, are based on the schedule and the current manufacturing situation. Once a decision is made, it is communicated to the resources as well as to the order holons. These resource and order holons will from then on autonomously perform the activities asked for by the SFC holon. When finished, they report back to the interface agents to continue their work. Monitoring takes care of special cases, when either the resources or the order holon does not behave as expected. However, monitoring is not the focus of this paper. The internal layout of the SFC holon, presented in figure 1, is an operational specification. In other words, it is only one example of how this holon could look like, and other implementations of the same functions can perform the job quite well. It is certainly necessary to provide the SFC holon with multiple registration and interface agents, if the number of resources or orders rises. Then, the shop floor organiser will also be distributed over several computers. However, the basic ideas and the interface remain the same.
3.4 Strategies One of the strengths of this architecture is the fact that it supports different strategies to execute a schedule. A strict hierarchical strategy consists in following the scheduled sequence of operations exactly. Strictly hierarchical strategies are useful if the amount of disturbances is low. A fully heterarchical control strategy would totally neglect the schedule and organise a bidding system to allocate workstations to operations of orders. Strictly heterarchical strategies are useful if the amount of disturbances is high. However, the holonic architecture can be fully exploited when intermediate strategies are needed, namely when a medium amount of disturbances occur. The next section shows how the organiser in the SFC holon can work for different control strategies, and how these different strategies can be combined in this architecture. It will also enable the system to work without scheduler, or with multiple schedulers.
4. Holonic Schedule Execution 4.1. Hierarchical Control The architecture presented in this paper supports hierarchical control. Using this control strategy, the shop floor control holon precisely follows the sequence of tasks prescribed by the scheduler. When necessary, the SFC holon waits for the necessary production resources to become available or for an operator intervention to restore the system such that it can continue along this prescribed schedule.
Therefore, the workstation holons and order holons are obliged to report to the SFC holon and wait until they get permission to continue. This permission will be given when the requested activity is the next activity scheduled on both the workstation schedule and the order schedule. Notice that hierarchical control only allows for one scheduler. This means that the scheduler must take into account all aspects of the manufacturing system for optimisation of the production. Aspects that are neglected, e.g., transportation times, are not scheduled at all. Then, the order holon should take completely autonomous action to get itself transported to the right workstation. If the amount of disturbances is low, hierarchical control follows a given schedule and provides good performance. It also yields a quite predictable performance. However, the performance is very dependent on the scheduler. Moreover, if disturbances occur more frequently, the performance drops rapidly because the SFC holon cannot react to it without consulting the scheduler. Numerical results of this behaviour are presented in [VBV+94].
4.2. Heterarchical Control The fragility of off-line generated schedules prompted the development of heterarchical control. In heterarchical control, all decisions are made by autonomous agents. For shop floor control, this means that each workstation has its own set of agents that manages the local production activities independently. Orders select a workstation for a specific activity by requesting for offers. The workstation with the cheapest offer is selected. The offer given by the workstation is based on local information. The offer can include as well a cost element as an expected finishing time for the activity. When the order selects a workstation to execute the operation of the order, the workstation schedules it in its list of activities. Any available schedules are totally ignored. This control strategy is very similar to the use of dispatching rules for scheduling. The architecture presented in this paper supports such a control strategy. The order holons and the resource holons can behave as described above. The shop floor control holon can be considered as the market place where order holons and workstation holons meet. An example of this strategy is described in [VBV+94] and compared with hierarchical control. The resulting behaviour is opportunistic. It allows the use of all possible alternatives to face any situation. When perturbations occur, the system accepts them and adapts automatically to the new conditions. However, there is no global optimisation and the system can reach, under specific circumstances, some ‘unstable’ states, where the responses to a perturbation induce bigger disturbances in the system. Usually, heterarchical control is easy to implement and to be made operational. However, its excellent reactivity is paid for in terms of lower overall performance. Notice that the experiments conducted in [VBV+94], were performed on a system with a different architecture. This architecture, though distributed, did not have autonomous agents for orders [Val93]. The same heterarchical behaviour can be achieved in both architectures, but the new architecture supports an easy change-over between control strategies.
4.3. Hybrid control strategies While conventional architectures support only hierarchical or heterarchical control, this architecture supports both -and many more. Intermediate control strategies can be tuned to the specific manufacturing situation and as such can present good solutions in far more situations. According to these control strategies, the SFC holon co-operates with the scheduler holon in a way that goes beyond master-slave relationship. The SFC holon considers the schedules as advice, which it will follow in principle. However, when the scheduling advice becomes unfeasible or clearly suboptimal, the SFC holon autonomously adapts to the prevailing situation and tries to approximate the advised schedule as good as possible. It gives feedback of its actions to the scheduler. Two hybrid control strategies that were implemented, divide decision power over scheduler and shop floor control. In the first one, the SFC holon obeys the sequence given by the scheduler strictly, until disturbances occur. If the next operation scheduled on a workstation would start later than scheduled, the SFC holon has the authority to change the schedule as it pleases. In the second one, everything scheduled before a specific time is the responsibility of the SFC holon. Everything else is the responsibility of the reactive scheduler. It continuously reads the feedback of shop floor data and adapts its schedule to the new situation. Then the scheduler holon decides which tasks can become the responsibility of the SFC holon. Once the schedule is released to the SFC holon, it has full control over all tasks the scheduler released. This control again is heterarchical, i.e., each station takes its own decisions on how to sequence its work. It therefore uses simple, dispatching-like decision rules, like ‘earliest due date’ to select the sequence in which to execute its work. These two strategies yield a better compromise between performance optimisation and reactivity for our testbed flexible-assembly system. The experiments we therefore conducted, were performed using another architecture [Val93]. Although it was possible to implement the behaviour we needed on this older non-holonic architecture, it needed a lot of time and expertise to do so. In the new architecture, implementing, simulating and testing a new strategy should be possible within 24 hours.
4.4. A fundamental problem for executing a schedule In the previous subsections, several heuristic solutions were presented to control the shop floor, given the schedule and the already known deviations from the original schedule. This section will show that it is impossible to construct a good strategy to execute a near-optimal schedule that deals with disturbances autonomously and does not have to perform rescheduling itself, if the Gantt chart is the only available information of the schedule. This is shown in the following example. Consider a job-shop scheduling problem with three machines and three orders. Order B is more urgent than A, and A and B are a lot more urgent than C. In figure 2, the schedule is shown. It can easily be understood that this schedule is optimal, since the most urgent order is scheduled as early as possible, and the other orders are scheduled in between. Suppose the SFC holon is autonomously executing the schedule. It already started operations A1 and B1, and is waiting for either of them to be finished, in which case it would normally start operations B2 and C1. However, due to a temporary lack of components, operation A1 takes more time to complete. When A1 is finally finished, the question can be raised whether the current schedule should be followed or whether operation C1 should be skipped. Given the relative importance of the orders, we now know the right answer, namely to skip operation C1. However, this conclusion could not have been deducted with the information contained in the Gantt-chart only.
Figure 2: An example of problems that occur when executing a schedule. This Gantt chart represents an optimal schedule. Due dates for order A, B and C are 4, 2, and 10 time units. The weights of order A, B, and C are 5, 10 and 1. The performance measure is the weighted mean tardiness. If A1 takes 1 time unit more to complete than expected, it is best to skip operation C1.
4.5. Proposed intermediate holonic control strategy The problem raised in the previous subsection can be solved using the following control strategy to combine the autonomous behaviour (reacting to disturbances) with co-operative behaviour (obeying the schedule). Therefore, the SFC holon explicitly has to consider the effect of local deviations from the schedule to the global performance. This is done by the use of derivatives of the objective function to the duration of the operations. Consider the example of the previous subsection. The effect of the change of the duration of operation A1 on the global performance measure L (the weighted mean tardiness) is represented by the partial derivative ∂L ∂d A1 , where dA1 is the duration of operation A1. This value can be calculated as follows. First, all precedence constraints are written as inequalities. The sequence in which all operations are scheduled on a workstation and within an order also form a set of inequality constraints. These inequalities are expressed in terms of starting times, durations and completion times of operations. Since weighted mean tardiness is a regular measure of performance, given all inequalities, operations will best be started as early as possible. This means that all inequalities can be combined and that the weighted mean tardiness L can be expressed as a function of only the durations of the operations and the time the workstations become available. This function contains only additions and maximisations. The decision whether or not to swap operations C1 and B3 can now be taken by repeating this procedure for the schedule that is made by swapping these two operations. The decision that yields the lowest rise in mean weighted tardiness is the one that should be taken. The same procedure should be done for operations A2 and C2, since the start time of A2 is also directly dependent on the completion time of A1. In this case, there is no need for a swap.
5. Conclusions This paper has presented a holonic architecture for shop floor control. It consists of a set of autonomous building blocks, called holons, that take care of a physical or logical part of the production system. These holons are the order holons, the workstation holons, the transport system holon, the shop floor control holon and the scheduler holons. An important aspect of this architecture is that it supports the use of several control strategies. Therefore, the requirements for the holons are such that the architecture in which they co-operate can be adapted after the holons are developed and implemented. As such, the actual architecture the system works in, is adjustable, rather than an initial set of constraints on the design. Consequently, the shop floor control strategy is easily adaptable to the manufacturing situation. Hierarchical as well as heterarchical control can be performed with the same hardware en software. Moreover, a whole range of intermediate strategies can be used, depending on the situation on the shop floor. The more autonomy is left to the shop
floor control holon, the better it reacts to disturbances. The extreme case for this is heterarchical control. The more the shop floor control holons follows the advice of the schedulers, the higher the performance will be, given it is not disturbed by unexpected events. The extreme case for this is hierarchical control. To really be able to execute a schedule in an autonomous yet intelligent way needs more information about a schedule than a Gantt chart. Therefore it is proposed to use partial derivatives of the global performance measure to the operation durations. This way, the effects of local decisions on the global performance are analysed and a good compromise between co-operation and autonomy is reached.
6. Acknowledgements This paper presents research results obtained through work sponsored by a specialisation grant of the Flemish Institute for Support of Scientific and Technological Research in Industry (IWT), by the Concerted Research Action (GOA) on holonic manufacturing, and by Belgian Programme on Interuniversity Poles of Attraction by the Belgian State, Prime Minister’s Office, Science Policy Programming. The scientific responsibility is assumed by its authors.
7. References [VBV+94] P. VALCKENAERS, F. BONNEVILLE, H. VAN BRUSSEL, L. BONGAERTS, and J. WYNS, Results of the Holonic Control System Benchmark at KULeuven, Rensselaer's 4th International Conference on Computer Intergrated Manufacturing and Automation Technology (CIMAT), proceedings, Rensselaer's Polytechnic Institute, New York, USA, October 1994 [VVB+94a] P. VALCKENAERS, H. VAN BRUSSEL, F. BONNEVILLE, L. BONGAERTS, and J. WYNS, IMS Test Case 5: Holonic Manufacturing Systems, Pre-prints of IMS'94, IFAC workshop, Vienna 13-15 June 1994. [Par91] VAN DYKE PARUNAK, H., "Characterising the Manufacturing Scheduling Problem," Journal of Manufacturing Systems, Vol 10, No 3, pp241-258, 1991. [LSD91] U. LAMPKEMEYER, B.C. SCHMIDT, J. DETAND, Flexplan, Knowledge based Planning and Control in Manufacturing Environments (Description of the Main Modules), Proceedings of CIM-Europe 7th Annual Conference, Torino, Italy, 29-31 May, 1991. [Chr92] CHRYSSOLOURIS, G., "Manufacturing Systems, Theory and Practice", Springer-Verlag, New York, 1992. [BBR+91] BAUER, A., BOWDEN, R., BROWNE, J., DUGGAN, J. en LYONS, G., "Shop Floor Control Systems, From design to implementation," Chapman & Hall, London, 1991. [RNS93] U. REMBOLD, B.O. NNAJI, A. STORR, Computer Integrated Manufacturing and Engineering, AddisonWesley Publishing Company, Wokingham, England, 1993 [Val93] VALCKENAERS, P., "Flexibility for Integrated Production Automation", PhD. thesis K.U.Leuven, 1993 [DBW91] D.M. DILTS, N.P. BOYD, H.H.WHORMS, The Evolution of Control Architectures for Automated Manufacturing Systems, Journal of Manufacturing Systems, Vol. 10, N. 1, 1991. [Bus94] STEFAN BUSSMANN, A multi-agent approach for dynamic, adaptive scheduling of material flow, MAAMAN-94, October 1994 [Sim90] H. A. SIMON, The sciences of the artificial, 2nd ed., MIT Press Cambridge (Mass.), 1990 [Koe89] A. KOESTLER, The Ghost in the Machine, Arkana Books, 1989 [LC94] P. LUH, CZERWINSKY, Scheduling Products with Bill of Material Using an Improved Lagrangian Relaxation Technique, Transactions on Robotics and Automation Vol.10, N.2 p.99, 1994 [BSH92] BISPO, C., SENTIEIRO, J.J.S., en HIBBERD, R.D., "Adaptive scheduling for high volume shops," IEEE Transactions on Robotics and Automation, Vol. 8, N. 6, December 1992. [KCM92] KARSITI, CRUZ AND MULLIGAN, Performance Forecasts as Feedback for Schedule Generation, Journal of Manufacturing Systems, V.11 N.4 p.326, 1992 [KG81] J. KIMEMIA AND S. GERSCHWIN, An Algorithm for the Computer Control of Production in a Flexible Manufacturing System, Proc. IEEE, 1981, pp.628-633.
