- Email: [email protected]
A methodology for creating a virtual model for a flexible manufacturing system
Computers in Industry 56 (2005) 734–746 www.elsevier.com/locate/compind
A methodology for creating a virtual model for a flexible manufacturing system Sang C. Park * Department of Industrial Information & Systems Engineering, Ajou University, San 5, Woncheon-dong, Yeongtong-gu, Suwon 443-749, Republic of Korea Received 27 May 2004; accepted 7 April 2005 Available online 5 July 2005
Abstract Proposed in the paper is an object-oriented methodology to create a virtual flexible manufacturing system (FMS) model. The proposed virtual FMS model consists of four types of objects: the virtual device model (object model), the transfer handler model ( functional model), the state manager model, and the flow controller model (dynamic model). A virtual device model consists of two parts: shell and core. To improve the reusability of a virtual device model, the shell part is designed to adapt to different FMS configurations. For the fidelity of the virtual FMS model, a transfer handler model has a set of device-level commands imitating the physical mechanism of a transfer. As a result, we can expect more accurate simulation results. The flow controller model makes decisions on firable transfers based on decision variables, which are maintained by the state manager model. For the implementation of the proposed virtual FMS model, this paper employs Discrete Event Systems Specifications (DEVS) formalism, which supports the specification of discrete event models in a hierarchical, modular manner. The proposed virtual FMS model has been implemented and tested with many examples. # 2005 Published by Elsevier B.V. Keywords: Virtual FMS; Virtual factory; FMS prototyping; FMS simulation
1. Introduction As product life cycles are reduced in the continuously changing marketplace, modern manufacturing systems must have sufficient responsiveness to adapt their behaviors efficiently to a wide range of circumstances [7]. To respond to these demands, including high productivity and production flexibility, * Fax: +82 31 219 1610. E-mail address: [email protected]. 0166-3615/$ – see front matter # 2005 Published by Elsevier B.V. doi:10.1016/j.compind.2005.04.002
the use of a flexible manufacturing system (FMS) has been widely accepted. A flexible manufacturing system is an integrated production system composed of automated workstations such as computer numerically controlled (CNC) machines with tool change capability, a hardware handling system and storage system, and a computer control system which controls the operations of the whole system. The design of an FMS requires high investment, and decisions at this stage have to be made very carefully to ensure that the highly automated
S.C. Park / Computers in Industry 56 (2005) 734–746
manufacturing system will successfully satisfy the demands of an ever-changing market. Simulation is an essential tool for the design and analysis of complex systems that cannot be easily described by analytical or mathematical models [3,4]. It is useful for calculating utilization statistics, finding bottlenecks, pointing out scheduling errors and even for creating manufacturing schedules. Traditionally, various simulation languages, including ARENA1 and AutoMod1, have been used for the simulation of manufacturing systems [2]. Since those simulation languages focus on the representation of independent entity flows (job flows) between processes, their approach is commonly referenced to as a transactionoriented approach. On the other hand, the objectoriented approach is based on a set of object classes that model the behavior of real system components. The object-oriented modeling (OOM) paradigm is a way of thinking based on modeling objects from the real world and then using the model to build a languageindependent design organized around those objects [8]. Since the OOM has fully demonstrated to be an effective technique for modeling complex software systems, quite a few researchers have tried to apply the OOM technique to the design and simulation of manufacturing systems. Narayanan et al. [17] reviewed diffused object-oriented methodologies to design manufacturing system software models. Their work also includes a framework of analysis for production system modeling. Kovacs et al. [1] used the objectoriented design paradigm to improve the reusability of FMS components. Anglani et al. [2] proposed a procedure to develop FMS simulation models, based on the unified modeling language (UML) analysis/ design tools and on the ARENA1 simulation language. One of the features of their research is that an objectoriented design phase is integrated with an implementation phase that is made with a common transactionoriented simulation language. Based on the OOM paradigm, different researchers have proposed various FMS modeling approaches despite the fact that they express them in different ways with different notations. For example, Choi et al. [6] proposed the JR-net modeling framework based on the OOM paradigm of Rumbaugh et al. [8], which consists of three sub-models (an object model, functional model, and dynamic model). The JR-net was developed to cope with the drawbacks of formal modeling tools (Petri-net, Event
735
Graph, ACD), such as modeling difficulty and nearintractability. Although the JR-net modeling framework is clearly defined and well-structured, the authors did not provide the implementation strategy. Chen and Lu [16] presented an object-oriented modeling methodology to design production systems by means of the Petri-nets, the entity relationship diagram (ERD) and the IDEF0. Other than the OOM paradigm [5,6], there is another very important concept which should be considered in today’s simulation environment. With the enormous improvement of computing power, many users want to create much more realistic simulation models, which can forecast not only the production capability of the system but also the physical validity and efficiency of co-working machines. The demand results in the concept of virtual factory (VF), which can be described as a model executing manufacturing processes in computers as well as the real world [7,11–15]. To implement a virtual FMS, it is necessary to construct digital models for all physical and logical elements (entities and activities) of a real FMS. Onosato and Iwata [11] identified two requirements of virtual manufacturing systems, which are application independence and structural analogy, and suggested the architecture of virtual manufacturing systems consisting of virtual physical systems and virtual informational systems. Iwata et al. [12] presented the architecture of virtual manufacturing systems for modeling and distributed simulation. Huang and Yeh [13] used the colored timed Petri-net (CTPN) to implement a virtual factory emulator. For the effective building of a virtual environment for simulation, Ye and Lin [14] proposed an approach of extracting the useful data from a twodimensional logical simulation. Lin et al. [15] tried to represent a virtual factory in an analytical form so that existing mathematical analysis could be applied. To summarize from the previous work on the topic of VF, some aimed at developing the overall concept and architecture of VF, while others focused on the modeling scheme of VF; however, these schemes are more conceptual than realistic, for their results are either too coarse or somewhat fragmentary. Obviously, we can benefit greatly from VF, but it is still difficult and time-consuming to build. The objective of this paper is to develop an objectoriented methodology for the modeling and simulation of a virtual FMS. For the implementation of the
736
S.C. Park / Computers in Industry 56 (2005) 734–746
proposed virtual FMS model, this paper employs DEVSIM++ [10], which is an object-oriented simulation language based on Zeigler’s DEVS formalism [9]. The overall structure of the paper is as follows. Section 2 presents the overall approach to the development of the virtual FMS model, and Section 3 gives a detailed description of the virtual FMS model. Some examples and illustrations are given in Section 4. Finally, concluding remarks are addressed in Section 5.
2. Approach to the virtual FMS model In developing the virtual FMS model, the first thing we have to consider is the user requirements. As shown in Fig. 1, this paper extracts the user requirements from the FMS prototyping process identified by interviewing FMS designers. FMS design starts with the system requirements including the products and capacity. Based on the system
requirements, FMS designers determine the manufacturing processes and the rough configurations of an FMS. Once the manufacturing processes are determined, then the layout design gets started. At this stage, it is desirable to make alternatives as many as possible, and that is why FMS designers need the interactive layout design functionality. The next step is to choose the most dominant layout among the alternatives. To do so, it is necessary to have a method to evaluate layouts to rank them, and the manual operation functionality can support this process. Once they determine the most dominant layout, then they start to design the supervisory control logic. With the control logic, they can analyze the performance by using the simulation functionality. If the performance meets the system requirements, they can make a plan for the implementation of the FMS. Otherwise, they have to go back to prior steps, such as layout design or control logic design steps. From the FMS designing procedure, nine requirements have been extracted: (1)
Fig. 1. FMS designer’s requirements.
S.C. Park / Computers in Industry 56 (2005) 734–746
737
Fig. 2. Three-phase modeling procedure.
layout design, (2) manual operation for layout evaluation, (3) flow control logic programming, (4) simulation for performance analysis, (5) planning for implementation of a real FMS, (6) fidelity for highquality simulation results, (7) reusability of the virtual FMS model, (8) modeling power, and (9) ease of construction. To develop a virtual FMS model, we need to choose a reference model for a common example of an FMS. As a reference model, this paper employs the threephase modeling framework suggested by Choi et al. [6]. The modeling framework is based on the objectoriented modeling paradigm of Rumbaugh et al. [8] and consists of three sub-models: static layout model (object model), job flow model (functional model), and supervisory control model (dynamic model). Fig. 2(a) shows the static model which is constructed by positioning two device symbols, a buffer and a machine. The job flow model, shown in Fig. 2(b), describes the part flow in the system by drawing arrows between device symbols. In Fig. 2(b), the solid line represents the flow of an unfinished part from the buffer to the machine, and the dotted line represents the flow of a finished part from the machine to the buffer. Fig. 2(c) shows the supervisory control model, which defines the firing conditions of each flow according to the system state. For example, the token bag, shown in Fig. 2(c), represents the availability of the machine to control the flow of the unfinished part from the buffer to the machine. The static layout model consists of manufacturing devices having their positions in the layout. To represent such a manufacturing device, this paper
employs the concept of a virtual device: a digital model imitating the physical and logical aspects of a real device. In designing a virtual device model, the most important measure should be the reusability of the components because a virtual device can be used for many different FMS configurations. Without the effective reusability feature of a virtual device, usually it is more natural to create new components from scratch than to search for useful elements in other systems. To achieve reusability, we split a virtual device into two parts, shell and core; the shell part can adapt to different FMS configurations and the core part undertakes inherent properties of the device, such as device controller (interpretation and execution of device-level commands), kinematics, and geometric shape. The rough concept of a virtual device is shown in Fig. 3. The job flow model is supposed to describe the flow (transfer) of parts and auxiliary resources (pallets and tools) between devices. Conventional approaches
Fig. 3. Outline of a virtual device model.
738
S.C. Park / Computers in Industry 56 (2005) 734–746
mainly focused on describing the firing condition of a transfer, and did not pay much attention on the physical mechanism enabling the transfer. In reality, a transfer happens by the combination of device-level commands between co-working devices (giving and taking devices). For the fidelity of the virtual FMS model, this paper models a transfer as an object, called a transfer handler, which includes a set of device-level commands enabling the transfer. As a result, we can check the mechanical validity of each transfer and also expect more accurate simulation results because the total time of each transfer will be computed from its physical mechanism (device-level commands). A device-level command can be considered as a program to operate a machine, such as industrial robots (offline programs) and CNC machines (NC programs). Fig. 4 shows the rough outline of a transfer handler model. The supervisory control model describes the control logic of an FMS which makes decisions on firable transfers based on the system state. The system state can be defined by the combination of the states of all virtual devices in the FMS, but this approach might cause an explosion of the state space. That is why we need to define decision variables, which can express meaningful system states. We employ two objects for the supervisory control model: (1) flow controller for making decisions on firable transfers based on the system state (decision variables) and (2) state manager for maintaining decision variables based on the mapping
Fig. 4. Outline of a transfer handler model.
relations between decision variables and the states of virtual devices in the system. Fig. 5 shows the overall structure of the proposed virtual FMS model. The virtual FMS model has four types of objects, virtual device (static layout model), transfer handler (job flow model), state manager, and flow controller (supervisory control model). For the implementation of the virtual FMS model, this paper employs Zeigler’s Discrete Event Systems Specifications (DEVS) formalism [9,10], which supports the specification of discrete event models in a hierarchical, modular manner. The semantics of the formalism are highly compatible with object-oriented specifications for simulation models. DEVSIM++ is a simulation environment which realizes the DEVS formalism for modeling and associated abstract simulator concepts for simulation, all in C++ [10]. We can simulate a
Fig. 5. Outline of the virtual FMS model.
S.C. Park / Computers in Industry 56 (2005) 734–746
DEVS model in the DEVSIM++ environment without implementing the simulation engine. The implementation strategy of this paper is to transform the virtual FMS model into a DEVS model and simulate the model with DEVSIM++. Within the DEVS formalism, one must specify two types of sub-models: (1) the atomic model, the basic models, from which larger ones are built and (2) the coupled model, how atomic models are connected in a hierarchical manner. Formally, an atomic model M is specified by a 7-tuple:
739
couple model DN is defined as: DN ¼ hX; Y; M; EIC; EOC; IC; SELECTi X : input events set; Y : output events set; M : set of all component models in DEVS; EIC DN:IN M:IN : external input coupling relation;
M ¼ hX; S; Y; dint ; dext ; l; ta i
EOC M:OUT DN:OUT : external output coupling relation;
X : input events set; S : sequential states set; Y : output events set;
IC M:OUT M:IN : internal coupling relation;
dint : S ! S : internal transition function;
SELECT : 2M ! M : tie-breaking selector;
dext : Q X ! S : external transition function Q ¼ fðs; eÞjs 2 S; 0 e ta ðsÞg: total state of M;
where the extensions .IN and .OUT represent the input ports set and the output ports set of respective DEVS models. For the implementation of the virtual FMS model, the four types of components (virtual device, transfer handler, state manager, and flow controller) will be represented as atomic models, and the whole virtual FMS model will be represented as a coupled model, including the atomic models and coupling relations between them. The detail specifications of the virtual FMS model are addressed in the following section.
l : S ! Y : output function; ta : S ! Real : time advance function: The four elements in the 7-tuple, namely dint, dext, l and ta, are called the characteristic functions of an atomic model. The second form of the model, called a coupled model, tells how to couple several component models together to form a new model. Formally, a
Fig. 6. Shell of a virtual device.
740
S.C. Park / Computers in Industry 56 (2005) 734–746
3. Virtual FMS model 3.1. Virtual device model As mentioned above, a virtual device consists of a shell part and a core part to improve the reusability. The shell part allows a virtual device model to adapt to different FMS configurations, and it encloses the core part which represents the inherent properties of a device, such as kinematics, geometric shape and the execution of device-level commands. The shell part needs to provide interfaces with two types of components, the state manager and the transfer handler, in the virtual FMS model. The shell part needs to report the state of the virtual device to the state manager whenever the state changes. While the relation between the shell part and the state manager is one-way communication (from the shell part to the state manager), the communication between the shell part and the transfer handler should be two-way. The transfer handler gives device-level commands to the shell part to control the virtual device, and it also receives feed back from the shell part, such as the result (success or failure) of the command execution. According to the FMS configuration, a virtual device can be related to multiple transfers. In this case, the shell part of the virtual device needs to communicate with multiple transfer handlers. Because of this, the shell part needs to be instantiated by considering the number of related transfers. Fig. 6 shows the state transition diagram of a shell part having two related transfers (transfer handler i and transfer handler j). Observe that it has two input ports from two transfer
handlers and it also has two output ports to the transfer handlers. For the state manager, there is only one output port to report the state of the virtual device. Fig. 6 shows the stage transition diagram, and the corresponding DEVS atomic model can be described as follows. For the implementation details, one can refer to the DEVSIM++ user’s manual [10]. Shell of a virtual device : M ¼ hX; S; Y; dint ; dext ; l; ta i X ¼ fTHi ; TH j g S ¼ fWait; Load command; Command executiong Y ¼ fSM; THi ; TH j g dint ðLoad commandÞ ¼ Command execution dint ðCommand executionÞ ¼ Wait dext ðWait; THi or TH j Þ ¼ Load command lðLoad commandÞ ¼ SM lðCommand executionÞ ¼ THi or TH j lðCommand executionÞ ¼ SM ta : S ! Real : time advance function The core part of a virtual device is enclosed by the shell part, and it represents the inherent properties (physical and logical elements) of a real device. For the physical aspects, the core part needs to have a geometric body with kinematics, such as moving joints (rotation or translation) and attributes of each moving joint including speed, acceleration and feasible moving range. To control the geometric body, we need to have a device controller which
Fig. 7. Core of a virtual device.
S.C. Park / Computers in Industry 56 (2005) 734–746
models the logical aspects of a device. The device controller should be able to execute device-level commands by operating the geometric body. In the case of a NC machine, the device controller should be able to interpret NC commands, such as M-codes, G-codes, and APT commands. For example, ‘‘G00 X050.0 Y086.5 Z100.0’’ is a G-code command ordering a rapid tool movement to the position of (X = 50.0, Y = 86.5, Z = 100.0). An example of the core part is shown in Fig. 7. 3.2. Transfer handler model
741
definition of the DEVS atomic model corresponding to the transfer handler model, shown in Fig. 8, can be described as follows: Transfer handler : M ¼ hX; S; Y; dint ; dext ; l; ta i X ¼ fFC; VDi ; VD j g S ¼ fWait; Next command; Issue commandg Y ¼ fVDi ; VD j g dint ðNext commandÞ ¼ Issue command
A transfer handler model has a set of device-level commands enabling a transfer between two devices, giving and taking devices. A transfer handler model needs to communicate with the flow controller and a pair of virtual devices. As shown in Fig. 8, a transfer handler has an input port (FC) from the flow controller through which a firing signal activates the transfer. Once a firing signal comes in, the transfer handler finds device-level commands which will be delivered to corresponding virtual devices through two output ports (VDi, VDj). When the virtual devices complete the ordered commands, they inform the transfer handler of the end of commands through two input ports (VDi, VDj). Then, the transfer handler finds the next command to be executed. These steps are repeated until the transfer is completed. The formal
dint ðIssue commandÞ ¼ Next command or Wait dext ðWait; FCÞ ¼ Next command lðIssue commandÞ ¼ VDi or VD j ta : S ! Real : time advance function For the fidelity of the virtual FMS model, a transfer handler performs a transfer by the combination of device-level commands. Since the virtual FMS model performs a transfer in a very realistic manner, we can even check the validity of the physical mechanism of a transfer, and also expect more accurate simulation results. Fig. 9 shows an example of a transfer between a robot and a CNC machine.
Fig. 8. Transfer handler model.
742
S.C. Park / Computers in Industry 56 (2005) 734–746
Fig. 9. An example of a transfer.
3.3. Flow controller and state manager For controlling an FMS, the virtual FMS model introduces two types of components, the state manager and flow controller. The state manager
maintains decision variables representing the FMS state, and the flow controller chooses firable transfers according to the decision variables. As shown in Fig. 10, the state manager needs to have k input ports, where k is the number of virtual devices belonging to
Fig. 10. State manager and flow controller.
S.C. Park / Computers in Industry 56 (2005) 734–746
the virtual FMS model. Whenever there is a state change of a virtual device, it should report to the state manager through the corresponding input port. Then, the state manager needs to reflect the change to the decision variables by using the mapping relations between the decision variables and the states of virtual devices. If there are any changes in the decision variables, the state manager should report to the flow controller through the only output port (FC). The state manager may play an important role in planning the real FMS implementation, especially in planning the design of sensory equipment. The formal definitions of the DEVS atomic models corresponding to the flow controller and the state manager, shown in Fig. 10, can be described as follows: Flow controller : M ¼ hX; S; Y; dint ; dext ; l; ta i X ¼ fSMg S ¼ fWait; Firable transferg
743
there is a firable transfer, the flow controller gives an order to fire the transfer through the corresponding output port. For the decision making, it is necessary to specify the firing condition of each transfer. 3.4. Virtual FMS model As mentioned above, a virtual FMS model consists of four types of objects, virtual device (static layout model), transfer handler (job flow model), state manager and flow controller (supervisory control model). While the four types of objects are implemented as atomic models, the whole virtual FMS model is implemented as a coupled model, including those atomic models and coupling relations between them. Fig. 11 shows a simple example of a virtual FMS model including two virtual devices, one transfer handler. The formal definitions of the DEVS coupled model corresponding to the virtual FMS model, shown in Fig. 11, can be described as follows.
Y ¼ fTH1 ; TH2 ; . . . ; THn g; where n is the number of transfer handlers dint ðFirable transferÞ ¼ Wait
Virtual FMS : DN ¼ hX; Y; M; EIC; EOC; IC; SELECTi
dext ðWait; SMÞ ¼ Firable transfer
X ¼ fg;
lðFirable transferÞ ¼ TH1 or TH2 or . . . or THn
M :¼ fVDI ; VDJ ; THIJ ; SM; FCg
ta: S ! Real: time advance function
EIC ¼ fg;
Y ¼ fg
EOC ¼ fg
State manager : M ¼ hX; S; Y; dint ; dext ; l; ta i X ¼ fVD1 ; VD2 ; . . . ; VDk g; where k is the number virtual devices S ¼ fWait; Updateg Y ¼ fFCg dint ðUpdateÞ ¼ Wait
IC ¼ fðSM:O1 FC:I1Þ; ðFC:O1 THIJ:I1Þ; ðTHIJ:O1 VDI:I1Þ; ðTHIJ:O2 VDJ:I1Þ; ðVDI:O1 SM:I1Þ; ðVDI:O2 THIJ:I2Þ; ðVDJ:O1 SM:I2Þ; ðVDJ:O2 THIJ:I3Þg SELECT: 2M ! M: tie-breaking selector;
dext ðWait; VD1 or VD2 or . . . or VDk Þ ¼ Update lðUpdateÞ ¼ FC ta: S ! Real: time advance function The flow controller has one input port from the state manager, and n output ports, where n is the number of transfer handlers in the system, as shown in Fig. 10. Whenever the stage manager reports a state change of the system, the flow controller makes a decision on firable transfers based on the flow control logic. If
4. Examples and illustrations The proposed virtual FMS model has been implemented and tested with various examples to prove its usefulness. For the simulation of the virtual FMS model, this paper employs Zeigler’s DEVS formalism. We used C++ language in a Visual Studio environment and OpenGL for the graphical rendering. The virtual FMS line shown in Fig. 12 is a mechanical
744
S.C. Park / Computers in Industry 56 (2005) 734–746
Fig. 11. A virtual FMS model.
Fig. 12. Mechanical parts machining line.
S.C. Park / Computers in Industry 56 (2005) 734–746
745
Fig. 13. Virtual device modeling and execution.
parts machining line with four machining centers and a washing machine. While the transfer handler, the state manager, the flow controller, and the controller of a virtual device can be implemented by programming in the DEVSIM++ environment, the geometric body of a virtual device requires solid modeling functionalities. For the modeling of the geometric body of a virtual device, the constructive solid geometry (CSG) modeling scheme was employed. In the CSG modeling scheme, a user can interactively construct a solid model by combining various primitives, such as cylinders, spheres, boxes, and cones. To imitate the kinematics of a real device, it is necessary to define the moving joints and the attributes of each joint. We can verify a virtual device by executing it with a real device program, as shown in Fig. 13. Our final goal is to provide a library containing all standard manufacturing devices, such as machining stations, AGVs, and robots. Therefore, users can easily instantiate virtual devices, without making efforts for modeling virtual devices.
5. Discussion and conclusions This paper presents an object-oriented methodology for the modeling and simulation of a virtual FMS. For the implementation of the proposed virtual FMS model, the paper employs DEVSIM++ which is an object-oriented simulation language based on Zeigler’s DEVS formalism. The OOM paradigm of Rumbaugh uses three kinds of models to describe a system: the object model, describing the objects in the system and their relationships; the dynamic model, describing the interactions among objects in the system; and the functional model, describing the data transformations of the system. The proposed virtual FMS model follows the OOM paradigm and uses four types of components: the virtual device model corresponding to the object model, the transfer handler model corresponding to the functional model, and the state manager and flow controller model corresponding to the dynamic model. A virtual device is designed considering reusability, and the device consists of two parts: shell and core.
746
S.C. Park / Computers in Industry 56 (2005) 734–746
The shell part allows a virtual device model to adapt to different FMS configurations, and it encloses the core part which contains the inherent properties of a device, such as kinematics, geometric shape, and the execution of device-level commands. For the fidelity of the virtual FMS model, a transfer handler model has a set of device-level commands imitating the physical mechanism of a transfer. As a result, we can check the mechanical validity of each transfer and also expect more accurate simulation results, because the total time of each transfer will be computed from its physical mechanism. The flow controller model makes decisions on firable transfers based on decision variables, which are maintained by the state manager model. To maintain the decision variables, the state manager stores mapping relations between decision variables and the states of virtual devices in the system. The mapping relations can serves as the guidelines for the planning of a real FMS implementation.
[8]
[9] [10] [11]
[12]
[13]
[14]
[15]
Reference [16] [1] G.L. Kovacs, S. Kopacsi, J. Nacsa, G. Haidegger, P. Groumpos, Application of software reuse and object-oriented methodologies for the modeling and control of manufacturing systems, Computers in Industry 39 (1999) 177–189. [2] A. Anglani, A. Grieco, M. Pacella, T. Tolio, Object-oriented modeling and simulation of flexible manufacturing system: a rule-based procedure, Simulation Modeling Practice and Theory 10 (2002) 209–234. [3] P. Klingstam, P. Gullander, Overview of simulation tools for computer-aided production engineering, Computers in Industry 38 (1999) 173–186. [4] A.M.A. Al-Ahmari, K. Ridgway, An integrated modeling method to support manufacturing system analysis and design, Computers in Industry 38 (1999) 225–238. [5] C. Ou-Yang, T.Y. Guan, J.S. Lin, Developing a computer shop floor control model for a CIM system-using object modeling technique, Computers in Industry 41 (2000) 213–238. [6] B.K. Choi, Kwan H. Han, Tea Y. Park, Object-oriented graphical modeling of FMSs, The International Journal of Flexible Manufacturing Systems 8 (1996) 159–182. [7] B.K. Choi, B.H. Kim, New trends in CIM: virtual manufacturing systems for next generation manufacturing, in: Current
[17]
Advances in Mechanical Design and Production Seventh Cairo University International MDP Conference, Cairo, February 15–17, 2000, pp. 425–436. J. Rumbaugh, M. Blaha, W. Premerlani, W. Losenson, ObjectOriented Modeling and Design, Prentice Hall Inc., Englewood Cliffs, NJ, 1991. B.P. Zeigler, Multifacetted Modeling and Discrete Event Simulation, Academic Press, Orland, 1984. T.G. Kim, DEVSIM++ User’s Manual, Department of Electrical Engineering, KAIST, Korea, 1994. M. Onosato, K. Iwata, Development of a virtual manufacturing system by integrating product models and factory models, CIRP 42 (1) (1993) 475–478. K. Iwata, M. Onosato, K. Teramoto, S. Osaki, A modeling and simulation architecture for virtual manufacturing systems, CIRP 44 (1) (1995) 399–402. H. Huang, C. Yeh, Development of a virtual factory emulator based on three-tire architecture, in: IEEE International Conference on Robotics & Automation, Detroit, MI, May, 1999, pp. 2434–2439. L. Ye, F. Lin, Virtual system simulation—a step beyond the conventional simulation, in: 22nd International Conference on Computer and Industrial Engineering, 20 December, 1997, 304–306. M. Lin, L. Fu, T. Shih, Virtual Factory—a novel testbed for an advanced flexible manufacturing system, in: IEEE International Conference on Robotics & Automation, Detroit, MI, May, 1999, pp. 2422–2427. K.Y. Chen, S.S. Lu, A Petri-net and entity-relationship diagram based object-oriented design method for manufacturing systems control, International Journal of Computer Integrated Manufacturing 10 (1–4) (1997) 17–28. S. Narayanan, D.A. Bodner, U. Sreekanth, T. Govindaraj, L.F. McGinnis, C.M. Mitchell, Research in object-oriented manufacturing simulations: an assessment of the state of the art, IIE Transaction 30 (9) (1998) 795–810.
Sang C. Park is an assistant professor in the Department of Industrial & Information Systems Engineering at Ajou University. Before joining Ajou, he worked for DaimlerChrysler Corp. and CubickTek Co., developing commercial and inhouse CAD/CAM/CAPP/simulation software systems. He received his BS, MS, and PhD degrees from KAIST in 1994, 1996, and 2000, respectively, all in industrial engineering. His research interests include geometric algorithms in CAD/CAM, process planning, engineering knowledge management, and discrete event system simulation. He can be reached via email at [email protected].
A methodology for creating a virtual model for a flexible manufacturing system Sang C. Park * Department of Industrial Information & Systems Engineering, Ajou University, San 5, Woncheon-dong, Yeongtong-gu, Suwon 443-749, Republic of Korea Received 27 May 2004; accepted 7 April 2005 Available online 5 July 2005
Abstract Proposed in the paper is an object-oriented methodology to create a virtual flexible manufacturing system (FMS) model. The proposed virtual FMS model consists of four types of objects: the virtual device model (object model), the transfer handler model ( functional model), the state manager model, and the flow controller model (dynamic model). A virtual device model consists of two parts: shell and core. To improve the reusability of a virtual device model, the shell part is designed to adapt to different FMS configurations. For the fidelity of the virtual FMS model, a transfer handler model has a set of device-level commands imitating the physical mechanism of a transfer. As a result, we can expect more accurate simulation results. The flow controller model makes decisions on firable transfers based on decision variables, which are maintained by the state manager model. For the implementation of the proposed virtual FMS model, this paper employs Discrete Event Systems Specifications (DEVS) formalism, which supports the specification of discrete event models in a hierarchical, modular manner. The proposed virtual FMS model has been implemented and tested with many examples. # 2005 Published by Elsevier B.V. Keywords: Virtual FMS; Virtual factory; FMS prototyping; FMS simulation
1. Introduction As product life cycles are reduced in the continuously changing marketplace, modern manufacturing systems must have sufficient responsiveness to adapt their behaviors efficiently to a wide range of circumstances [7]. To respond to these demands, including high productivity and production flexibility, * Fax: +82 31 219 1610. E-mail address: [email protected]. 0166-3615/$ – see front matter # 2005 Published by Elsevier B.V. doi:10.1016/j.compind.2005.04.002
the use of a flexible manufacturing system (FMS) has been widely accepted. A flexible manufacturing system is an integrated production system composed of automated workstations such as computer numerically controlled (CNC) machines with tool change capability, a hardware handling system and storage system, and a computer control system which controls the operations of the whole system. The design of an FMS requires high investment, and decisions at this stage have to be made very carefully to ensure that the highly automated
S.C. Park / Computers in Industry 56 (2005) 734–746
manufacturing system will successfully satisfy the demands of an ever-changing market. Simulation is an essential tool for the design and analysis of complex systems that cannot be easily described by analytical or mathematical models [3,4]. It is useful for calculating utilization statistics, finding bottlenecks, pointing out scheduling errors and even for creating manufacturing schedules. Traditionally, various simulation languages, including ARENA1 and AutoMod1, have been used for the simulation of manufacturing systems [2]. Since those simulation languages focus on the representation of independent entity flows (job flows) between processes, their approach is commonly referenced to as a transactionoriented approach. On the other hand, the objectoriented approach is based on a set of object classes that model the behavior of real system components. The object-oriented modeling (OOM) paradigm is a way of thinking based on modeling objects from the real world and then using the model to build a languageindependent design organized around those objects [8]. Since the OOM has fully demonstrated to be an effective technique for modeling complex software systems, quite a few researchers have tried to apply the OOM technique to the design and simulation of manufacturing systems. Narayanan et al. [17] reviewed diffused object-oriented methodologies to design manufacturing system software models. Their work also includes a framework of analysis for production system modeling. Kovacs et al. [1] used the objectoriented design paradigm to improve the reusability of FMS components. Anglani et al. [2] proposed a procedure to develop FMS simulation models, based on the unified modeling language (UML) analysis/ design tools and on the ARENA1 simulation language. One of the features of their research is that an objectoriented design phase is integrated with an implementation phase that is made with a common transactionoriented simulation language. Based on the OOM paradigm, different researchers have proposed various FMS modeling approaches despite the fact that they express them in different ways with different notations. For example, Choi et al. [6] proposed the JR-net modeling framework based on the OOM paradigm of Rumbaugh et al. [8], which consists of three sub-models (an object model, functional model, and dynamic model). The JR-net was developed to cope with the drawbacks of formal modeling tools (Petri-net, Event
735
Graph, ACD), such as modeling difficulty and nearintractability. Although the JR-net modeling framework is clearly defined and well-structured, the authors did not provide the implementation strategy. Chen and Lu [16] presented an object-oriented modeling methodology to design production systems by means of the Petri-nets, the entity relationship diagram (ERD) and the IDEF0. Other than the OOM paradigm [5,6], there is another very important concept which should be considered in today’s simulation environment. With the enormous improvement of computing power, many users want to create much more realistic simulation models, which can forecast not only the production capability of the system but also the physical validity and efficiency of co-working machines. The demand results in the concept of virtual factory (VF), which can be described as a model executing manufacturing processes in computers as well as the real world [7,11–15]. To implement a virtual FMS, it is necessary to construct digital models for all physical and logical elements (entities and activities) of a real FMS. Onosato and Iwata [11] identified two requirements of virtual manufacturing systems, which are application independence and structural analogy, and suggested the architecture of virtual manufacturing systems consisting of virtual physical systems and virtual informational systems. Iwata et al. [12] presented the architecture of virtual manufacturing systems for modeling and distributed simulation. Huang and Yeh [13] used the colored timed Petri-net (CTPN) to implement a virtual factory emulator. For the effective building of a virtual environment for simulation, Ye and Lin [14] proposed an approach of extracting the useful data from a twodimensional logical simulation. Lin et al. [15] tried to represent a virtual factory in an analytical form so that existing mathematical analysis could be applied. To summarize from the previous work on the topic of VF, some aimed at developing the overall concept and architecture of VF, while others focused on the modeling scheme of VF; however, these schemes are more conceptual than realistic, for their results are either too coarse or somewhat fragmentary. Obviously, we can benefit greatly from VF, but it is still difficult and time-consuming to build. The objective of this paper is to develop an objectoriented methodology for the modeling and simulation of a virtual FMS. For the implementation of the
736
S.C. Park / Computers in Industry 56 (2005) 734–746
proposed virtual FMS model, this paper employs DEVSIM++ [10], which is an object-oriented simulation language based on Zeigler’s DEVS formalism [9]. The overall structure of the paper is as follows. Section 2 presents the overall approach to the development of the virtual FMS model, and Section 3 gives a detailed description of the virtual FMS model. Some examples and illustrations are given in Section 4. Finally, concluding remarks are addressed in Section 5.
2. Approach to the virtual FMS model In developing the virtual FMS model, the first thing we have to consider is the user requirements. As shown in Fig. 1, this paper extracts the user requirements from the FMS prototyping process identified by interviewing FMS designers. FMS design starts with the system requirements including the products and capacity. Based on the system
requirements, FMS designers determine the manufacturing processes and the rough configurations of an FMS. Once the manufacturing processes are determined, then the layout design gets started. At this stage, it is desirable to make alternatives as many as possible, and that is why FMS designers need the interactive layout design functionality. The next step is to choose the most dominant layout among the alternatives. To do so, it is necessary to have a method to evaluate layouts to rank them, and the manual operation functionality can support this process. Once they determine the most dominant layout, then they start to design the supervisory control logic. With the control logic, they can analyze the performance by using the simulation functionality. If the performance meets the system requirements, they can make a plan for the implementation of the FMS. Otherwise, they have to go back to prior steps, such as layout design or control logic design steps. From the FMS designing procedure, nine requirements have been extracted: (1)
Fig. 1. FMS designer’s requirements.
S.C. Park / Computers in Industry 56 (2005) 734–746
737
Fig. 2. Three-phase modeling procedure.
layout design, (2) manual operation for layout evaluation, (3) flow control logic programming, (4) simulation for performance analysis, (5) planning for implementation of a real FMS, (6) fidelity for highquality simulation results, (7) reusability of the virtual FMS model, (8) modeling power, and (9) ease of construction. To develop a virtual FMS model, we need to choose a reference model for a common example of an FMS. As a reference model, this paper employs the threephase modeling framework suggested by Choi et al. [6]. The modeling framework is based on the objectoriented modeling paradigm of Rumbaugh et al. [8] and consists of three sub-models: static layout model (object model), job flow model (functional model), and supervisory control model (dynamic model). Fig. 2(a) shows the static model which is constructed by positioning two device symbols, a buffer and a machine. The job flow model, shown in Fig. 2(b), describes the part flow in the system by drawing arrows between device symbols. In Fig. 2(b), the solid line represents the flow of an unfinished part from the buffer to the machine, and the dotted line represents the flow of a finished part from the machine to the buffer. Fig. 2(c) shows the supervisory control model, which defines the firing conditions of each flow according to the system state. For example, the token bag, shown in Fig. 2(c), represents the availability of the machine to control the flow of the unfinished part from the buffer to the machine. The static layout model consists of manufacturing devices having their positions in the layout. To represent such a manufacturing device, this paper
employs the concept of a virtual device: a digital model imitating the physical and logical aspects of a real device. In designing a virtual device model, the most important measure should be the reusability of the components because a virtual device can be used for many different FMS configurations. Without the effective reusability feature of a virtual device, usually it is more natural to create new components from scratch than to search for useful elements in other systems. To achieve reusability, we split a virtual device into two parts, shell and core; the shell part can adapt to different FMS configurations and the core part undertakes inherent properties of the device, such as device controller (interpretation and execution of device-level commands), kinematics, and geometric shape. The rough concept of a virtual device is shown in Fig. 3. The job flow model is supposed to describe the flow (transfer) of parts and auxiliary resources (pallets and tools) between devices. Conventional approaches
Fig. 3. Outline of a virtual device model.
738
S.C. Park / Computers in Industry 56 (2005) 734–746
mainly focused on describing the firing condition of a transfer, and did not pay much attention on the physical mechanism enabling the transfer. In reality, a transfer happens by the combination of device-level commands between co-working devices (giving and taking devices). For the fidelity of the virtual FMS model, this paper models a transfer as an object, called a transfer handler, which includes a set of device-level commands enabling the transfer. As a result, we can check the mechanical validity of each transfer and also expect more accurate simulation results because the total time of each transfer will be computed from its physical mechanism (device-level commands). A device-level command can be considered as a program to operate a machine, such as industrial robots (offline programs) and CNC machines (NC programs). Fig. 4 shows the rough outline of a transfer handler model. The supervisory control model describes the control logic of an FMS which makes decisions on firable transfers based on the system state. The system state can be defined by the combination of the states of all virtual devices in the FMS, but this approach might cause an explosion of the state space. That is why we need to define decision variables, which can express meaningful system states. We employ two objects for the supervisory control model: (1) flow controller for making decisions on firable transfers based on the system state (decision variables) and (2) state manager for maintaining decision variables based on the mapping
Fig. 4. Outline of a transfer handler model.
relations between decision variables and the states of virtual devices in the system. Fig. 5 shows the overall structure of the proposed virtual FMS model. The virtual FMS model has four types of objects, virtual device (static layout model), transfer handler (job flow model), state manager, and flow controller (supervisory control model). For the implementation of the virtual FMS model, this paper employs Zeigler’s Discrete Event Systems Specifications (DEVS) formalism [9,10], which supports the specification of discrete event models in a hierarchical, modular manner. The semantics of the formalism are highly compatible with object-oriented specifications for simulation models. DEVSIM++ is a simulation environment which realizes the DEVS formalism for modeling and associated abstract simulator concepts for simulation, all in C++ [10]. We can simulate a
Fig. 5. Outline of the virtual FMS model.
S.C. Park / Computers in Industry 56 (2005) 734–746
DEVS model in the DEVSIM++ environment without implementing the simulation engine. The implementation strategy of this paper is to transform the virtual FMS model into a DEVS model and simulate the model with DEVSIM++. Within the DEVS formalism, one must specify two types of sub-models: (1) the atomic model, the basic models, from which larger ones are built and (2) the coupled model, how atomic models are connected in a hierarchical manner. Formally, an atomic model M is specified by a 7-tuple:
739
couple model DN is defined as: DN ¼ hX; Y; M; EIC; EOC; IC; SELECTi X : input events set; Y : output events set; M : set of all component models in DEVS; EIC DN:IN M:IN : external input coupling relation;
M ¼ hX; S; Y; dint ; dext ; l; ta i
EOC M:OUT DN:OUT : external output coupling relation;
X : input events set; S : sequential states set; Y : output events set;
IC M:OUT M:IN : internal coupling relation;
dint : S ! S : internal transition function;
SELECT : 2M ! M : tie-breaking selector;
dext : Q X ! S : external transition function Q ¼ fðs; eÞjs 2 S; 0 e ta ðsÞg: total state of M;
where the extensions .IN and .OUT represent the input ports set and the output ports set of respective DEVS models. For the implementation of the virtual FMS model, the four types of components (virtual device, transfer handler, state manager, and flow controller) will be represented as atomic models, and the whole virtual FMS model will be represented as a coupled model, including the atomic models and coupling relations between them. The detail specifications of the virtual FMS model are addressed in the following section.
l : S ! Y : output function; ta : S ! Real : time advance function: The four elements in the 7-tuple, namely dint, dext, l and ta, are called the characteristic functions of an atomic model. The second form of the model, called a coupled model, tells how to couple several component models together to form a new model. Formally, a
Fig. 6. Shell of a virtual device.
740
S.C. Park / Computers in Industry 56 (2005) 734–746
3. Virtual FMS model 3.1. Virtual device model As mentioned above, a virtual device consists of a shell part and a core part to improve the reusability. The shell part allows a virtual device model to adapt to different FMS configurations, and it encloses the core part which represents the inherent properties of a device, such as kinematics, geometric shape and the execution of device-level commands. The shell part needs to provide interfaces with two types of components, the state manager and the transfer handler, in the virtual FMS model. The shell part needs to report the state of the virtual device to the state manager whenever the state changes. While the relation between the shell part and the state manager is one-way communication (from the shell part to the state manager), the communication between the shell part and the transfer handler should be two-way. The transfer handler gives device-level commands to the shell part to control the virtual device, and it also receives feed back from the shell part, such as the result (success or failure) of the command execution. According to the FMS configuration, a virtual device can be related to multiple transfers. In this case, the shell part of the virtual device needs to communicate with multiple transfer handlers. Because of this, the shell part needs to be instantiated by considering the number of related transfers. Fig. 6 shows the state transition diagram of a shell part having two related transfers (transfer handler i and transfer handler j). Observe that it has two input ports from two transfer
handlers and it also has two output ports to the transfer handlers. For the state manager, there is only one output port to report the state of the virtual device. Fig. 6 shows the stage transition diagram, and the corresponding DEVS atomic model can be described as follows. For the implementation details, one can refer to the DEVSIM++ user’s manual [10]. Shell of a virtual device : M ¼ hX; S; Y; dint ; dext ; l; ta i X ¼ fTHi ; TH j g S ¼ fWait; Load command; Command executiong Y ¼ fSM; THi ; TH j g dint ðLoad commandÞ ¼ Command execution dint ðCommand executionÞ ¼ Wait dext ðWait; THi or TH j Þ ¼ Load command lðLoad commandÞ ¼ SM lðCommand executionÞ ¼ THi or TH j lðCommand executionÞ ¼ SM ta : S ! Real : time advance function The core part of a virtual device is enclosed by the shell part, and it represents the inherent properties (physical and logical elements) of a real device. For the physical aspects, the core part needs to have a geometric body with kinematics, such as moving joints (rotation or translation) and attributes of each moving joint including speed, acceleration and feasible moving range. To control the geometric body, we need to have a device controller which
Fig. 7. Core of a virtual device.
S.C. Park / Computers in Industry 56 (2005) 734–746
models the logical aspects of a device. The device controller should be able to execute device-level commands by operating the geometric body. In the case of a NC machine, the device controller should be able to interpret NC commands, such as M-codes, G-codes, and APT commands. For example, ‘‘G00 X050.0 Y086.5 Z100.0’’ is a G-code command ordering a rapid tool movement to the position of (X = 50.0, Y = 86.5, Z = 100.0). An example of the core part is shown in Fig. 7. 3.2. Transfer handler model
741
definition of the DEVS atomic model corresponding to the transfer handler model, shown in Fig. 8, can be described as follows: Transfer handler : M ¼ hX; S; Y; dint ; dext ; l; ta i X ¼ fFC; VDi ; VD j g S ¼ fWait; Next command; Issue commandg Y ¼ fVDi ; VD j g dint ðNext commandÞ ¼ Issue command
A transfer handler model has a set of device-level commands enabling a transfer between two devices, giving and taking devices. A transfer handler model needs to communicate with the flow controller and a pair of virtual devices. As shown in Fig. 8, a transfer handler has an input port (FC) from the flow controller through which a firing signal activates the transfer. Once a firing signal comes in, the transfer handler finds device-level commands which will be delivered to corresponding virtual devices through two output ports (VDi, VDj). When the virtual devices complete the ordered commands, they inform the transfer handler of the end of commands through two input ports (VDi, VDj). Then, the transfer handler finds the next command to be executed. These steps are repeated until the transfer is completed. The formal
dint ðIssue commandÞ ¼ Next command or Wait dext ðWait; FCÞ ¼ Next command lðIssue commandÞ ¼ VDi or VD j ta : S ! Real : time advance function For the fidelity of the virtual FMS model, a transfer handler performs a transfer by the combination of device-level commands. Since the virtual FMS model performs a transfer in a very realistic manner, we can even check the validity of the physical mechanism of a transfer, and also expect more accurate simulation results. Fig. 9 shows an example of a transfer between a robot and a CNC machine.
Fig. 8. Transfer handler model.
742
S.C. Park / Computers in Industry 56 (2005) 734–746
Fig. 9. An example of a transfer.
3.3. Flow controller and state manager For controlling an FMS, the virtual FMS model introduces two types of components, the state manager and flow controller. The state manager
maintains decision variables representing the FMS state, and the flow controller chooses firable transfers according to the decision variables. As shown in Fig. 10, the state manager needs to have k input ports, where k is the number of virtual devices belonging to
Fig. 10. State manager and flow controller.
S.C. Park / Computers in Industry 56 (2005) 734–746
the virtual FMS model. Whenever there is a state change of a virtual device, it should report to the state manager through the corresponding input port. Then, the state manager needs to reflect the change to the decision variables by using the mapping relations between the decision variables and the states of virtual devices. If there are any changes in the decision variables, the state manager should report to the flow controller through the only output port (FC). The state manager may play an important role in planning the real FMS implementation, especially in planning the design of sensory equipment. The formal definitions of the DEVS atomic models corresponding to the flow controller and the state manager, shown in Fig. 10, can be described as follows: Flow controller : M ¼ hX; S; Y; dint ; dext ; l; ta i X ¼ fSMg S ¼ fWait; Firable transferg
743
there is a firable transfer, the flow controller gives an order to fire the transfer through the corresponding output port. For the decision making, it is necessary to specify the firing condition of each transfer. 3.4. Virtual FMS model As mentioned above, a virtual FMS model consists of four types of objects, virtual device (static layout model), transfer handler (job flow model), state manager and flow controller (supervisory control model). While the four types of objects are implemented as atomic models, the whole virtual FMS model is implemented as a coupled model, including those atomic models and coupling relations between them. Fig. 11 shows a simple example of a virtual FMS model including two virtual devices, one transfer handler. The formal definitions of the DEVS coupled model corresponding to the virtual FMS model, shown in Fig. 11, can be described as follows.
Y ¼ fTH1 ; TH2 ; . . . ; THn g; where n is the number of transfer handlers dint ðFirable transferÞ ¼ Wait
Virtual FMS : DN ¼ hX; Y; M; EIC; EOC; IC; SELECTi
dext ðWait; SMÞ ¼ Firable transfer
X ¼ fg;
lðFirable transferÞ ¼ TH1 or TH2 or . . . or THn
M :¼ fVDI ; VDJ ; THIJ ; SM; FCg
ta: S ! Real: time advance function
EIC ¼ fg;
Y ¼ fg
EOC ¼ fg
State manager : M ¼ hX; S; Y; dint ; dext ; l; ta i X ¼ fVD1 ; VD2 ; . . . ; VDk g; where k is the number virtual devices S ¼ fWait; Updateg Y ¼ fFCg dint ðUpdateÞ ¼ Wait
IC ¼ fðSM:O1 FC:I1Þ; ðFC:O1 THIJ:I1Þ; ðTHIJ:O1 VDI:I1Þ; ðTHIJ:O2 VDJ:I1Þ; ðVDI:O1 SM:I1Þ; ðVDI:O2 THIJ:I2Þ; ðVDJ:O1 SM:I2Þ; ðVDJ:O2 THIJ:I3Þg SELECT: 2M ! M: tie-breaking selector;
dext ðWait; VD1 or VD2 or . . . or VDk Þ ¼ Update lðUpdateÞ ¼ FC ta: S ! Real: time advance function The flow controller has one input port from the state manager, and n output ports, where n is the number of transfer handlers in the system, as shown in Fig. 10. Whenever the stage manager reports a state change of the system, the flow controller makes a decision on firable transfers based on the flow control logic. If
4. Examples and illustrations The proposed virtual FMS model has been implemented and tested with various examples to prove its usefulness. For the simulation of the virtual FMS model, this paper employs Zeigler’s DEVS formalism. We used C++ language in a Visual Studio environment and OpenGL for the graphical rendering. The virtual FMS line shown in Fig. 12 is a mechanical
744
S.C. Park / Computers in Industry 56 (2005) 734–746
Fig. 11. A virtual FMS model.
Fig. 12. Mechanical parts machining line.
S.C. Park / Computers in Industry 56 (2005) 734–746
745
Fig. 13. Virtual device modeling and execution.
parts machining line with four machining centers and a washing machine. While the transfer handler, the state manager, the flow controller, and the controller of a virtual device can be implemented by programming in the DEVSIM++ environment, the geometric body of a virtual device requires solid modeling functionalities. For the modeling of the geometric body of a virtual device, the constructive solid geometry (CSG) modeling scheme was employed. In the CSG modeling scheme, a user can interactively construct a solid model by combining various primitives, such as cylinders, spheres, boxes, and cones. To imitate the kinematics of a real device, it is necessary to define the moving joints and the attributes of each joint. We can verify a virtual device by executing it with a real device program, as shown in Fig. 13. Our final goal is to provide a library containing all standard manufacturing devices, such as machining stations, AGVs, and robots. Therefore, users can easily instantiate virtual devices, without making efforts for modeling virtual devices.
5. Discussion and conclusions This paper presents an object-oriented methodology for the modeling and simulation of a virtual FMS. For the implementation of the proposed virtual FMS model, the paper employs DEVSIM++ which is an object-oriented simulation language based on Zeigler’s DEVS formalism. The OOM paradigm of Rumbaugh uses three kinds of models to describe a system: the object model, describing the objects in the system and their relationships; the dynamic model, describing the interactions among objects in the system; and the functional model, describing the data transformations of the system. The proposed virtual FMS model follows the OOM paradigm and uses four types of components: the virtual device model corresponding to the object model, the transfer handler model corresponding to the functional model, and the state manager and flow controller model corresponding to the dynamic model. A virtual device is designed considering reusability, and the device consists of two parts: shell and core.
746
S.C. Park / Computers in Industry 56 (2005) 734–746
The shell part allows a virtual device model to adapt to different FMS configurations, and it encloses the core part which contains the inherent properties of a device, such as kinematics, geometric shape, and the execution of device-level commands. For the fidelity of the virtual FMS model, a transfer handler model has a set of device-level commands imitating the physical mechanism of a transfer. As a result, we can check the mechanical validity of each transfer and also expect more accurate simulation results, because the total time of each transfer will be computed from its physical mechanism. The flow controller model makes decisions on firable transfers based on decision variables, which are maintained by the state manager model. To maintain the decision variables, the state manager stores mapping relations between decision variables and the states of virtual devices in the system. The mapping relations can serves as the guidelines for the planning of a real FMS implementation.
[8]
[9] [10] [11]
[12]
[13]
[14]
[15]
Reference [16] [1] G.L. Kovacs, S. Kopacsi, J. Nacsa, G. Haidegger, P. Groumpos, Application of software reuse and object-oriented methodologies for the modeling and control of manufacturing systems, Computers in Industry 39 (1999) 177–189. [2] A. Anglani, A. Grieco, M. Pacella, T. Tolio, Object-oriented modeling and simulation of flexible manufacturing system: a rule-based procedure, Simulation Modeling Practice and Theory 10 (2002) 209–234. [3] P. Klingstam, P. Gullander, Overview of simulation tools for computer-aided production engineering, Computers in Industry 38 (1999) 173–186. [4] A.M.A. Al-Ahmari, K. Ridgway, An integrated modeling method to support manufacturing system analysis and design, Computers in Industry 38 (1999) 225–238. [5] C. Ou-Yang, T.Y. Guan, J.S. Lin, Developing a computer shop floor control model for a CIM system-using object modeling technique, Computers in Industry 41 (2000) 213–238. [6] B.K. Choi, Kwan H. Han, Tea Y. Park, Object-oriented graphical modeling of FMSs, The International Journal of Flexible Manufacturing Systems 8 (1996) 159–182. [7] B.K. Choi, B.H. Kim, New trends in CIM: virtual manufacturing systems for next generation manufacturing, in: Current
[17]
Advances in Mechanical Design and Production Seventh Cairo University International MDP Conference, Cairo, February 15–17, 2000, pp. 425–436. J. Rumbaugh, M. Blaha, W. Premerlani, W. Losenson, ObjectOriented Modeling and Design, Prentice Hall Inc., Englewood Cliffs, NJ, 1991. B.P. Zeigler, Multifacetted Modeling and Discrete Event Simulation, Academic Press, Orland, 1984. T.G. Kim, DEVSIM++ User’s Manual, Department of Electrical Engineering, KAIST, Korea, 1994. M. Onosato, K. Iwata, Development of a virtual manufacturing system by integrating product models and factory models, CIRP 42 (1) (1993) 475–478. K. Iwata, M. Onosato, K. Teramoto, S. Osaki, A modeling and simulation architecture for virtual manufacturing systems, CIRP 44 (1) (1995) 399–402. H. Huang, C. Yeh, Development of a virtual factory emulator based on three-tire architecture, in: IEEE International Conference on Robotics & Automation, Detroit, MI, May, 1999, pp. 2434–2439. L. Ye, F. Lin, Virtual system simulation—a step beyond the conventional simulation, in: 22nd International Conference on Computer and Industrial Engineering, 20 December, 1997, 304–306. M. Lin, L. Fu, T. Shih, Virtual Factory—a novel testbed for an advanced flexible manufacturing system, in: IEEE International Conference on Robotics & Automation, Detroit, MI, May, 1999, pp. 2422–2427. K.Y. Chen, S.S. Lu, A Petri-net and entity-relationship diagram based object-oriented design method for manufacturing systems control, International Journal of Computer Integrated Manufacturing 10 (1–4) (1997) 17–28. S. Narayanan, D.A. Bodner, U. Sreekanth, T. Govindaraj, L.F. McGinnis, C.M. Mitchell, Research in object-oriented manufacturing simulations: an assessment of the state of the art, IIE Transaction 30 (9) (1998) 795–810.
Sang C. Park is an assistant professor in the Department of Industrial & Information Systems Engineering at Ajou University. Before joining Ajou, he worked for DaimlerChrysler Corp. and CubickTek Co., developing commercial and inhouse CAD/CAM/CAPP/simulation software systems. He received his BS, MS, and PhD degrees from KAIST in 1994, 1996, and 2000, respectively, all in industrial engineering. His research interests include geometric algorithms in CAD/CAM, process planning, engineering knowledge management, and discrete event system simulation. He can be reached via email at [email protected].