- Email: [email protected]
An object-oriented simulation framework for real-time control of automated flexible manufacturing systems
Computers & Industrial Engineering 48 (2005) 111–127 www.elsevier.com/locate/dsw
An object-oriented simulation framework for real-time control of automated flexible manufacturing systems Ali Yalcina,*, Ravi Kalyan Namballab a
Department of Industrial and Management Systems Engineering, University of South Florida, 4202 East Fowler Avenue, ENB 118, Tampa, FL 33620, USA b Department of Computer Science and Engineering, University of South Florida, 4202 East Fowler Avenue, ENB 118, Tampa, FL 33620, USA Received 15 October 2003; accepted 15 July 2004 Available online 10 November 2004
Abstract This paper describes an object-oriented simulation approach for the design of a flexible manufacturing system that allows the implementation of control logic during the system design phase. The object-oriented design approach is built around the formal theory of supervisory control based on Finite Automata. The formalism is used to capture inter-object relationships that are difficult to identify in the object-oriented design approach. The system resources are modeled as object classes based on the events that have to be monitored for real-time control. Realtime control issues including deadlock resolution, resource failures in various modes of operation and recovery from failures while sustaining desirable logical system properties are integrated into the logical design for simulating the supervisory controller. q 2004 Elsevier Ltd. All rights reserved. Keywords: Object-oriented simulation; Flexible manufacturing systems; Real-time control
1. Introduction Performance evaluation of discrete parts manufacturing plant design is quite difficult and has to date been tractable mostly through simulation models. Current commercial software for the simulation of manufacturing system designs does not incorporate models of the sensory data collection and electronic control systems that will eventually drive the operation of the factory that the simulation is modeling. * Corresponding author. Tel.: C1 813 974 55 90; fax: C1 813 974 59 56. E-mail address: [email protected] (A. Yalcin). 0360-8352/$ - see front matter q 2004 Elsevier Ltd. All rights reserved. doi:10.1016/j.cie.2004.07.010
112
A. Yalcin, R.K. Namballa / Computers & Industrial Engineering 48 (2005) 111–127
This leaves the control system design architecture as a separate design task to be performed later. Consequently, the impact of the control system on system performance is evaluated after the construction of the plant. Integration of control system design into plant simulation models requires modeling the plant in terms of events that will have to be monitored, recorded, and used for control. In principle, the software used to control the simulated factory operations could also be used to drive the operations of the actual factory after it is constructed. The traditional hierarchical decomposition approach to the design and control of manufacturing systems includes the strategic level (initial design) at the top, followed by the tactical (system configuration) and operational levels (part dispatching) towards the bottom. The control systems as they are referred to in this paper, reside below the operational decisions layer and deal with real-time control of the manufacturing system, which includes deadlock resolution and recovery from resource failures. 1.1. Background There have been several significant manufacturing system simulation approaches that address real-time control issues. The RapidCIM project (Joshi, Smith, Wysk, Peters, & Pegden, 1995) develops a plug-and-play shop floor control design environment based on a simulation model of a target system and a simulation model of its controller. It is based on the control system architecture described by Smith, Hoberecht, and Joshi (1996), and an automatic control code generator for message passing between workstation controller and equipment developed by Smith and Joshi (1993). In RapidCIM, the control modules are integrated within the simulation. It is anticipated that, after debugging a control module, it can be plugged into the actual physical environment and serve as the shop floor control system. This is accomplished by using the simulation software package Arena Real-Time (System Modeling Corporation, 1999), which advances the simulation of the control logic in real-time based on messages passed back and forth with the actual system. Originally developed for discrete event systems, RapidCIM has recently been extended to hybrid systems, which consist of both discrete event and continuous processes (Moreno-Lizaranzu, Wysk, Hong, & Prabhu, 2001). Deuermeyer, Curry, Duchowski, and Venkatesh (1997) develop an automatic deadlock detection scheme for general-purpose simulation systems and offer deadlock detection/recovery algorithms for grouped and overlapping resources using a graph-theoretic description. The methodology described assumes that only a single unit of one or more resources is required for processing of a part. Venkatesh, Smith, Deuermeyer, and Curry (1998) extend this formalism to systems where multiple units of one or more resources are required for processing. The recent extensive survey by Narayanan et al. (1998) summarizes the efforts in the last decade towards the development of object-oriented simulation of manufacturing systems. From the real-time control simulation perspective, OOSIM project (Bodner et al., 1993) addresses deadlock issues within their described framework. While resource failures have been integrated into a number of the simulations, the scope has been limited to measuring system performance, i.e. resource utilizations (Borenstein, 2000). There has been no significant work in addressing the issue of recovering from failures while sustaining required logical properties of the system such as deadlock-freeness and proper termination of activities in the simulation of manufacturing systems.
A. Yalcin, R.K. Namballa / Computers & Industrial Engineering 48 (2005) 111–127
113
1.2. Object-oriented simulation The primary contribution of object-oriented approaches is through their ability to facilitate links between the analysis and specification of a real system and the design and implementation of an action model for that real system where the structure and behavior of entities are readily modeled as objects. An object, in the object-oriented paradigm, is a collection of data (attributes) together with all the operations (methods) which access or alter that data (Hill, 1996). Some or all of these operations could be used to provide a uniform external interface to other parts of the system. Other objects in the system can interact with this object only through requests for the object to execute its operations. The ability of the objectoriented paradigm to provide a direct representation for real world objects comes with four unique features associated with it, namely, encapsulation, data abstraction, inheritance and dynamic binding (Buttler & Corbin, 1991; Tang & Smithers, 1991). Object-oriented simulations have now been produced in many languages, however it is important to emphasize that the use of object-oriented methods is not dependent on any particular programming language (Jones & Powell, 1993). The inherent weakness associated with most of the languages is that they provide users with limited opportunity to extend an existing language feature. The application of the language is limited by the inherent language structure. Some languages allow for creation and insertion of procedures written in other languages but this feature provides only a procedural extension. For example, Arena Simulation Software (Kelton, Sadowski, & Sadowski, 2001) provides a template approach to representing blocks of SIMAN statements so that higher levels of abstraction can be used directly. However, lower levels still remain bound to the SIMAN language. This paper presents an object-oriented design approach for the simulation of flexible manufacturing systems. The approach is an extension of Boucher, Yalcin, and Tai (2000) in scope, design and implementation. The methodology in Boucher et al. (2000) integrates real-time supervisory control and physical system simulation using ARENA simulation coupled with control modules developed using C programming language. The proposed approach in this paper extends the scope by integrating resource failures and recovery from failure procedures. The object-oriented design and implementation approach pursued in this work is also different, and has proven to be more effective with respect to ease of implementation, debugging and extensibility. In this paper, CCC, which is an object-oriented extension to the C programming language, is used. CCC allows for the addition of new data types with their own behaviors, thereby, dealing with the limitation of extensibility, and like most of the other programming languages, it provides procedural abstraction as well. The important features of the described framework are: (1) integrates control system design into the simulation of the physical process, (2) horizontally and vertically extendible within the manufacturing system design and control functions hierarchy (3) the mathematical foundation based on finite automata formalism allows for logical as well as quantitative analysis of the system, (4) facilitates the design and implementation of robust and formal controller models and algorithms that can service a variety of system designs, resolve deadlocks, and accommodate a range of resource failures, and (5) allows an analyst to design and evaluate the impact of different control programs on factory performance, and evaluation of various manufacturing system designs in a ‘plug’ n play” fashion. The rest of the paper is organized as follows. Section 2 describes the physical system. Section 3 describes the simulation framework and its object-oriented realization. Section 4 describes the simulation, the inputs and outputs and the implementation of objects’ interactions, and Section 5 summarizes the contributions of this work and draws some conclusions.
114
A. Yalcin, R.K. Namballa / Computers & Industrial Engineering 48 (2005) 111–127
Fig. 1. A typical flexible manufacturing system architecture.
2. Physical system The physical system considered is a fully automated flexible manufacturing cell that has a number of single capacity machines and a central material-handling device, such as a robot, that interconnects these machines. There is an input and an output buffer where parts can be loaded and unloaded to and from the cell via the material-handling device. Each machine and the material handler are assumed to have their own internal controller as well as a Programmable Logic Controller (PLC) that it is connected to which coordinates its interactions with the rest of the components in the system. The cell controller monitors the machine PLCs for machine failures, repair completions, event start and finish signals, etc. Based on these signals, the controller assures that the system operates within the specified allowable system states through coordinating the activities of the resources in the system. The model of the physical system architecture is illustrated in Fig. 1.
3. Object-oriented design framework In order to simulate the real-time control activities, the system model must consider several factors such as the status of machines and material handlers, processing requirements of the parts in the system, sequencing of the operations required by these parts and contingencies such as equipment breakdowns. The proposed object-oriented design approach contains constructs to model: (1) manufacturing cell, (2) the control structure to accomplish desired system behavior, and (3) communication between the cell and its controller. The modeling of the cell includes the definition of machines, robots, input and output buffers, their interactions and associated contingencies such as resource failures. The control structure, the supervisory controller, controls the physical system in real-time. Finally, the event-handler facilitates the communication of signals from the cell components to the supervisory controller. The object classes associated with these entities and their interaction are depicted in Fig. 2. The events that take place in the cell, denoted by s, are communicated to the supervisory controller object through the event handler object. The control actions, denoted by J(s), are communicated from the supervisor via the cell object to the material handler, which executes these events. The design approach separates the physical characteristics of the manufacturing system from the control requirements of the physical system. In this manner, different combinations of decision strategies can be readily ‘plugged in’ and evaluated without changes to the model of the physical system.
A. Yalcin, R.K. Namballa / Computers & Industrial Engineering 48 (2005) 111–127
115
Fig. 2. Object classes used to model the flexible manufacturing system.
This type of adaptability is desirable in order to evaluate the effectiveness of different supervisory control strategies on a given physical system at the design phase. Such separation is easily implemented in the object-oriented model by creating separate classes for the physical system and the supervisory controller. Different combinations of cell models and control strategies could be experimented with by creating different instances of the corresponding classes and varying the values of their attributes to describe the corresponding model or control strategy. The encapsulation property of the object-oriented approach alleviates the problem of adaptability. For example, the supervisor class, within its body, has all the necessary functions to describe its operation. In order to test different functionalities of supervisor behavior, all the changes that have to be made would be confined to the supervisor class, and do not affect the classes related to the physical system. In the following sections, each physical and logical object classes’ attributes, methods and the objects interactions with other objects are described. Fig. 3 summarizes the attributes and methods associated with all the object classes. It is assumed that each object has an identification attribute, e.g. part_ID in part class, and all classes have methods that return the values of the attributes when requested, e.g. get_current_state( ) in part class which returns the value of the current_state attribute. Furthermore, each class is assumed to have a method that constructs instances of the specific object, e.g. part( ) in part class. These attributes and methods are omitted in Fig. 3 for the other object classes. The relevant attributes and methods of the classes are defined based on the supervisory control theory introduced by Yalcin and Boucher (2000) and Yalcin (2004). Each subsection below establishes a parallelism with this theory and the object-oriented realization of the physical and controller entities. 3.1. Physical object classes 3.1.1. Part class Each part is associated with a part type that is described by the part_type attribute, which describes the sequence of operations required by the part. Execution of an event involving the movement of the part
116
A. Yalcin, R.K. Namballa / Computers & Industrial Engineering 48 (2005) 111–127
Fig. 3. Classes used in the OO model of FMS.
invokes the update_state( ) method to change the current_state attribute implying the loading of the part onto a new machine. 3.1.2. Buffer class The buffer class is used to model the input and output buffers through which the parts enter and leave the manufacturing cell. The parts in the buffer are denoted by the parts[ ] array and the size of the array determines the capacity of the buffer. The value of the binary unload attribute is set to ‘1’ whenever there is a new part to be unloaded. The parts are buffered into this object through the enter_parts( ) method, while the id of the part that is waiting to be unloaded at the front of the buffer is returned by the get_nextpart( ) method. 3.1.3. Machine class At any time, a machine could be processing a part, waiting to be unloaded, in the idle state or in a failed state. The set of binary attributes (Processing, Unload, Idle and Failed) for the machine class
A. Yalcin, R.K. Namballa / Computers & Industrial Engineering 48 (2005) 111–127
117
Fig. 4. States of machine w/o failure.
cover all these states. The id of the part that is being processed is specified by the part_on_machine attribute. The failure_rate and repair_rate are required to estimate the time between different occurrences of failures and also the time between the occurrence of a failure and the corresponding repair. Remaining_processing_time attribute is used in the case of resource failure and represents the remaining operation time of the current part. The load_part( ) and unload_part( ) methods are invoked by load_machnine( ) and unload_machine( ) methods of the cell class to load and unload parts to and from the machines. The update_state( ) method of the machine class is used to update its attributes to denote the occurrence of an event in the cell. A novel contribution of this research is incorporating a range of unexpected resource failures into the simulation of the manufacturing cell and incorporating the required supervisory control and recovery actions into the simulation of the supervisory control logic when these failures are encountered. When machine failures are not considered, a machine is either idle or busy (processing a part or occupied by a part waiting to be unloaded) as depicted in Fig. 4. The machine class’s model is extended to account for the unexpected failures of resources in the cell as shown in Fig. 5. Failures in either the idle or the busy states, and failures when the part being processed on the failed resource is scrapped or continues its operation after the machine is repaired are considered. A subtle point involves the type of failure where the part is scrapped or not scrapped. When a failure occurs, the supervisor does not know whether it will result in scrapping the part or not. This is not known until the failure is ‘cleared’ usually by a plant
Fig. 5. States of machines w/failure.
118
A. Yalcin, R.K. Namballa / Computers & Industrial Engineering 48 (2005) 111–127
technician. When the machine is repaired, the state of the machine is updated accordingly either to the idle state (event k) where the part is scrapped or to the state where the failure occurred (events e or f) if the part is not scrapped. These procedures of actual practice are taken into consideration in designing the proposed control rules. 3.1.4. Material_handler class This class represents the material handler that loads and unloads parts from the machines and buffers in the cell. The busy and idle attributes are used as they are in the machine class. The execute_event( ) method is used to simulate the execution of an event by the material handler. This is achieved by invoking the load_machine( ) method for part loading and unload_machine( ) method for part unloading of the cell class. 3.1.5. Cell class The object model of the cell class includes attributes that describe the resources in the cell, i.e. buffers, robots and machines which are classes of their own. The current state of the cell is described by the current_state attribute, which is used in making resource allocation decisions by the supervisory controller. The methods associated with this class include the make_move_request( ) and make_newpart_request( ) methods which are used by the cell to make a part movement request within the cell or loading of a new part into the cell request to the supervisor. The evaluate_response( ) evaluates the response of the supervisor to the request made and upon a ‘positive’ response, invokes the execute_event( ) method of the material handler class which in turn invokes the load_machine( ) or unload_machine( ) methods, and update_cellstate( ) method for updating the current state of the cell to reflect the occurrence of an event. The attributes and methods of the cell class are based on the finite automata model of the cell. Consider the cell depicted in Fig. 6 with two machines, M1 and M2, and a robot which loads and unloads the machines as well as the cell itself through buffers I1 and O1. The cell is modeled as a finite automaton GZ(S, Q, d, qo, Qm). The transition graph for this cell is shown in Fig. 7. The states of the model are represented by three letter words, which are the status of components M1, M2 and R1 as idle(i) or busy(b). For this example, the finite alphabet of event labels is SZ{I1R1, R1M1, M1R1, R1M2, M2R1, R1O1}. The set of states is QZ{iii, iib, bii, ibi, bib, ibb, bbi}. d:S!Q/Q is the state transition function. qoZ{iii} and QmZ{iii} are the initial state and the set of marked states of the model where all the resources are idle. The current_state attribute’s value belongs to the set of states Q. The load_machine( ) method and the unload_machine( ) method update the cell’s current state based on
Fig. 6. A flexible manufacturing cell.
A. Yalcin, R.K. Namballa / Computers & Industrial Engineering 48 (2005) 111–127
119
Fig. 7. Transition graph for the cell in Fig. 1.
the transition function d( ) and the set of events S. These events describe the part movements from machines to the robot (unloading) and from the robot to the machines (loading). Distinguishing between the failed, unload or processing states is accomplished by checking the attributes of each resource’s object representation. The fail_resource( ), determine_failuretype( ) and repair_resource( ) methods are invoked based on the changes in machine attributes that reflect the different stages of a failure. These methods invoke resource_failed( ) and resource_repaired( ) methods of the supervisor class to update the supervisory control logic. 3.2. Logical object classes 3.2.1. Event handler class The event handler object is used as an interface between the cell and the supervisory controller. The event handler monitors the cell’s objects’ attributes and queues the corresponding signals to be processed by the supervisor. In finite automata theory, the supervisor observes the events that transition the objects between states; i.e. a, b, c, a, d, e,. as in Fig. 5. In real manufacturing systems, this is often not the case. Instead, the current state of the object is observed. The transition that has occurred is known only by implication; i.e. by knowledge of the prior state and the current state of the machines. The attributes of the machine class are intended to represent a set of PLC tags (idle, processing, unload, failed). The tag value domain (0, 1) indicates whether the state is false or true. The machine can only be in one state at a time. The event handler object determines the event request to be sent to the supervisor for evaluation based on the state changes of the machines. Table 1 describes the sequence of state changes for machines and the corresponding event requests sent to the supervisor. Note that when a machine goes from the failed to the idle state, keeping track of only the last state leads to ambiguity as to the signal sent to the supervisor. This can correspond to a failure in the idle mode that is repaired without any parts being scrapped or a failure in the busy mode where the part is scrapped and the machine returns to the system as idle. This ambiguity is resolved by checking the part_on_machine attribute and the remaining_processing_time attribute of the repaired machine. The event handler also maintains the simulation clock through the clock attribute. The simulation clock is advanced using the update_time( ) method. The event_marked[ ] array, indexed by time, describes the events scheduled to occur at a given time. The mark_event( ) method is used by the machine objects to schedule their unload requests at appropriate times and updates the next_event_time attribute to reflect the earliest time that an event is scheduled. The unmark_event( ) method is used in
120
A. Yalcin, R.K. Namballa / Computers & Industrial Engineering 48 (2005) 111–127
Table 1 State changes and corresponding events Sequence of state changes
Corresponding signal sent to supervisor
Idle/processing Unload/idle Processing/unload Idle/failed Unload/failed Processing/failed Failed/processing Failed/unload Failed/idle
Part loaded on machine Part unloading complete Part move request Resource failed in idle mode Resource failed in unload mode Resource failed in processing mode Resource repaired Resource repaired Resource repaired
case of a failure to reschedule the events associated with the failed resource. For example, if a resource fails during the processing of a part, then the completion event of the part must be unmarked if the part is scrapped or delayed if it is not scrapped. The trigger_event( ) is invoked at the advancement of simulation time and initiates one of five types of possible scheduled events, namely loading, unloading, failure, failure clearance and repair by modifying the attributes of associated objects. 3.2.2. Supervisor class The supervisor class uses the evaluate_move_request( ) and evaluate_newpart_request( ) methods to evaluate the corresponding requests from the cell it is associated with. The methods shuffle( ) and trim( ) are private to the supervisor and are used by the evaluate_newpart_request( ) method to generate the control pattern for the set of parts being processed by the cell. The controller can be viewed as a state transition machine that determines which events are allowed to occur next according to the present state of the system and the given production requirements schedule. The control strategy is implemented using the fundamental tools of finite automata theory, as described in (Boucher et al., 2000; Yalcin & Boucher, 2000). An example is included below to illustrate the workings of the supervisor object and establish the relationship between the supervisory control theory in Yalcin and Boucher (2000) and its object-oriented realization. Consider the cell and the finite automaton G representing the cell as described in Section 3.1.5. Assume that there are two part types being processed in the system. Part A has to visit M1 and M2, each of them once, in either order. Part B has to visit M1 and M2 in that order. The FA models for the routings of the parts are shown in Fig. 8. The FA model of each process plan explicitly depicts all the possible routes a part may take for complete processing. The supervisor object uses the shuffle( ) method to generate the requirements model from the finite automata models of the parts in the cell. Whenever the event handler signals the supervisor that a new part is ready for processing in the input buffer via the make_newpart_request( ), the supervisor shuffles the requirements model of the remaining parts in the cell and the finite automaton model of the new part. The shuffle operation yields the new requirements model that includes all possible processing sequences of the parts in the system. The requirements model, represented by the finite automaton SZ(S, X, x, x0, Xm), contains illegal states (in which more than one part is on the same machine) or deadlocked states. In order to eliminate the illegal states, the requirements model S is coupled with the cell model G resulting in a new finite automaton S/GZ(S, Q!X, d!x, qc!x0, Qm!Xm), where qc is the current state of the plant model.
A. Yalcin, R.K. Namballa / Computers & Industrial Engineering 48 (2005) 111–127
121
Fig. 8. Part routing and Finite Automata models for part types A and B.
Fig. 9 shows the requirements model and the corresponding coupled cell model for our example system when a part of type A is in the state a2 and a new part of type B enters the cell. The marked language of the coupled system, denoted by Lm(S/G), consists of the marked sequence of events that take the coupled system from initial state to the combined final state where all parts are processed and unloaded (Yalcin & Boucher, 2000). In order to eliminate deadlock states, i.e. a2b1, bi, from the coupled model, and determine Lm (S/G), the trim( ) method is used to obtain the deadlock-free maximally permissive control pattern to control the cell. The resulting deadlock-free control pattern for the models in Fig. 9 is shown in Fig. 10.
Fig. 9. Finite Automate models for S and S/G.
122
A. Yalcin, R.K. Namballa / Computers & Industrial Engineering 48 (2005) 111–127
Fig. 10. The resulting Supervisory Control Pattern implementing Lm(S/G).
Whenever there is a request to move a part in the cell from one machine to another, the supervisor controller object would use evaluate_move_request( ) method to check the table indexed by the current state of the supervisor and the event. A ‘1’ in the corresponding table entry would validate the request and a presence of ‘0’ would mean denial of the request. Modeling of failures using the afore-mentioned finite-automata representation would require the modification of the plant model to denote the unavailability of a resource due to the failure. This would increase the state space of the plant model from 2nK1 to 6nK1 and the size of the coupled model S/G would also be compounded in size. The proposed object-oriented implementation handles failures efficiently in real-time by applying a ‘mask’ disabling all the transitions from the control pattern that load or unload the failed resource (Yalcin, 2004). This ‘mask’ is implemented through the machine_failed( ) method. To illustrate this approach, consider an automated manufacturing cell with four machines and a robot that loads and unloads these machines similar to the cell depicted in Fig. 6. In addition to parts A and B in Fig. 8, another part C is considered. The transition graph of the finite automata model for Part C is depicted in Fig. 11. Consider a point in time when part A is in state a6, part B is in state b2 and part C is in state c2. At this point the current state of the requirements model is a6b2c2 and the current state of the cell model is bbbii. The supervisory control pattern transition graph is shown in Fig. 12. Assume machine 3 fails while part C is being processed. When the failure signal is received, the events M3R1 and R1M3 are ‘masked’ and disabled until the resource is repaired. The only event allowed in state a6b2c2 by the supervisor is M2R1. Event sequence M2R1-R101 is the only allowable sequence and will be executed. In state afb2c2 there
Fig. 11. Transition graph for Part C.
A. Yalcin, R.K. Namballa / Computers & Industrial Engineering 48 (2005) 111–127
123
Fig. 12. Transition graph of the allowable events in the supervisory controller.
are two events allowable, M3R1 associated with part C and M1R1 associated with part B. Assuming machine 3 is still in the failed state, only M2R1, B is allowed. When the system reaches state afbfc2, iibii the system is blocked and must wait until machine 3 is repaired to finish processing part C. Upon receiving a repair signal, the mask is removed and the plant returns to its normal operation using the resource_repaired( ) method. If the failure causes the part on the machine to be scrapped, a new control pattern is generated based on the requirements of the remaining parts in the cell and the state of the machine is set to idle by modifying the objects attributes. If the failure is in the idle mode or the part is not scrapped no action is necessary until the resource is repaired where the attributes of the repaired resource is updated (Yalcin, 2004). A subtle point arises when a resource fails and the part on the robot at that time requires the use of the failed resource. This situation is handled by placing the part back to the resource it came from and returning the state of the supervisor, the cell, the part and the involved resource to their respective states
124
A. Yalcin, R.K. Namballa / Computers & Industrial Engineering 48 (2005) 111–127
before the part was picked up. If both the destination resource and the resource where the part was picked up from fail during the transportation of the part, the robot has no choice but to wait until one of the resources is repaired.
4. System simulation 4.1. Simulation inputs The input files to the simulation describe the processing times and the routing of the part types in the cell representing the full set of alternative production sequences for the parts. There are two types of files. The partplantstate[i].txt specifies the machine which can perform the required operation on part type i in a particular state. The partprocessplan[i].txt describes the state transitions for the part type i and the processing time for that part in each state. Together, they contain all the information to generate the corresponding Finite Automata models of the parts. At the beginning of each simulation, the user also specifies the number of machines in the cell model and the number of parts to be processed in the plant during the simulation. The user may also simulate resource failures in the plant by specifying failure-rates and repair rates for the resources. These set of details are complete in themselves in describing the structure and behavior of the plant comprehensively. The constructor of the cell class is used as an initialization procedure to create the buffer, the machine, the material handler and the part objects that form the cell object, and to create certain informationarrays from the input files. These arrays capture all the information on the cell behavior and are henceforth, used by the supervisor to formulate a control strategy. 4.2. Simulation logic The simulation logic is implemented in the object-oriented model through the updating of the attributes of the component objects and the interactions among these components are modeled through the message-passing facility in the object-oriented approach. The event handler object monitors the buffers and the machines in the cell and queues and relays appropriate event signals to the supervisor object. The supervisor object then evaluates the request based on the current state of the system and the control strategy and sends back the decision to allow/disallow the request back to the cell object, which executes the move if it is allowed. If the move is not allowed, it is sent to the end of the queue of events requested in the event handler object to be evaluated again when the system state changes. The flow of information within the simulation is illustrated in Fig. 13. The simulation starts with the arrival of a part to the input buffer. The event handler sends the load new part signal to the supervisor based on the change in the buffer object’s attributes. The supervisor generates a new control pattern, evaluates the move requested using the evaluate_newpart_request( ) and the evaluate_move_request( ) methods. The response is evaluated by the evaluate_response( ) method of the cell, and if it is allowed, the execute_event( ) method of the material handler, load_machine( ) method of the cell and load_part( ) method of the machine are sequentially invoked. The current states of the cell, the machine and the part are updated using their respective update_state( ) methods. Based on the processing time of the required operation, the mark_event( ) method of the event handler object schedules the part to be unloaded when the processing is complete. When the simulation
A. Yalcin, R.K. Namballa / Computers & Industrial Engineering 48 (2005) 111–127
125
Fig. 13. Flow of information within the simulation.
clock reaches that time epoch, trigger_event( ) method of the event handler updates the machine attribute unload to 1 and processing to 0, which initiates a new move request and the cycle continues until all scheduled parts are processed. Machine failures are scheduled according to the failure times that are generated randomly as a function of a failure rate specified by the user prior to the simulation. The event handler object monitors these events by monitoring each machine’s attributes. When the simulation clock reaches the time epoch at which a machine is ‘scheduled’ to fail, the failed attribute is set by the trigger_event( ) method. The fail_resource( ) method of the cell is invoked and the event handler signals the supervisor to indicate the failure of the machine. The resource_failed( ) method of the supervisor object disables the events requiring this machine via implementing a mask. The event_handler sends another request to the supervisor if the part is scrapped. The supervisor then generates a new control pattern considering the scrapped part. When the machine is repaired, this event is also relayed to the supervisor in a similar fashion to the failure event and the system returns to normal operation status and processing of the part resumes. A detailed description of the simulation software and the source code is available in Namballa and Yalcin (2004).
126
A. Yalcin, R.K. Namballa / Computers & Industrial Engineering 48 (2005) 111–127
4.3. Simulation outputs The output produced by the simulation model is captured in data files and includes event trace information, system performance information, and supervisory controller computation complexity information. The trace information includes a trace of the events ordered by time for understanding the behavior of the system. The system performance information includes measures such as the throughput, resource utilization, etc. Also, included are the state space and response time of the supervisory controller to keep track of computational complexity.
5. Summary and conclusions Integration of control requirements into plant simulation models requires modeling the plant in terms of events that have to be monitored, recorded, and used for control. In this paper we describe an objectoriented approach to the design of flexible manufacturing system simulation that allow the implementation of control logic during the system design phase. The object-oriented design approach is structured around formal supervisory control theory. While object-oriented design approaches have several advantages for software development, especially in specifying intra-object relationships, the interactions between objects in a complex system are difficult to capture. The formalisms in supervisory control theory are utilized to capture and implement these inter-object interactions. We have described a design platform that allows a design engineer to design and evaluate the impact of different control programs on factory performance. Important contributions of this work are: (1) the development of an extendable object-oriented manufacturing system simulation framework, (2) the design of simulation objects that properly communicate state information and service requests to a supervisory controller, (3) the design of a supervisory control object model based on formal methods that can service a range of flexible manufacturing systems, and (4) addresses subtle implementation issues such as dynamic routing flexibility, deadlock resolution, use of PLCs and diagnostic procedures in repairs allowing the simulated control code to be used as a real-time supervisory controller for the actual system. Complementary to and different from other proposed object-oriented manufacturing system simulations in the literature, the implementation of simulation logic that incorporates a range of realistic resource failures and failure recovery procedures while sustaining desirable logical properties of the system such as deadlock-freeness and proper termination is a novel contribution.
References Bodner, D. A., Dilley-Schneider, S. J., Narayanan, S., Sreekanth, U., McGinnis, L. F., Mitchell, C. M., & Govindaraj, T. (1993). Object-oriented modeling and simulation of automated control in manufacturing. Proceedings of the 1993 IEEE international conference on robotics and automation (Vol. 3, pp. 83–88). Washington, DC: IEEE Computer Society Press. Borenstein, D. (2000). Implementation of an object-oriented tool for the simulation of manufacturing systems and its application to study the effects of flexibility. International Journal of Production Research, 38(9), 2125–2142. Boucher, T. O., Yalcin, A., & Tai, T. (2000). Dynamic routing and the performance of automated manufacturing cells. IIE Transactions, 32(10), 975–988. Buttler, G. F., & Corbin, M. J. (1991). Introduction to object-oriented simulation. IEEE Colloquium on Object-Oriented Simulation and Control, 1/1–1/3.
A. Yalcin, R.K. Namballa / Computers & Industrial Engineering 48 (2005) 111–127
127
Deuermeyer, B., Curry, G., Duchowski, A. T., & Venkatesh, S. (1997). An automatic approach to deadlock detection and resolution in discrete simulation systems. INFORMS Journal on Computing, 9(2), 195–205. Hill, D. R. C. (1996). Object-oriented analysis and simulation. Reading, MA: Addison-Wesley. Jones, J. A., & Powell, K. A. (1993). Building object-oriented simulations with CCC. Proceedings of the Winter simulation conference, Los Angeles, 79–88. Joshi, S. B., Smith, J. S., Wysk, R. A., Peters, B. A., & Pegden, C. D. (1995). RapidCIM: An approach to rapid development of control software for FMS control. 27th CIRP international seminar on manufacturing systems, Ann Arbor, MI . Kelton, W. D., Sadowski, R. P., & Sadowski, D. A. (2001). Simulation with Arena. New York: McGraw-Hill. Moreno-Lizaranzu, M. J., Wysk, R. A., Hong, J., & Prabhu, V. V. (2001). A hybrid shop-floor control system for food manufacturing. IIE Transactions, 33, 193–202. Namballa R., & Yalcin A (2004). Source codes for object-oriented implementation of flexible manufacturing system simulation. University of South Florida, IMSE Department, http://www.eng.usf.edu/~ayalcin/object_oriented_cell_controller_simulation/. Narayanan, S., Bodner, D. A., Sreekanth, U., Govindaraj, T., McGinnis, L. F., & Mitchell, C. M. (1998). Research in objectoriented manufacturing simulations: An assessment of the state of the art. IIE Transactions, 30, 795–810. Smith, J. S., Hoberecht, W. C., & Joshi, S. B. (1996). A shop-floor control architecture for computer-integrated manufacturing. IIE Transactions, 28, 783–794. Smith, J. S., & Joshi, S. B. (1993). Message-based part state graphs (MPSG) for shop floor control. Proceedings of the second IIE research conference, Los Angeles, CA . System Modeling Corporation (1999). Arena professional edition reference guide, Swickley, PA. Tang, M. X., & Smithers, T. (1991). Towards object-oriented simulation. IEEE Colloquium on Object-Oriented Simulation and Control, 7/1–7/4. Venkatesh, S., Smith, J. S., Deuermeyer, B., & Curry, G. (1998). Deadlock detection and resolution for discrete-event simulation: Multiple-unit seizes. IIE Transactions, 30, 201–216. Yalcin, A. (2004). Re-configurable supervisory control of automated manufacturing cells with resource failures. Robotics and Computer Integrated Manufacturing, 20(2), 111–119. Yalcin, A., & Boucher, T. O. (2000). Deadlock avoidance in flexible manufacturing systems using finite automata. IEEE Transactions on Robotics and Automation, 16(4).
An object-oriented simulation framework for real-time control of automated flexible manufacturing systems Ali Yalcina,*, Ravi Kalyan Namballab a
Department of Industrial and Management Systems Engineering, University of South Florida, 4202 East Fowler Avenue, ENB 118, Tampa, FL 33620, USA b Department of Computer Science and Engineering, University of South Florida, 4202 East Fowler Avenue, ENB 118, Tampa, FL 33620, USA Received 15 October 2003; accepted 15 July 2004 Available online 10 November 2004
Abstract This paper describes an object-oriented simulation approach for the design of a flexible manufacturing system that allows the implementation of control logic during the system design phase. The object-oriented design approach is built around the formal theory of supervisory control based on Finite Automata. The formalism is used to capture inter-object relationships that are difficult to identify in the object-oriented design approach. The system resources are modeled as object classes based on the events that have to be monitored for real-time control. Realtime control issues including deadlock resolution, resource failures in various modes of operation and recovery from failures while sustaining desirable logical system properties are integrated into the logical design for simulating the supervisory controller. q 2004 Elsevier Ltd. All rights reserved. Keywords: Object-oriented simulation; Flexible manufacturing systems; Real-time control
1. Introduction Performance evaluation of discrete parts manufacturing plant design is quite difficult and has to date been tractable mostly through simulation models. Current commercial software for the simulation of manufacturing system designs does not incorporate models of the sensory data collection and electronic control systems that will eventually drive the operation of the factory that the simulation is modeling. * Corresponding author. Tel.: C1 813 974 55 90; fax: C1 813 974 59 56. E-mail address: [email protected] (A. Yalcin). 0360-8352/$ - see front matter q 2004 Elsevier Ltd. All rights reserved. doi:10.1016/j.cie.2004.07.010
112
A. Yalcin, R.K. Namballa / Computers & Industrial Engineering 48 (2005) 111–127
This leaves the control system design architecture as a separate design task to be performed later. Consequently, the impact of the control system on system performance is evaluated after the construction of the plant. Integration of control system design into plant simulation models requires modeling the plant in terms of events that will have to be monitored, recorded, and used for control. In principle, the software used to control the simulated factory operations could also be used to drive the operations of the actual factory after it is constructed. The traditional hierarchical decomposition approach to the design and control of manufacturing systems includes the strategic level (initial design) at the top, followed by the tactical (system configuration) and operational levels (part dispatching) towards the bottom. The control systems as they are referred to in this paper, reside below the operational decisions layer and deal with real-time control of the manufacturing system, which includes deadlock resolution and recovery from resource failures. 1.1. Background There have been several significant manufacturing system simulation approaches that address real-time control issues. The RapidCIM project (Joshi, Smith, Wysk, Peters, & Pegden, 1995) develops a plug-and-play shop floor control design environment based on a simulation model of a target system and a simulation model of its controller. It is based on the control system architecture described by Smith, Hoberecht, and Joshi (1996), and an automatic control code generator for message passing between workstation controller and equipment developed by Smith and Joshi (1993). In RapidCIM, the control modules are integrated within the simulation. It is anticipated that, after debugging a control module, it can be plugged into the actual physical environment and serve as the shop floor control system. This is accomplished by using the simulation software package Arena Real-Time (System Modeling Corporation, 1999), which advances the simulation of the control logic in real-time based on messages passed back and forth with the actual system. Originally developed for discrete event systems, RapidCIM has recently been extended to hybrid systems, which consist of both discrete event and continuous processes (Moreno-Lizaranzu, Wysk, Hong, & Prabhu, 2001). Deuermeyer, Curry, Duchowski, and Venkatesh (1997) develop an automatic deadlock detection scheme for general-purpose simulation systems and offer deadlock detection/recovery algorithms for grouped and overlapping resources using a graph-theoretic description. The methodology described assumes that only a single unit of one or more resources is required for processing of a part. Venkatesh, Smith, Deuermeyer, and Curry (1998) extend this formalism to systems where multiple units of one or more resources are required for processing. The recent extensive survey by Narayanan et al. (1998) summarizes the efforts in the last decade towards the development of object-oriented simulation of manufacturing systems. From the real-time control simulation perspective, OOSIM project (Bodner et al., 1993) addresses deadlock issues within their described framework. While resource failures have been integrated into a number of the simulations, the scope has been limited to measuring system performance, i.e. resource utilizations (Borenstein, 2000). There has been no significant work in addressing the issue of recovering from failures while sustaining required logical properties of the system such as deadlock-freeness and proper termination of activities in the simulation of manufacturing systems.
A. Yalcin, R.K. Namballa / Computers & Industrial Engineering 48 (2005) 111–127
113
1.2. Object-oriented simulation The primary contribution of object-oriented approaches is through their ability to facilitate links between the analysis and specification of a real system and the design and implementation of an action model for that real system where the structure and behavior of entities are readily modeled as objects. An object, in the object-oriented paradigm, is a collection of data (attributes) together with all the operations (methods) which access or alter that data (Hill, 1996). Some or all of these operations could be used to provide a uniform external interface to other parts of the system. Other objects in the system can interact with this object only through requests for the object to execute its operations. The ability of the objectoriented paradigm to provide a direct representation for real world objects comes with four unique features associated with it, namely, encapsulation, data abstraction, inheritance and dynamic binding (Buttler & Corbin, 1991; Tang & Smithers, 1991). Object-oriented simulations have now been produced in many languages, however it is important to emphasize that the use of object-oriented methods is not dependent on any particular programming language (Jones & Powell, 1993). The inherent weakness associated with most of the languages is that they provide users with limited opportunity to extend an existing language feature. The application of the language is limited by the inherent language structure. Some languages allow for creation and insertion of procedures written in other languages but this feature provides only a procedural extension. For example, Arena Simulation Software (Kelton, Sadowski, & Sadowski, 2001) provides a template approach to representing blocks of SIMAN statements so that higher levels of abstraction can be used directly. However, lower levels still remain bound to the SIMAN language. This paper presents an object-oriented design approach for the simulation of flexible manufacturing systems. The approach is an extension of Boucher, Yalcin, and Tai (2000) in scope, design and implementation. The methodology in Boucher et al. (2000) integrates real-time supervisory control and physical system simulation using ARENA simulation coupled with control modules developed using C programming language. The proposed approach in this paper extends the scope by integrating resource failures and recovery from failure procedures. The object-oriented design and implementation approach pursued in this work is also different, and has proven to be more effective with respect to ease of implementation, debugging and extensibility. In this paper, CCC, which is an object-oriented extension to the C programming language, is used. CCC allows for the addition of new data types with their own behaviors, thereby, dealing with the limitation of extensibility, and like most of the other programming languages, it provides procedural abstraction as well. The important features of the described framework are: (1) integrates control system design into the simulation of the physical process, (2) horizontally and vertically extendible within the manufacturing system design and control functions hierarchy (3) the mathematical foundation based on finite automata formalism allows for logical as well as quantitative analysis of the system, (4) facilitates the design and implementation of robust and formal controller models and algorithms that can service a variety of system designs, resolve deadlocks, and accommodate a range of resource failures, and (5) allows an analyst to design and evaluate the impact of different control programs on factory performance, and evaluation of various manufacturing system designs in a ‘plug’ n play” fashion. The rest of the paper is organized as follows. Section 2 describes the physical system. Section 3 describes the simulation framework and its object-oriented realization. Section 4 describes the simulation, the inputs and outputs and the implementation of objects’ interactions, and Section 5 summarizes the contributions of this work and draws some conclusions.
114
A. Yalcin, R.K. Namballa / Computers & Industrial Engineering 48 (2005) 111–127
Fig. 1. A typical flexible manufacturing system architecture.
2. Physical system The physical system considered is a fully automated flexible manufacturing cell that has a number of single capacity machines and a central material-handling device, such as a robot, that interconnects these machines. There is an input and an output buffer where parts can be loaded and unloaded to and from the cell via the material-handling device. Each machine and the material handler are assumed to have their own internal controller as well as a Programmable Logic Controller (PLC) that it is connected to which coordinates its interactions with the rest of the components in the system. The cell controller monitors the machine PLCs for machine failures, repair completions, event start and finish signals, etc. Based on these signals, the controller assures that the system operates within the specified allowable system states through coordinating the activities of the resources in the system. The model of the physical system architecture is illustrated in Fig. 1.
3. Object-oriented design framework In order to simulate the real-time control activities, the system model must consider several factors such as the status of machines and material handlers, processing requirements of the parts in the system, sequencing of the operations required by these parts and contingencies such as equipment breakdowns. The proposed object-oriented design approach contains constructs to model: (1) manufacturing cell, (2) the control structure to accomplish desired system behavior, and (3) communication between the cell and its controller. The modeling of the cell includes the definition of machines, robots, input and output buffers, their interactions and associated contingencies such as resource failures. The control structure, the supervisory controller, controls the physical system in real-time. Finally, the event-handler facilitates the communication of signals from the cell components to the supervisory controller. The object classes associated with these entities and their interaction are depicted in Fig. 2. The events that take place in the cell, denoted by s, are communicated to the supervisory controller object through the event handler object. The control actions, denoted by J(s), are communicated from the supervisor via the cell object to the material handler, which executes these events. The design approach separates the physical characteristics of the manufacturing system from the control requirements of the physical system. In this manner, different combinations of decision strategies can be readily ‘plugged in’ and evaluated without changes to the model of the physical system.
A. Yalcin, R.K. Namballa / Computers & Industrial Engineering 48 (2005) 111–127
115
Fig. 2. Object classes used to model the flexible manufacturing system.
This type of adaptability is desirable in order to evaluate the effectiveness of different supervisory control strategies on a given physical system at the design phase. Such separation is easily implemented in the object-oriented model by creating separate classes for the physical system and the supervisory controller. Different combinations of cell models and control strategies could be experimented with by creating different instances of the corresponding classes and varying the values of their attributes to describe the corresponding model or control strategy. The encapsulation property of the object-oriented approach alleviates the problem of adaptability. For example, the supervisor class, within its body, has all the necessary functions to describe its operation. In order to test different functionalities of supervisor behavior, all the changes that have to be made would be confined to the supervisor class, and do not affect the classes related to the physical system. In the following sections, each physical and logical object classes’ attributes, methods and the objects interactions with other objects are described. Fig. 3 summarizes the attributes and methods associated with all the object classes. It is assumed that each object has an identification attribute, e.g. part_ID in part class, and all classes have methods that return the values of the attributes when requested, e.g. get_current_state( ) in part class which returns the value of the current_state attribute. Furthermore, each class is assumed to have a method that constructs instances of the specific object, e.g. part( ) in part class. These attributes and methods are omitted in Fig. 3 for the other object classes. The relevant attributes and methods of the classes are defined based on the supervisory control theory introduced by Yalcin and Boucher (2000) and Yalcin (2004). Each subsection below establishes a parallelism with this theory and the object-oriented realization of the physical and controller entities. 3.1. Physical object classes 3.1.1. Part class Each part is associated with a part type that is described by the part_type attribute, which describes the sequence of operations required by the part. Execution of an event involving the movement of the part
116
A. Yalcin, R.K. Namballa / Computers & Industrial Engineering 48 (2005) 111–127
Fig. 3. Classes used in the OO model of FMS.
invokes the update_state( ) method to change the current_state attribute implying the loading of the part onto a new machine. 3.1.2. Buffer class The buffer class is used to model the input and output buffers through which the parts enter and leave the manufacturing cell. The parts in the buffer are denoted by the parts[ ] array and the size of the array determines the capacity of the buffer. The value of the binary unload attribute is set to ‘1’ whenever there is a new part to be unloaded. The parts are buffered into this object through the enter_parts( ) method, while the id of the part that is waiting to be unloaded at the front of the buffer is returned by the get_nextpart( ) method. 3.1.3. Machine class At any time, a machine could be processing a part, waiting to be unloaded, in the idle state or in a failed state. The set of binary attributes (Processing, Unload, Idle and Failed) for the machine class
A. Yalcin, R.K. Namballa / Computers & Industrial Engineering 48 (2005) 111–127
117
Fig. 4. States of machine w/o failure.
cover all these states. The id of the part that is being processed is specified by the part_on_machine attribute. The failure_rate and repair_rate are required to estimate the time between different occurrences of failures and also the time between the occurrence of a failure and the corresponding repair. Remaining_processing_time attribute is used in the case of resource failure and represents the remaining operation time of the current part. The load_part( ) and unload_part( ) methods are invoked by load_machnine( ) and unload_machine( ) methods of the cell class to load and unload parts to and from the machines. The update_state( ) method of the machine class is used to update its attributes to denote the occurrence of an event in the cell. A novel contribution of this research is incorporating a range of unexpected resource failures into the simulation of the manufacturing cell and incorporating the required supervisory control and recovery actions into the simulation of the supervisory control logic when these failures are encountered. When machine failures are not considered, a machine is either idle or busy (processing a part or occupied by a part waiting to be unloaded) as depicted in Fig. 4. The machine class’s model is extended to account for the unexpected failures of resources in the cell as shown in Fig. 5. Failures in either the idle or the busy states, and failures when the part being processed on the failed resource is scrapped or continues its operation after the machine is repaired are considered. A subtle point involves the type of failure where the part is scrapped or not scrapped. When a failure occurs, the supervisor does not know whether it will result in scrapping the part or not. This is not known until the failure is ‘cleared’ usually by a plant
Fig. 5. States of machines w/failure.
118
A. Yalcin, R.K. Namballa / Computers & Industrial Engineering 48 (2005) 111–127
technician. When the machine is repaired, the state of the machine is updated accordingly either to the idle state (event k) where the part is scrapped or to the state where the failure occurred (events e or f) if the part is not scrapped. These procedures of actual practice are taken into consideration in designing the proposed control rules. 3.1.4. Material_handler class This class represents the material handler that loads and unloads parts from the machines and buffers in the cell. The busy and idle attributes are used as they are in the machine class. The execute_event( ) method is used to simulate the execution of an event by the material handler. This is achieved by invoking the load_machine( ) method for part loading and unload_machine( ) method for part unloading of the cell class. 3.1.5. Cell class The object model of the cell class includes attributes that describe the resources in the cell, i.e. buffers, robots and machines which are classes of their own. The current state of the cell is described by the current_state attribute, which is used in making resource allocation decisions by the supervisory controller. The methods associated with this class include the make_move_request( ) and make_newpart_request( ) methods which are used by the cell to make a part movement request within the cell or loading of a new part into the cell request to the supervisor. The evaluate_response( ) evaluates the response of the supervisor to the request made and upon a ‘positive’ response, invokes the execute_event( ) method of the material handler class which in turn invokes the load_machine( ) or unload_machine( ) methods, and update_cellstate( ) method for updating the current state of the cell to reflect the occurrence of an event. The attributes and methods of the cell class are based on the finite automata model of the cell. Consider the cell depicted in Fig. 6 with two machines, M1 and M2, and a robot which loads and unloads the machines as well as the cell itself through buffers I1 and O1. The cell is modeled as a finite automaton GZ(S, Q, d, qo, Qm). The transition graph for this cell is shown in Fig. 7. The states of the model are represented by three letter words, which are the status of components M1, M2 and R1 as idle(i) or busy(b). For this example, the finite alphabet of event labels is SZ{I1R1, R1M1, M1R1, R1M2, M2R1, R1O1}. The set of states is QZ{iii, iib, bii, ibi, bib, ibb, bbi}. d:S!Q/Q is the state transition function. qoZ{iii} and QmZ{iii} are the initial state and the set of marked states of the model where all the resources are idle. The current_state attribute’s value belongs to the set of states Q. The load_machine( ) method and the unload_machine( ) method update the cell’s current state based on
Fig. 6. A flexible manufacturing cell.
A. Yalcin, R.K. Namballa / Computers & Industrial Engineering 48 (2005) 111–127
119
Fig. 7. Transition graph for the cell in Fig. 1.
the transition function d( ) and the set of events S. These events describe the part movements from machines to the robot (unloading) and from the robot to the machines (loading). Distinguishing between the failed, unload or processing states is accomplished by checking the attributes of each resource’s object representation. The fail_resource( ), determine_failuretype( ) and repair_resource( ) methods are invoked based on the changes in machine attributes that reflect the different stages of a failure. These methods invoke resource_failed( ) and resource_repaired( ) methods of the supervisor class to update the supervisory control logic. 3.2. Logical object classes 3.2.1. Event handler class The event handler object is used as an interface between the cell and the supervisory controller. The event handler monitors the cell’s objects’ attributes and queues the corresponding signals to be processed by the supervisor. In finite automata theory, the supervisor observes the events that transition the objects between states; i.e. a, b, c, a, d, e,. as in Fig. 5. In real manufacturing systems, this is often not the case. Instead, the current state of the object is observed. The transition that has occurred is known only by implication; i.e. by knowledge of the prior state and the current state of the machines. The attributes of the machine class are intended to represent a set of PLC tags (idle, processing, unload, failed). The tag value domain (0, 1) indicates whether the state is false or true. The machine can only be in one state at a time. The event handler object determines the event request to be sent to the supervisor for evaluation based on the state changes of the machines. Table 1 describes the sequence of state changes for machines and the corresponding event requests sent to the supervisor. Note that when a machine goes from the failed to the idle state, keeping track of only the last state leads to ambiguity as to the signal sent to the supervisor. This can correspond to a failure in the idle mode that is repaired without any parts being scrapped or a failure in the busy mode where the part is scrapped and the machine returns to the system as idle. This ambiguity is resolved by checking the part_on_machine attribute and the remaining_processing_time attribute of the repaired machine. The event handler also maintains the simulation clock through the clock attribute. The simulation clock is advanced using the update_time( ) method. The event_marked[ ] array, indexed by time, describes the events scheduled to occur at a given time. The mark_event( ) method is used by the machine objects to schedule their unload requests at appropriate times and updates the next_event_time attribute to reflect the earliest time that an event is scheduled. The unmark_event( ) method is used in
120
A. Yalcin, R.K. Namballa / Computers & Industrial Engineering 48 (2005) 111–127
Table 1 State changes and corresponding events Sequence of state changes
Corresponding signal sent to supervisor
Idle/processing Unload/idle Processing/unload Idle/failed Unload/failed Processing/failed Failed/processing Failed/unload Failed/idle
Part loaded on machine Part unloading complete Part move request Resource failed in idle mode Resource failed in unload mode Resource failed in processing mode Resource repaired Resource repaired Resource repaired
case of a failure to reschedule the events associated with the failed resource. For example, if a resource fails during the processing of a part, then the completion event of the part must be unmarked if the part is scrapped or delayed if it is not scrapped. The trigger_event( ) is invoked at the advancement of simulation time and initiates one of five types of possible scheduled events, namely loading, unloading, failure, failure clearance and repair by modifying the attributes of associated objects. 3.2.2. Supervisor class The supervisor class uses the evaluate_move_request( ) and evaluate_newpart_request( ) methods to evaluate the corresponding requests from the cell it is associated with. The methods shuffle( ) and trim( ) are private to the supervisor and are used by the evaluate_newpart_request( ) method to generate the control pattern for the set of parts being processed by the cell. The controller can be viewed as a state transition machine that determines which events are allowed to occur next according to the present state of the system and the given production requirements schedule. The control strategy is implemented using the fundamental tools of finite automata theory, as described in (Boucher et al., 2000; Yalcin & Boucher, 2000). An example is included below to illustrate the workings of the supervisor object and establish the relationship between the supervisory control theory in Yalcin and Boucher (2000) and its object-oriented realization. Consider the cell and the finite automaton G representing the cell as described in Section 3.1.5. Assume that there are two part types being processed in the system. Part A has to visit M1 and M2, each of them once, in either order. Part B has to visit M1 and M2 in that order. The FA models for the routings of the parts are shown in Fig. 8. The FA model of each process plan explicitly depicts all the possible routes a part may take for complete processing. The supervisor object uses the shuffle( ) method to generate the requirements model from the finite automata models of the parts in the cell. Whenever the event handler signals the supervisor that a new part is ready for processing in the input buffer via the make_newpart_request( ), the supervisor shuffles the requirements model of the remaining parts in the cell and the finite automaton model of the new part. The shuffle operation yields the new requirements model that includes all possible processing sequences of the parts in the system. The requirements model, represented by the finite automaton SZ(S, X, x, x0, Xm), contains illegal states (in which more than one part is on the same machine) or deadlocked states. In order to eliminate the illegal states, the requirements model S is coupled with the cell model G resulting in a new finite automaton S/GZ(S, Q!X, d!x, qc!x0, Qm!Xm), where qc is the current state of the plant model.
A. Yalcin, R.K. Namballa / Computers & Industrial Engineering 48 (2005) 111–127
121
Fig. 8. Part routing and Finite Automata models for part types A and B.
Fig. 9 shows the requirements model and the corresponding coupled cell model for our example system when a part of type A is in the state a2 and a new part of type B enters the cell. The marked language of the coupled system, denoted by Lm(S/G), consists of the marked sequence of events that take the coupled system from initial state to the combined final state where all parts are processed and unloaded (Yalcin & Boucher, 2000). In order to eliminate deadlock states, i.e. a2b1, bi, from the coupled model, and determine Lm (S/G), the trim( ) method is used to obtain the deadlock-free maximally permissive control pattern to control the cell. The resulting deadlock-free control pattern for the models in Fig. 9 is shown in Fig. 10.
Fig. 9. Finite Automate models for S and S/G.
122
A. Yalcin, R.K. Namballa / Computers & Industrial Engineering 48 (2005) 111–127
Fig. 10. The resulting Supervisory Control Pattern implementing Lm(S/G).
Whenever there is a request to move a part in the cell from one machine to another, the supervisor controller object would use evaluate_move_request( ) method to check the table indexed by the current state of the supervisor and the event. A ‘1’ in the corresponding table entry would validate the request and a presence of ‘0’ would mean denial of the request. Modeling of failures using the afore-mentioned finite-automata representation would require the modification of the plant model to denote the unavailability of a resource due to the failure. This would increase the state space of the plant model from 2nK1 to 6nK1 and the size of the coupled model S/G would also be compounded in size. The proposed object-oriented implementation handles failures efficiently in real-time by applying a ‘mask’ disabling all the transitions from the control pattern that load or unload the failed resource (Yalcin, 2004). This ‘mask’ is implemented through the machine_failed( ) method. To illustrate this approach, consider an automated manufacturing cell with four machines and a robot that loads and unloads these machines similar to the cell depicted in Fig. 6. In addition to parts A and B in Fig. 8, another part C is considered. The transition graph of the finite automata model for Part C is depicted in Fig. 11. Consider a point in time when part A is in state a6, part B is in state b2 and part C is in state c2. At this point the current state of the requirements model is a6b2c2 and the current state of the cell model is bbbii. The supervisory control pattern transition graph is shown in Fig. 12. Assume machine 3 fails while part C is being processed. When the failure signal is received, the events M3R1 and R1M3 are ‘masked’ and disabled until the resource is repaired. The only event allowed in state a6b2c2 by the supervisor is M2R1. Event sequence M2R1-R101 is the only allowable sequence and will be executed. In state afb2c2 there
Fig. 11. Transition graph for Part C.
A. Yalcin, R.K. Namballa / Computers & Industrial Engineering 48 (2005) 111–127
123
Fig. 12. Transition graph of the allowable events in the supervisory controller.
are two events allowable, M3R1 associated with part C and M1R1 associated with part B. Assuming machine 3 is still in the failed state, only M2R1, B is allowed. When the system reaches state afbfc2, iibii the system is blocked and must wait until machine 3 is repaired to finish processing part C. Upon receiving a repair signal, the mask is removed and the plant returns to its normal operation using the resource_repaired( ) method. If the failure causes the part on the machine to be scrapped, a new control pattern is generated based on the requirements of the remaining parts in the cell and the state of the machine is set to idle by modifying the objects attributes. If the failure is in the idle mode or the part is not scrapped no action is necessary until the resource is repaired where the attributes of the repaired resource is updated (Yalcin, 2004). A subtle point arises when a resource fails and the part on the robot at that time requires the use of the failed resource. This situation is handled by placing the part back to the resource it came from and returning the state of the supervisor, the cell, the part and the involved resource to their respective states
124
A. Yalcin, R.K. Namballa / Computers & Industrial Engineering 48 (2005) 111–127
before the part was picked up. If both the destination resource and the resource where the part was picked up from fail during the transportation of the part, the robot has no choice but to wait until one of the resources is repaired.
4. System simulation 4.1. Simulation inputs The input files to the simulation describe the processing times and the routing of the part types in the cell representing the full set of alternative production sequences for the parts. There are two types of files. The partplantstate[i].txt specifies the machine which can perform the required operation on part type i in a particular state. The partprocessplan[i].txt describes the state transitions for the part type i and the processing time for that part in each state. Together, they contain all the information to generate the corresponding Finite Automata models of the parts. At the beginning of each simulation, the user also specifies the number of machines in the cell model and the number of parts to be processed in the plant during the simulation. The user may also simulate resource failures in the plant by specifying failure-rates and repair rates for the resources. These set of details are complete in themselves in describing the structure and behavior of the plant comprehensively. The constructor of the cell class is used as an initialization procedure to create the buffer, the machine, the material handler and the part objects that form the cell object, and to create certain informationarrays from the input files. These arrays capture all the information on the cell behavior and are henceforth, used by the supervisor to formulate a control strategy. 4.2. Simulation logic The simulation logic is implemented in the object-oriented model through the updating of the attributes of the component objects and the interactions among these components are modeled through the message-passing facility in the object-oriented approach. The event handler object monitors the buffers and the machines in the cell and queues and relays appropriate event signals to the supervisor object. The supervisor object then evaluates the request based on the current state of the system and the control strategy and sends back the decision to allow/disallow the request back to the cell object, which executes the move if it is allowed. If the move is not allowed, it is sent to the end of the queue of events requested in the event handler object to be evaluated again when the system state changes. The flow of information within the simulation is illustrated in Fig. 13. The simulation starts with the arrival of a part to the input buffer. The event handler sends the load new part signal to the supervisor based on the change in the buffer object’s attributes. The supervisor generates a new control pattern, evaluates the move requested using the evaluate_newpart_request( ) and the evaluate_move_request( ) methods. The response is evaluated by the evaluate_response( ) method of the cell, and if it is allowed, the execute_event( ) method of the material handler, load_machine( ) method of the cell and load_part( ) method of the machine are sequentially invoked. The current states of the cell, the machine and the part are updated using their respective update_state( ) methods. Based on the processing time of the required operation, the mark_event( ) method of the event handler object schedules the part to be unloaded when the processing is complete. When the simulation
A. Yalcin, R.K. Namballa / Computers & Industrial Engineering 48 (2005) 111–127
125
Fig. 13. Flow of information within the simulation.
clock reaches that time epoch, trigger_event( ) method of the event handler updates the machine attribute unload to 1 and processing to 0, which initiates a new move request and the cycle continues until all scheduled parts are processed. Machine failures are scheduled according to the failure times that are generated randomly as a function of a failure rate specified by the user prior to the simulation. The event handler object monitors these events by monitoring each machine’s attributes. When the simulation clock reaches the time epoch at which a machine is ‘scheduled’ to fail, the failed attribute is set by the trigger_event( ) method. The fail_resource( ) method of the cell is invoked and the event handler signals the supervisor to indicate the failure of the machine. The resource_failed( ) method of the supervisor object disables the events requiring this machine via implementing a mask. The event_handler sends another request to the supervisor if the part is scrapped. The supervisor then generates a new control pattern considering the scrapped part. When the machine is repaired, this event is also relayed to the supervisor in a similar fashion to the failure event and the system returns to normal operation status and processing of the part resumes. A detailed description of the simulation software and the source code is available in Namballa and Yalcin (2004).
126
A. Yalcin, R.K. Namballa / Computers & Industrial Engineering 48 (2005) 111–127
4.3. Simulation outputs The output produced by the simulation model is captured in data files and includes event trace information, system performance information, and supervisory controller computation complexity information. The trace information includes a trace of the events ordered by time for understanding the behavior of the system. The system performance information includes measures such as the throughput, resource utilization, etc. Also, included are the state space and response time of the supervisory controller to keep track of computational complexity.
5. Summary and conclusions Integration of control requirements into plant simulation models requires modeling the plant in terms of events that have to be monitored, recorded, and used for control. In this paper we describe an objectoriented approach to the design of flexible manufacturing system simulation that allow the implementation of control logic during the system design phase. The object-oriented design approach is structured around formal supervisory control theory. While object-oriented design approaches have several advantages for software development, especially in specifying intra-object relationships, the interactions between objects in a complex system are difficult to capture. The formalisms in supervisory control theory are utilized to capture and implement these inter-object interactions. We have described a design platform that allows a design engineer to design and evaluate the impact of different control programs on factory performance. Important contributions of this work are: (1) the development of an extendable object-oriented manufacturing system simulation framework, (2) the design of simulation objects that properly communicate state information and service requests to a supervisory controller, (3) the design of a supervisory control object model based on formal methods that can service a range of flexible manufacturing systems, and (4) addresses subtle implementation issues such as dynamic routing flexibility, deadlock resolution, use of PLCs and diagnostic procedures in repairs allowing the simulated control code to be used as a real-time supervisory controller for the actual system. Complementary to and different from other proposed object-oriented manufacturing system simulations in the literature, the implementation of simulation logic that incorporates a range of realistic resource failures and failure recovery procedures while sustaining desirable logical properties of the system such as deadlock-freeness and proper termination is a novel contribution.
References Bodner, D. A., Dilley-Schneider, S. J., Narayanan, S., Sreekanth, U., McGinnis, L. F., Mitchell, C. M., & Govindaraj, T. (1993). Object-oriented modeling and simulation of automated control in manufacturing. Proceedings of the 1993 IEEE international conference on robotics and automation (Vol. 3, pp. 83–88). Washington, DC: IEEE Computer Society Press. Borenstein, D. (2000). Implementation of an object-oriented tool for the simulation of manufacturing systems and its application to study the effects of flexibility. International Journal of Production Research, 38(9), 2125–2142. Boucher, T. O., Yalcin, A., & Tai, T. (2000). Dynamic routing and the performance of automated manufacturing cells. IIE Transactions, 32(10), 975–988. Buttler, G. F., & Corbin, M. J. (1991). Introduction to object-oriented simulation. IEEE Colloquium on Object-Oriented Simulation and Control, 1/1–1/3.
A. Yalcin, R.K. Namballa / Computers & Industrial Engineering 48 (2005) 111–127
127
Deuermeyer, B., Curry, G., Duchowski, A. T., & Venkatesh, S. (1997). An automatic approach to deadlock detection and resolution in discrete simulation systems. INFORMS Journal on Computing, 9(2), 195–205. Hill, D. R. C. (1996). Object-oriented analysis and simulation. Reading, MA: Addison-Wesley. Jones, J. A., & Powell, K. A. (1993). Building object-oriented simulations with CCC. Proceedings of the Winter simulation conference, Los Angeles, 79–88. Joshi, S. B., Smith, J. S., Wysk, R. A., Peters, B. A., & Pegden, C. D. (1995). RapidCIM: An approach to rapid development of control software for FMS control. 27th CIRP international seminar on manufacturing systems, Ann Arbor, MI . Kelton, W. D., Sadowski, R. P., & Sadowski, D. A. (2001). Simulation with Arena. New York: McGraw-Hill. Moreno-Lizaranzu, M. J., Wysk, R. A., Hong, J., & Prabhu, V. V. (2001). A hybrid shop-floor control system for food manufacturing. IIE Transactions, 33, 193–202. Namballa R., & Yalcin A (2004). Source codes for object-oriented implementation of flexible manufacturing system simulation. University of South Florida, IMSE Department, http://www.eng.usf.edu/~ayalcin/object_oriented_cell_controller_simulation/. Narayanan, S., Bodner, D. A., Sreekanth, U., Govindaraj, T., McGinnis, L. F., & Mitchell, C. M. (1998). Research in objectoriented manufacturing simulations: An assessment of the state of the art. IIE Transactions, 30, 795–810. Smith, J. S., Hoberecht, W. C., & Joshi, S. B. (1996). A shop-floor control architecture for computer-integrated manufacturing. IIE Transactions, 28, 783–794. Smith, J. S., & Joshi, S. B. (1993). Message-based part state graphs (MPSG) for shop floor control. Proceedings of the second IIE research conference, Los Angeles, CA . System Modeling Corporation (1999). Arena professional edition reference guide, Swickley, PA. Tang, M. X., & Smithers, T. (1991). Towards object-oriented simulation. IEEE Colloquium on Object-Oriented Simulation and Control, 7/1–7/4. Venkatesh, S., Smith, J. S., Deuermeyer, B., & Curry, G. (1998). Deadlock detection and resolution for discrete-event simulation: Multiple-unit seizes. IIE Transactions, 30, 201–216. Yalcin, A. (2004). Re-configurable supervisory control of automated manufacturing cells with resource failures. Robotics and Computer Integrated Manufacturing, 20(2), 111–119. Yalcin, A., & Boucher, T. O. (2000). Deadlock avoidance in flexible manufacturing systems using finite automata. IEEE Transactions on Robotics and Automation, 16(4).