PMA - Production Engineering, Machine Design and Automation
How to refer to this page:
Bongaerts, 1998, "Integration of Scheduling and Control in Holonic Manufacturing Systems", Ph.D. Thesis PMA/K.U.Leuven, Chapter 3.

PROSA

Wyns developed PROSA, the PMA/K.U.Leuven holonic reference architecture for manufacturing systems (Van Brussel, 1998, Wyns, 1999). It mainly is an inter-holon architecture, identifying the kind of holons, their responsibilities, and the structure in which they interact. The basic architecture consists out of three types of basic holons: order holons, product holons, and resource holons. They are structured using object-oriented concepts like aggregation and specialisation. Staff holons can be added to assist the basic holons with expert knowledge (Bongaerts, 1996).

Definition of architecture

A reference architecture is an abstraction of a generic solution that provides a set of models, a set of coherent engineering and design principles, and eventually a set of tools and a methodology used in a specific domain (Wyns, 1996, 1999). It aims at structuring the design of a specific system architecture by defining a unified terminology, a generic system structure, the kinds of system components, their responsibilities, dependencies, interfaces, data, behaviour (interactions), constraints, design rules, and models to represent all these aspects.

Basic Holons

There are three types of basic building blocks in a holonic manufacturing system (HMS): product holons, resource holons, and order holons (Figure 1).

Figure 1: Basic Holons

A product holon holds the process and product knowledge to ensure the correct fabrication of the product with sufficient quality. It acts as an information server to the other holons in the HMS. A product holon provides consistent and up-to-date information on the product life-cycle, user requirements, design, and process plan and bill of material.

A resource holon consists of a physical part, namely a production resource in the HMS, and of an information processing part that controls the resource. It offers production capacity and functionality to the surrounding holons (Wyns, 1996). It holds the methods to allocate the production resources, and the knowledge and procedures to organise, use and control these production resources to drive production. A resource holon is an abstraction for the production means such as machines, furnaces, conveyors, pipelines, pallets, components, raw materials, tools, tool holders, material storage, personnel, energy, floor space, etc.

An order holon represents a manufacturing order. It is an active entity responsible for performing the work correctly and on time. It explicitly captures all information and information processing of a job (Valckenaers, 1996).

For a minimalistic implementation of a manufacturing system, it suffices to have a holarchy consisting of these three basic holon types. For instance, assume the use of a heterarchical control approach, based on a market concept, (Dilts, 1991; Joshi, 1994). In such implementation, product holons are created based on real or forecasted market demand. These product holons determine themselves how the product can be produced on the (dynamically changing) set of resource holons. They maintain all technical information needed for the fabrication of an instance of the product. When an order holon arrives in the system, it will first discover what it needs via the respective product holon. The order holon will negotiate with all relevant resource holons to have itself produced by them. As such, the order holon takes care of the logistical aspects (the resource allocation). When an operation starts, the order holon lets the product holon and the resource holons co-operate to perform the technical part of the operation.

The main contribution of this basic control architecture is to get, eventually, everything manufactured in the face of disturbances, uncertainty and change, but with limited guarantees about when and where exactly.

At the same time, if the reference architecture would be limited to this simple basic control architecture, it would have serious drawbacks. First, in a entire factory, there is a large amount of holons (thousands of products, orders and resources), such that it is difficult to understand and manage such an unstructured pool of holons. More importantly, it does not provide predictable performance, even when the environment behaves according to predictions, nor does it offer opportunities for optimisation. The next subsections describe how the architecture addresses these issues.

Aggregation and Specialisation

Interaction between a large number of low level agents results in complex system behaviour that is difficult to understand, to control and to predict (Waldrop, 1992). Structuring the agents in a hierarchy is the appropriate solution to tackle this complexity (Koestler, 1967).

Therefore, aggregated holons are defined as a set of related holons that are clustered together and form in their turn a bigger holon with its own identity. An aggregation hierarchy is formed, which is open-ended at the top and at the bottom. Depending on the scope of the observer, holons are split up into their sub-holons or treated as a whole. The aggregation hierarchy is not necessarily a tree-shaped one: holons may belong to multiple aggregations. Aggregated holons can dynamically change their contents depending on particular needs of the system. They may even emerge out of the self-organising interaction of holons. Examples of aggregation can be found for resources, orders, and products.

A second classification concept is specialisation, which is derived from object-oriented methodologies. The aforementioned basic building blocks sometimes still are too abstract to reason about their place in an architecture. Specialisation separates the holons with respect to their manufacturing characteristics. For instance, for the resource holarchy, usually transport holons and production holons like workstations are very different types of resources.

Staff Holons

The heterarchical control architecture, described above, empowers the basic holons to take all decisions that are necessary to achieve the production goals. The more traditional centralised/hierarchical control architectures outperform this basic system but only under stable and predictable conditions. The basic architecture performs better in uncertain and more turbulent situations.

The K.U.Leuven Holonic Manufacturing Control architecture incorporates a mechanism to have the advantages of both without the disadvantages. It preserves the empowerment of the basic holons, and it gives these basic holons the support of staff holons. These staff holons offer the functionality that is typically found in the higher levels of hierarchical control systems. The main difference is that staff holons have an advisory role (Figure 2).

Figure 2: Staff holons

