In order to lower costs we need a true flexible manufacturing system (FMS). Such a system can be reused without the need to program each production setup ...
TOWARDS A TRUE FLEXIBLE MANUFACTURING SYSTEM ANDERS ADLEMO
SVEN-ARNE ANDRÉASSON
MARTIN FABIAN
Dept. of Computer Engineering
Dept. of Computer Science
Control Engineering Lab.
PER GULLANDER
BENGT LENNARTSON
Dept. of Production Engineering
Control Engineering Lab.
Chalmers University of Technology S-412 96 Göteborg, SWEDEN ABSTRACT The paper describes the concepts that must be considered in order to achieve a flexible manufacturing system that allows introduction of new products and new resources without total reprogramming of the control system. The basic structure of a resource model is presented and also guidelines for achieving a generic resource model. The description of how to manufacture the products is also essential. Basic guidelines for a product model are given. Then, control algorithm aspects are discussed. Operator interface and system dependability are given consideration. Conclusively a machining cell on which we will test our ideas is described.
Keywords: Computer Integrated Manufacturing, Supervisory Control, Flexible Manufacturing System, Object-Oriented Design, Generic Modeling.
1. Introduction A modern manufacturing control system is complex and difficult to implement, and subsequently costly. In order to lower costs we need a true flexible manufacturing system (FMS). Such a system can be reused without the need to program each production setup from scratch. The flexibility can be incorporated on different time scales. A long time scale flexibility permits incorporation of new or different equipment within the manufacturing system, without having to do a complete reprogramming of the control system. Flexibility on a shorter time scale allows incorporation of new products within the manufacturing system, without having to do a complete reprogramming of the control system. Flexibility on a very short time scale permits rescheduling of the manufacturing system on-line. This makes it possible to introduce fault tolerance into the system and subsequently higher dependability. To achieve a truly flexible manufacturing system a possible way is to endow it with a control system constructed to resemble operating systems of ordinary computers. Such a manufacturing system should be able to absorb new products and new equipment without a total reprogramming of the control system. Like in modern computer operating systems, the incorporation of new products (i.e. programs) should be feasible without having to change the production descriptions of already incorporated products, and the incorporation of new resources should be possible in the same way a new server is incorporated into a distributed operating system. In order to achieve such a system we are investigating the following topics:
Model of the manufacturing resources Model of the manufactured products Control algorithms In contrary to most other approaches to design models for flexible manufacturing, we intend to do a bottom up design. The models will be designed while studying cell level control for a number of case studies. The first case is a machining cell described later in this paper. A manufacturing system can be viewed as a finite set of resources, with the machining equipment shared between a set of products (not necessarily finite over time) to be manufactured. Each product, or rather its operation list in conjunction with the resource-models, describes desired routes through the system. To be
able to control the production efficiently, the controller must have an appropriate model of the manufacturing system as well as a model for all the products manufactured. In our approach, both these models will be based on object-oriented analysis and design [8]. The resources consist of producers, locations, and movers. They are modeled hierarchically, and for each node in the corresponding structure tree there is a set of operations that can be performed. The dynamic behavior of a resource is given by a finite state diagram that gives the states essential to the control system. The products are described by their corresponding operation lists. This description gives the operation list for each hierarchical level according to the resource structure tree. These lists can be static or dynamic during product execution. The production control must dedicate a resource for each operation in the operation list at all levels in the hierarchical structure. For each level, this can be done by synchronizing a state machine representing the product operation list with another state-machine representing the resources. This synchronization should be possible to do on-line in order to permit introduction of new products without total rescheduling of the system. Such a rescheduling is also necessary for introducing fault tolerance to the system. Fault tolerance means that the system can be dynamically rescheduled when a primary schedule can not be executed due to a resource failure. This flexibility will improve the dependability of the system [1, 2, 5]. In order to obtain a system that can adapt to changing demands, it is of importance that the operator can adjust the system control according to his experience. This calls for an interface that gives the operator a consistent view of the system that is adequate for his role in the production. There must also be easily understood ways of intervening in the system control.
2. Model of the Manufacturing Resources The manufacturing resources have complex dynamic behaviors. To be able to control production the control system always must know the correct state of each resource. The current state can be modelled by a set of dynamic parameters, each representing just one attribute such as discrete position, running/idle, loading/unloading. When using a state automaton to model resource behavior, each state corresponds to certain values of all these parameters. The current state of the whole manufacturing system is defined by the current states of all devices and all products present in the system. The state of the manufacturing system will be available to the control algorithm by using a set of concurrently executing state automatons. This state information, giving the current state of the manufacturing resources, should be separated from the information that tells the control system what to do when the system has reached a certain state. When the operations on a product in one machine tool are finished, the control information tells which resource will handle the product next. The control information can be extracted by the control algorithm using a resource capability model in conjunction with a product operation model, described in the next chapter. Resource capability model We have developed a model for describing, in an hierarchical manner, the capabilities of the manufacturing system’s physical components and their relationships. The model has been developed with the PACmodel as a basis [4] (the PAC model has been developed by the ESPRIT project COSIMA). In this model, the manufacturing system can be viewed as a set of resources needed to manufacture the products. These resources can be divided into three groups according to their functionality:
Producers that make the necessary physical or logical changes in product properties, e.g. CNC machines (physical changes), measuring stations (logical changes).
Locations that only store products and cannot change any properties of the product, e.g. local buffers and storage systems.
Movers that transports the products between producers and locations, e.g. AGVs, robots, and conveyors. These resources can be modeled hierarchically by grouping resources at one level into a virtual resource at the next higher level (figure 1a). A group of CNC machines and a robot can, for example, be grouped into an area level resource, i.e. a cell. These virtual resources may be not only producers but also movers such as AGV, or locations such as AS/RS (Automatic Storage and Retrieval Systems). When resources are bundled in this way, material handling internal to the cells and control of station-level resources can be disregarded and the design of the area level control system is simplified.
To be able to control production the control algorithm must know the capabilities of all available resources. These capabilities may change at run-time. For the producers the capabilities correspond to the operations that the resource is capable of performing, i.e. the programs it can run and implicitly also the products it can handle [1, 2]. The model includes capability information for all resources at all levels, but the cell-level control algorithm only has to consider the capabilities of the station level resources in that cell. The control system, however, must also consider constraints introduced by the resources. The material flow between two machines may, for example, be handled by a conveyor, making it necessary for resources to handle products in a certain order. Internal Resource Control Modules By using a modularized controller with generic and reusable components, the system will become more flexible, will have more reusable components and therefore also be simpler to design. In achieving this modularized controller an object-oriented analysis and design method can be used. The most probable outcome of such an object-oriented design of the controller is that each physical resource is represented by one software module in the controller. In our opinion, this is the most flexible way to build a modularized controller. These software modules are called “internal resources” and execute resource-specific tasks and holds the current state of one manufacturing resource [6] (figure 1b). Generic Resource Model Library Area level resource
available operations
OpA1 OpA5
R1
General
Cell level resources Station level resources
R11
R111
R12
R13
... R131
R132
R133
OpC2 OpC3
R134
OpS4 OpS6 OpS9
Devices R1111 R1112 R1311 R1312
R1331 R1332 R1341 R1342 R1343
a) Manufacturing resource capability model
Specific
Part Part AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAA AAAAAAAA AAAA AAAA AAAAAAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA Superior AAAA AAAA Controller AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA
Control System
Internal Physical Resources Resources
b) The modularized controller with internal resources for each physical resources. The general part of each internal resource is based on the generic models
Figure 1.
Using this control system structure many advantages will be gained. First, the understanding of system configuration and function will be simplified because the structure resembles the physical system’s configuration. The design of the superior controller will be significantly simplified, since complex tasks can be subdivided into new tasks by decisions made by lower-level controllers (internal resources) in an hierarchical manner. When designing the higher-level controller only the complex task and not all the subtasks has to be considered. Moreover, the flexibility of the controlling system will increase as the superior controller does not have to deal with device-specific tasks. The flexibility of the system will also be increased, since the modules can be exchanged or new modules can be added to the system without major changes. To achieve this flexibility, the new module must have exactly the same interfacial behavior as the previous one, i.e the same messages can be sent to and are received from the module. As seen from the module’s surroundings only the interface and behavior of the module have to be known. Between the internal resources high-level messages are sent, but between each internal resource and its respective physical device, a message-protocol, specific for the device, will probably be used. The internal resources therefore are split in two parts, one general and one specific. The general part of the software module gives an abstract view of the resource, modelled by some state automaton or Petri net. The functionality
promised by this general part is implemented by the specific part. The superior controller then has a homogeneous interface to all resources. These internal resources are self-contained models executing concurrently at run-time. Generic Resource Models Our approach to increase flexibility and standardization is to create a library of generic resource models to support the development of flexible control systems [6]. The implementation of the general part of the internal resources will be based on these generic resource models (figure 1b). To achieve this, manufacturing resources will be grouped into generic classes. All resources belonging to the same class have similar behavior and interface and will be modelled in the same way. These generic resource models also have a hierarchical structure. Some of the operations and attributes of a certain model class may be inherited from superior classes while some may be added. To find the optimal set of generic classes of manufacturing devices, the dynamic behavior and characteristics of many devices and manufacturing systems will be examined thoroughly to get an understanding of which classes to develop, and which devices that should be represented by these classes. It is also important to examine where the need for this flexibility is greatest and which devices are most important to include in these generic models. As a first step towards generic resource models describing the dynamic state changes and interfacial behavior (i.e. messages) of machine tools and robots, the operations performed in cooperation with the surrounding system will be analyzed. The results of this analysis will function as a basis for the development of generic resource models. When designing these classes of generic resource models, many aspects have to be considered, e.g. the design of the superior controller, the control system’s message-passingmessage-passing structure, the internal resources’ independence from other modules, the time available for passing messages, and how easily the system must be understood. The design of the generic models’ message interfaces is strongly affected by message-passing structure of the whole system and the design of the superior controller. An internal resource will communicate both with other internal resources and with the superior controller, and therefore the generic models also must have a generic message-sending and receiving behavior. To achieve high flexibility, the generic models must be as independent as possible of other models in the controller. If one model changes or if one model is added, other modules in the system should not be much affected. The system’s flexibility very much depends on how well the interfaces are designed, which therefore is the most important but also the most difficult part in the work of developing generic model libraries. The design of a generic model for a robot, for example, depends on the complexity of the orders that are received from the controller, how many programs that have to be run to execute the task, etc. Therefore one generic model cannot be made applicable to all kinds of control structures. Control systems can be divided into three groups based on their structure. In the first group the messagepassingmessage-passing system is designed so that all modules send multicast messages to all other controller modules instead of sending a message to a certain address. The modules do not have to know which modules they communicate with. This solution is used in heterarchical control systems. The most important advantage of the heterarchical solution is its high flexibility. The greatest disadvantage with it, is that control functions common to all resources in the whole cell, for example deadlock prevention, must be distributed to all controllers. The implementation of these common control functions, in most cases therefore will be more complicated compared to using one central controller. A second approach is to always send the messages to the same module. This behavior is used in a strictly centralized control structure. All modules receive orders from, and send responses to, the centralized controller. The most serious drawback of the second centralized approach is that all messages must pass the controller. In a manufacturing system a great amount of all messages are sent between the producers and the mover. It is therefore very inconvenient to pass all messages from the mover via the controller to the producer, and vice versa. In the third group the modules communicate with some of the other internal resources and control modules. The problem is to design the modules so that they still are loosely coupled, i.e. flexible. The addresses used to communicate must not be difficult to change; they may be implemented e.g. as a table in a database. This solution therefore is most difficult to implement. Our opinion is that the third solution is best in most cases. If implemented correctly, it combines the flexibility of the centralized approach with the message-passing efficiency of the heterarchical controller. Another problem that has to be considered is that the time passed from sending a message until receiving the response often is not negligible. This is especially true for assembly systems, where the time spent on handling information sometimes is greater than the time spent on transport and assembly operations.
3. Model of the Manufactured Products Through a manufacturing system there is a flow of products. Depending on the control level being viewed, the product flow can consist of either parts, products, or batches of different or similar products or parts. In order to control the system we need a model of the different products to be produced. Such a model could be seen as a “program” for how the product should be produced. For this model we will also use an object-oriented approach. The attributes of a product will determine the required functionality needed for its production, together with structures that depends on the model of the manufacturing system. It should also be possible to indicate the sequence of the various operations and the material transportation needed. The operations that the product has to go through are normally given in an operation list. It contains all the necessary operations and the order in which they should be performed. Since the sequence may be unimportant for certain operations, there should be a way to express this. It should also be possible to express that certain operations could be performed in parallel. For each operation there exist requirements that have to be met by the resource chosen to perform the operation. In this way a product will be described by an operation tree [3]. We call such an operation tree a mission (figure 2). The nodes in the tree also might contain other information needed for the scheduling. Another word for an operation list is a recipe. An operation list must be able to indicate that a production can be altered for a particular product. e.g. certain items might be singled out for test-measuring in order to survey the production statistically. This means that it must be possible to express variations in the production. This can be done in two ways:
static operation list which contains all varieties, dynamic operation list which can be altered during production. In an operation list the operations themselves can consist of new operation lists describing production at a lower hierarchical resource level. For feasible implementation of the production sequences it is of great worth to have to consider only a few items at a time. This is accomplished by separating the two types of information. The implementor can first concentrate on what route each product should take through the system, and then focus on the actions to be performed at each resource. The routes can be specified very directly as simple sequences like ”Do M111; Do M112 or M113; Do M114”. The actions on the other hand would look like ”For M1 program 7”. Such recipes for the manufacturing of a product can be algorithmically transformed into specifications usable for control-law synthesis, as described in the next section. required operations Area level operations
OpA5
M1
Cell level operations
OpC2
M1141 // M1142
// M1143
M112
M11
M114
M111 M113
Station level operations OpS1
M111 OpS2
M1111
M112 OpS3
M1131
Figure 2.
M1141
M113
OpS4
M1142
M114
M1143
Product operations tree with precedences.
When performing the production the control system may keep the production data about each product in a data base. The design of such a data base is dependent of the type of product description. • If we have a static operation list we will have to store flags that indicate what execution path to follow according to different choices as in figure 2. • With a dynamic operation-list we must store the actual route to follow. It should also be possible to change this route during execution. All routes should follow the precedence graphs as in figure 2.
4. Control System With respect to the above, control of a flexible manufacturing system will consist of mapping productmodel trees on the manufacturing-system tree. The implementation of this mapping can follow different strategies, such as resource-oriented, product-oriented, hybrid or demand-driven. Which strategy to follow depends on the production system. It would even be normal to use different strategies for each node in the manufacturing system model tree. The control algorithm also must avoid deadlock and provide safeness. These aspects may be analyzed using state automatons or Petri Nets. Our approach builds on the possibility of using the resource- and product-models in state automaton or Petri Net form, see [7], to synthesize correct control laws by means of the Supervisory Control Theory (SCT); see [10]. It is obvious that, given a model of the physical system and a specification for its overall behavior in the form of desired product-routes, the automatic synthesis of correct control-laws takes us a long way towards a truly flexible manufacturing system. Product Routing With products routing themselves through the system concurrently and asynchronously with each other, there has to be some controlling entity present within the system to synchronize the interaction between products and resources, as well as between the products themselves. It is natural to view a product as a specification for the manufacturing process to exhibit a certain event-sequence. All products, present in a system at any instant, together form a global specification for the system’s overall behavior. The resources will all be considered as having disjoint event-sets, and the resources executing together constitute the plant to be controlled. This plant generates all events, and the products merely follow. Control is seen as a mapping of product-model trees on the manufacturing-system tree. Such a mapping must be restricted by a supervisor, containing all allowable routes through the system. These routes are guaranteed to fulfil the specifications for the products, that is, they guarantee that each product is able to use the resources it requires, so as to satisfactorily be produced (see [7] for details). In formal terms, the mapping can be seen as the synchronization of the operation-lists and the resource-capabilities, thus enabling a supervisor to be synthesized by means of the SCT. The result of such a mapping can be seen in figure 3 b. Note that figure 3 b only describes the mapping on one hierarchical level, presumable the cell level, and that a similar mapping may be applied on all levels, as seen in figure 3 a, thereby allowing the automatic synthesis of control on all levels. OpA1 OpA5 AAAA OpA5 AAAA AAAA AAAAAAAA AAAA AAAAAAAA AAAA AAAA AAAA AAAA AAAAAAAA AAAA AAAAAAAA AAAA AAAA AAAA AAAAAAAA AAAA AAAAAAAA AAAA AAAA AAAA AAAAAAAA AAAA AAAAAAAA AAAA AAAA AAAA AAAAAAAA AAAA AAAAAAAA AAAA AAAA AAAA AAAA AAAAAAAAAAAAAAAA AAAA OpC2
AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA
AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA
OpS2
OpS2 OpS5
OpC2 OpC3 OpS6
OpS4 OpS6 OpS9
OpS1
OpS1 OpS4
OpS3
a) Mapping of product operations tree on producers configuration tree
OpS4
OpS4 OpS6 OpS9
OpS3 OpS4
b) Mapping a product-route on available resource-capabilities Figure 3.
When synthesizing a control scheme to fulfil all the separate specifications, these must be combined into one global specification for the overall system. However, it is imperative that each product be able to run totally unconstrained by any other, whenever desired and possible. Furthermore, the event-sets of the productroute descriptions are subsets of the plants event-set, and are not necessarily disjoint. We also want the resources to be as independent as possible of the specific application they take part in; they must not know the number of users, their ’type’, or even their names beforehand. A mechanism for modeling the sharing of the resources among the users that accomplishes all of the above is known as sharing by interleaving, [7]. The SCT considers state-machines and the event-strings they generate. Control thus becomes a by-product of parsing a regular grammar, described by a state-machine. This control is carried out by the dispatcher, which also has to resolve the inherent nondeterminism arising from interleaving the product-routes. Since the plant is deterministic, the nondeterminism arises where any of a number of different products can be allowed to use the same resource. Obviously, only one of thema can be permitted to do so. Therefore, the dispatcher
acts as a (logically) centralized control unit, enabling or disabling products to enter the resources. Which route of all the possible allowed ones the system is actually taking by allowing a specific product access to a resource, can be determined by inspection of the joint system-state before and after the actual event. In fact, with a deterministic plant, mere inspection of the product-routes' states is sufficient. Now, the product-routes reside within a computer and so their state can, without loss of generality, be considered as attainable. Thus, at each system-state the dispatcher determines which route to follow, and enables the corresponding product. The optimal choosing among the available routes is a complex task, the implementation of which is considered outside the scope of this article. Off-line calculation of control-laws for all products initiated in a system would have to involve productroutes that include all possible alternative routes, and thus would involve static operation-lists. Dynamic operation-lists would demand recalculation of the control-laws as soon as some change has been introduced, such as new alternative routes or temporary deleting of operations. This would inherently have to be done on-line due to its dynamic structure. On-Line Control In a flexible system the number and types of the resources are (runtime) constant and known, while the number and types of products is time-varying. New products with new routes are initiated and old ones terminate, asynchronously and independently as the work progresses. Thus, the total number of products and their routes through the system cannot be known a priori. For the sake of flexibility we must allow any possible route through the system. To cope with this we note that different initial-states of one and the same automaton do not alter the properties of interest to the SCT. This means that we can start up the system with just a few products and their routes calculated off-line. As new orders for more products arrive we interleave the new product-routes in their initial-state with the old product-routes in their current state. The resulting joint specification is then composed with the process in its current state, and a new supervisor can be calculated. Even as products terminate this calculation can be performed, so as to minimize the number of concurrently running products. The Interface to the Operator The enhanced role of the modern operator, being much more active in making immediate and sometimes drastic decisions, means that the interface between the system and the operator becomes very important. As the operator has to accumulate much more information and then has to take quick actions, the presentation of the actual status of a system has to be complete to permit making the right decisions, but, at the same time, limited to avoid the operator being flooded with information. The interface must also be user-friendly, i.e. be simple and easy for an operator to use. An interface also must be flexible enough to make it possible to introduce new hardware, software, or products without having to know every least detail about the current system and without having to redesign parts, or all, of the system. An important aspect of a manufacturing control system concerns how the presentation to the operator is designed. It is not obvious that all the details of a system should be presented, but perhaps rather just the function of the system, such as the operator perceives it. In some situations it therefore could be desirable that a specific operator personally defines how he wants to perceive a specific production system. A possible way to achieve this is to apply object-oriented design and programming of a production system. Thus, an interface between an operator and a computerized production system among many other things has to •
present a complete and consistent view of the system with respect to hardware, software, and current status of the production flow, without being too extensive,
•
be easy and user-friendly to an operator,
•
support programming, system upgrading, planning, supervision, monitoring, failure detection and localization, and failure elimination.
Arguments may be raised against having the dispatcher as a centralized control unit. However, the important issue is to present the operator with a decentralized view of the system, wherein she can specify the route of each product-type independently of any other. It is then up to the underlying control-law synthesizing a Some resources may be able to serve more users than one, but this will have to be modeled within the resource. No nondeterminism can arise because of this. The resources are always deterministic.
system to resolve the issues of deadlock and fulfillment of other specifications. This we claim we can achieve. Having a centralized control unit is no obstacle in itself, as long as the operator does not have to consider this aspect of the system.
5. The Case Study Installation A production-cell for rear-axles is currently (spring 1994) under development at Saab Scania Trucks and Buses, Sweden. This cell has acted as a case study for the research presented in this paper. The implementation of this cell will be described here in the light of the previous sections, considering resource-models, product-routing and control of the system. General Description As can be seen in figure 4, the cell consists of seven resources; a lathe and a multi-operational milling device, together with a quality control station (the producers); two output buffers and one input port (the locations); and a gantry crane (the mover) for loading and unloading the devices. A local area network connects the resources with each other and with the cell-controller. An initial premise was that all communication should take place by means of MMS-messages. However, only the Read- and WriteVariable messages was finally chosen to be implemented.
Lathe
Superior Controller
Milling machine
Entry conveyor
Main exit conveyor
3 Machine operation task description
1 Move & load task description
Measuring station Auxiliary exit conveyor
6 Task finished
Bar code reader
Operator Gantry crane
Operator
Mover
7 Task finished
2 4 Handshake messages
Producer
5 Start trigger
a) The case study installation Figure 4.
b) The message-passing structure. The numbers indicate the sequence used. Case study installation and message-passing structure
Rear axles are manually entered by the operator at the input-station. Here the bar-code reader registers the incoming workpieces by identifying their article numbers. The operator can manually enter rework codes for those axles that have already been through the system but have been unapproved by the QC (Quality Control). The normal flow through the system is for each workpiece to visit first the mill followed by the lathe, and then to exit by the main exit. However, the operator (or operators) can at any time request a specific workpart to the QC-station, where it will be tested for adherence to the tolerance-specifications. This testing is done manually. The GC (Gantry Crane) is of a special type equipped with twin grippers. Under normal operation one of the grippers is always empty, while the other holds a workpiece. Loading a device with a new workpart means first fetching the old workpiece with the empty gripper, rotating 180 degrees and then loading the device with the new workpiece. Thus loading a device is actually an unload-load sequence under normal operation. When leaving a workpiece at an out-port the GC becomes empty, and so always moves to the input-station to fetch a new workpart. Special workcycles will naturally have to exist for starting up and emptying the cell. With production times of around 10 minutes for each device, normal operation means that the GC will spend most of its time waiting for the production-units to finish their work-cycles. When the GC has fetched a new workpart from the input-port it will wait for the milling machine to finish its current task. When having
served the mill, the GC will stand idle waiting for the lathe to finish its current job. Finally, when the lathe has been unloaded-loaded, the processed workpiece will be left at the main exit, whereafter the GC fetches a new workpiece from the input-station. The result of normal operation is that incoming material pushes the outgoing material in front of itself. Workpieces will only be unloaded when new workpieces are to be loaded. This has several important implications. If the input flow of material stops, workpieces will remain in the devices 'forever'. When the system is not in the start-up or emptying phases, there will always be a workpiece at the QC-station waiting to be brought to some other unit, so that workpieces may have to wait a 'long' time to be moved from the QC-station. The fact that the GC has twin grippers, with one always empty, is equivalent to having one global buffer place within the system. Thus, the system can never deadlock and this fact significantly simplifies the implementation of the control functions. Control System When designing the control system the development team adhered closely to the object-oriented design method described by Shlaer/Mellor [11]. This method results in a number of program modules (objects) whose dynamic behavior is described by finite state automatons. The objects include models of the physical devices, BarCodeReader (BCR), Lathe (LA), Mill (MI), Gantry Crane (GC), and Measuring Station (MS), as well as abstract programming concepts like an initiator of part individuals (PI_Initiator) and a dispatcher-object (DecisionMaker). The objects communicate among themselves by sending telegrams requesting operations to be carried out by the receiving object. In practice, the telegrams are implemented as Read- and WriteVariable MMS messages. Control and synchronization of the physical units thus is effected by a dispatcher-object sending and receiving telegrams over the network and within the cell controller, to and from the various objects. The mover, producers, and the superior controller interact as described in figure 4b. Control of the system is effected by a centralized dispatcher with a global view of the overall system. The basic control activities essentially involve two tasks: registering incoming and outgoing workpieces, and selecting new tasks, missions, for the GC and the machines, in order to have the workpieces processed according to their specifications. Seemingly, the dispatcher would have to execute parallel tasks, one for each workpiece. This is not so, however, mainly because of the rigid configuration of the plant. The twin grippers, together with a demand to exchange products as often as possible, mean that the dispatcher has to consider only the workpiece currently held by the GC. It is the requirements of this sole, active workpiece that govern the actions of the dispatcher at each time instant. With no possibility of deadlocks, the dispatcher only has to consider the next action for the active product; no recalculation of allowed routes etc., is necessary. This, of course, is a highly application-specific and inflexible implementation. Without the twin-gripper robot, control would not be so straightforward. As there can be only a limited number of rear axles present within the system at any time, each of which can follow only a limited number of equal routes, there is resident within the dispatcher a fixed set of state automatons describing the workpieces. They are passive inasmuch as their only actions concern updating their respective states based on events from the physical devices. Thus the dispatcher always has a consistent view of the actual system state. However, the state automatons tend to become very detailed and thus highly application-specific and difficult to implement. There is little (or no) provision for designing reusable components to facilitate future development of similar systems. For instance, in the beginning of the system development, the state automatons for each product, consisted of more than 80 states. When the control information for the product, i.e. the operation-list, was removed from the automatons, and the position of the product was represented by a parameter instead of separate states, the number of states was reduced by approximately 90%.
6. Future work In this paper we have defined models and algorithms to achieve a truly flexible manufacturing system. We will go on by investigating how these models and algorithms should be designed for our case study, in order to achieve a more general solution than the present one. This case study is an (almost) pure serial system. We will also use our concepts on a pure parallel system (a cell with three almost identical stations) in order to investigate a completely different kind of system. Then we will try our models on a third case, a cell with both serial and parallel stations. Here we hope to combine the solutions of the two earlier systems in order to develop a general solution for cells with both serial and parallel product flows.
7. Acknowledgment This article was partially supported by the Swedish National Board for Industrial and Technical Development (NUTEK) under grant number 9304792-2.
8. References 1.
Adlemo, A., Andréasson, S.-A., Johansson, M. I., “Fault tolerance strategies in an existing FMS installation”, Control Engineering Practice, vol. 1, no. 1, Feb. 1993, pp. 127-134.
2.
Adlemo, A., Andréasson, S.-A., “Fault Tolerance in Flexible Manufacturing Systems”, will appear as a chapter in Modern Manufacturing: Information Control and Technology, Springer Verlag Advanced Manufacturing Series, Eds. Zaremba & Prasad, July 1994.
3.
Andréasson, S.-A., Andréasson, T., Carlsson, C., “An abstract data type for fault tolerant control algorithms in manufacturing systems”, Information Control Problems in Manufacturing Technology, E. A. Puente and L. Nemes (Eds.), IFAC Proceedings Series, Pergamon Press, Oxford, U.K., no. 13, 1990, pp. 51-56.
4.
Bauer, A., Bowden, R., Browne, J., Duggan, J., Lyons, G., Shop Floor Control Systems. From Design to Implementation, London, Chapman & Hall, 1991.
5.
Chintamaneni, P. R. , Jalote, P., Shieh,Y.-B., Tripathi, S. K., “On Fault Tolerance in Manufacturing Systems”, IEEE Network, vol. 2, no. 3, pp. 32 - 39, (May 1988).
6.
Fabian, M., Lennartson, B., ”Control of Manufacturing Systems: An Object-Oriented Approach”, INCOM’92, Toronto, Canada, May 25-28, 1992
7.
Fabian, M., Lennartson, B., ”Petri Nets and Control Synthesis: An Object-Oriented Approach”, IMS’94, Vienna, Austria, June 13-15, 1994
8.
Jacobson, I., Christerson, M., Jonsson, P., Övergaard, G., Object-Oriented Software Engineering - A Use Case Driven Approach, Addison-Wesley, 1992.
9.
Lee, M., Intelligent Robotics, Halsted, New York, USA, (1989).
10. Ramadge, P. J., Wonham, W.M., “Supervisory Control of a Class of Discrete Event Processes”, SIAM J. Control & Optimization, Vol. 25, No 1, 1987. 11. Shlaer S., Mellor, S. J., Object Lifecycles - Modeling the World in States,Yourdon Press Computing Series, Prentice-Hall Int, 1992.