To avoid that hierarchy introduces rigidity in the system, hierarchical control elements should not enforce their decisions to the basic holons in an inflexible way. Instead, they should have an advisory role in the production process. This change is similar to the shift from line functions to staff functions in human organisations (Hommes, 1980). Therefore, we define staff holons as holons that consider some facets of the problems of other "client" holons and provide this client holon with sufficient information such that it can take the correct decision about that problem. In other words, staff holons assist other holons to do their work. It is noteworthy that also in a human organisation, as stated in (Hommes, 1980), one of the main goals for the introduction of staff functions is to reduce the work load of line functions by providing them with expert knowledge.

Examples of staff holons are schedulers, process sequence planners, CAD-systems, and even MRP-systems. The most important staff holon in the Holonic Manufacturing Control System prototype is a reactive short-range scheduler.

The concept of basic holons enhanced with staff holons decouples the robustness and agility of the system from system optimisation: due to the distributed basic architecture, the HMS delivers robustness and agility and is simple to extend and reconfigure. The optimisation of the HMS is done by optional staff functions. When, due to disturbances and changes in the system, the hierarchical staff holons perform poorly, the advice may be ignored and the basic holons, taking autonomous actions, continue to do their work. On the other hand, when disturbances are totally absent, a HMS can be configured such that the basic holons do execute (in a hierarchical way) the decisions of the staff holons. Usually, however, decision power shall be distributed between basic holons and staff holons, as shown by Bongaerts (for resource allocation). This configuration is determined by the holarchy, which defines the basic rules for co-operation of the holons and thereby limits their autonomy.

Resource Allocation versus Process Control

Often, it is possible to simplify the architecture by limiting it to a certain viewpoint, suitable for a specific application. The structure of the entire holarchy can usually be fairly well decomposed in a resource allocation (sub-)holarchy and a process control (sub-)holarchy. The resource allocation holarchy (order holons, resource holons, and staff holons like the on-line shop floor control holon and the reactive scheduling holon) represents the logistic chain. It focuses on the reservation and allocation of equipment to tasks, aiming at good overall system performance, also under disturbances.

The process control holarchy (CAD-holon, CAPP-holon, product holon and the process control part of the resource holon) represents the technical chain, focusing on the design of the product and the planning and execution of the process. The most important advantage of this dual holarchy is the fact that it shields the resource allocation holarchy from the process control hierarchy. Orders, for instance, mainly focus on resource allocation. Products mainly focus on process planning and execution. Resources typically are part of both holarchies. However, their proposed structure explicitly takes into account this dual nature of their task (Wyns, 1996). Sometimes, the consideration of the interaction of resource allocation and process control yields additional advantages, as shown by Wyns (1997).

Modelling

An essential element of a manufacturing architecture is providing a modelling framework for the components in a manufacturing system, their functions, interfaces, interactions, and the structure in which they operate. Wyns (1999) and Van Brussel (1998) propose to use UML, the unified modelling language, to represent the needed models. UML is a modelling framework for object-oriented design and programming that resulted from the co-operation of Booch, Jacobson and Rumbaugh (Fowler, 1997). The main advantage of a modelling framework is the standard representation method.

Reconfigurability

Reconfigurability is an important requirement for holonic manufacturing systems, since it is a way to make them cope with changes. It should be possible to add, modify, replace and remove modules to, in and from HMSs. Moreover, the optimal configuration may depend on the specific system and situation on the shop floor (as shown for manufacturing control by Bongaerts). Consequently, the HMS should reconfigure itself to maintain its optimal configuration.

Therefore, a holonic architecture itself shall be reconfigurable. This implies that the very structure of the system can be modified, even while the system is running. This concept is quite new, compared to traditional architectures. For instance, a hierarchical architecture imposes a strict hierarchical control structure to the system, which remains unchanged. A heterarchical system imposes a flat control structure to the system. A holonic architecture does not impose a fixed control structure. Instead, it allows the structure to be variable, by allowing temporary hierarchies, multiple hierarchies and by loosening the definition of hierarchy, as explained by Simon (1969) or Valckenaers (1996).

To achieve this reconfigurability, the HMS needs a meta-model and meta-control. A meta-model is a model the HMS has of itself, and contains the system architecture. Bongaerts (1996) presents such a model. Meta-control is the process of defining the right meta-model and setting the right parameters over time. Both the meta-models and meta-control can be implemented both centrally (with a so-called "meta-controller") and distributedly (so-called "without meta-controller"). The concept of meta-models and meta-control is still recent and subject to future research. Possible approaches for the implementation of meta-control are, in increasing degree of autonomy:
· interactive reconfiguration (reconfiguration decisions are made by humans);
· centralised heuristic reconfiguration rules;
· reconfiguration based on experimental data;
· model-based reconfiguration rules (a model is defined to express how reconfiguration decisions affect the global performance, such that the optimal configuration can be determined);
· reconfiguration based on machine learning; and
· distributed reconfiguration.

Conclusion

A reference architecture on holonic manufacturing is presented, based on order, resource, product and staff holons. Important contributions are the separation of manufacturing control and process control, and the reconfigurability of the architecture.

This architecture was developed within the framework of the GOA/HMS project, mainly by Wyns (1999). However, for the development of a reference architecture, teamwork in a multidisciplinary group is essential.

Copyright 1996, Katholieke Universiteit Leuven
Page design: Jo Wyns
Information provider: PMA Division KULeuven
Comments for the authors: Jo Wyns
http://www.mech.kuleuven.ac.be/pma/project/goa/prosa.htm