An Object-Oriented Approach for Flexible Manufacturing Control ...

The International Journal of Flexible Manufacturing Systems, 15, 195–216, 2003 c 2003 Kluwer Academic Publishers. Manufactured in The Netherlands.


An Object-Oriented Approach for Flexible Manufacturing Control Systems Analysis and Design Using the Unified Modeling Language MANFREDI BRUCCOLERI AND SERGIO NOTO LA DIEGA DTPM, University of Palermo, Palermo, Italy GIOVANNI PERRONE DIFA, University of Basilicata, Potenza, Italy

Abstract. In reacting to global competition and rapidly changing customer demands, industrial business organizations have developed a strong interest in flexible automation. The aim of flexible automation focuses on achieving agility in handling uncertainties from internal or external environments. Modeling complex structures, promoting reuse, and shortening the development time cycle are particularly significant aspects in the analysis and design of CIM systems, where heterogeneous elements have to be integrated in a complex control architecture. The design methodology for FMS control software involves the abstraction of an FMS and the estimation of the system performances. The aim of this activity is to suggest the optimal configuration of an FMS for given specifications, through simulation tools. In the software engineering field, object-oriented (OO) approaches have proven to be a powerful technique with respect to such aspects. The unified modeling language (UML), by using OO design methodologies, can offer reusability, extendibility, and modifiability in software design. Also, it bridges the gap that exists between the OO analysis and design area and the area of OO programming by creating an integrative metamodel of OO concepts. The specific goal of this paper is to formulate a new methodology for developing reusable, extendible, and modifiable control software for an FMS in an object-oriented environment. It is demonstrated that, with few diagrams, UML can be used to model such systems without being associated with other modeling tools. Key Words: discrete-event simulation, FMS, unified modeling language

1.

Introduction

Cost, quality, and manufacturing lead times are the three success keys for manufacturing enterprises. In reacting to global competition and rapidly changing customer demands, business organizations in many industrial sectors have developed a big interest in flexible automation. The aim of flexible automation focuses on achieving agility in handling uncertainties from internal or external environments (Zhang, Gu, Li, and Duan, 1999). Agility can be defined as the ability to succeed in a competitive environment characterized by continually changing opportunities. It can be measured in terms of efficiency, flexibility, robustness, and adaptability. Flexible manufacturing systems (FMSs) are complex structures where heterogeneous elements have to be integrated by complex control architecture. FMSs consist of a set of manufacturing cells, machines, robots, automated guided vehicles, programmable logic controllers, cell controllers, and shop floor controllers (Elia and Menga, 1994). Flexibility in

196

BRUCCOLERI, NOTO LA DIEGA, AND PERRONE

an FMS is mainly gained by the utilization of programmable devices that control machines, robots, and material handling systems. Therefore, flexibility is primarily based on the realtime re-programmability of software control systems. Hence, FMS control software has to be designed to meet the production system real-time constraints and dynamically adapt to the market needs (Venkatesh and Zhou, 1998). Traditionally, the function of FMS control software is to coordinate and control different elements in a manufacturing system. In this paper, the integration between control and simulation software is proposed to expedite system development. The design methodology for FMS control software involves the abstraction of an FMS and the estimation of the system performances. The aim of such activity is to suggest a good configuration of an FMS for given specifications, through modeling and simulation tools. In an FMS, machines and robots working on specific part families may be grouped into cells. For these, control software could be designed for a given cell, in a way that it can be used to control another cell with few or no changes. In addition, reusable, modifiable, and extendible control software needs to be designed to deal with complex shop floor requirements and to easily adapt to changes in system specifications. To meet such requirements, a systematic design methodology should be used in designing FMS control software. In the software engineering field, an object-oriented (OO) approach has proven to be a powerful technique with respect to modeling, analysis, and design of complex systems. In such an approach, promoting reuse of software blocks and shortening the software system development time cycle are particularly significant features. In addition, in this context, visual modeling plays an important role for its high capability in allowing the designer an easier comprehension of complex systems. Yet, until a few years ago, OO methodologies had an important drawback: there was no standard language and, therefore, a great confusion and indecision on which language to adopt for OO programming existed in the minds of the modelers. The birth of many OO methods produced the so-called methods war which was overcome when, in November 1997, the object management group approved the unified modeling language (UML) as standard universal language (notation) for representing every kind of software system. UML defines a metamodel-based graphical notation around objectoriented analysis and design embracing all features of an OO paradigm. In fact, besides the standardization of the notations for representing OO concepts, the main contribution of UML is that it bridges the gap that exists between the OO analysis and design area and the area of OO programming by creating an integrative metamodel of OO concepts (Van Hillegersberg and Kumar, 1999). Also, the UML, by using object-oriented design methodologies, can offer reusability, extendibility, and modifiability in software design. So far, the UML is a modeling language that only specifies semantics and notation but no process methodology is defined within it. Coming back to FMS control systems, each FMS component can be modeled as an object that interacts with several other objects to complete a set of production tasks. Following these directions, the aim of the research presented in this paper is to design an objectoriented methodology for developing reusable, extendible, and modifiable control software for an FMS using UML diagrams. We propose a systematic design procedure to make the task of developing the control software system easier. Also, in this paper a sample flexible manufacturing control software (FMCS) development is shown and the reusability and

FLEXIBLE MANUFACTURING CONTROL SYSTEMS ANALYSIS AND DESIGN

197

flexibility of the designed software are demonstrated both in the design phase (by reusing objects of the same class) and in the running phase (by changing the system configuration, either at the operation level or at the strategic level). 2.

FMS control software

Monitoring and controlling an FMS is a complex but important task. In fact, modern computerized manufacturing systems have lagged far behind what could be achieved with existing technology (Joshi and Smith, 1994). The cost of such systems is often too high and it should be justified by a return on investment, which can be gained only if the required system flexibility is assured. Flexibility is the capability to react to the continuous market changes through easy production adaptability. A number of authors have stated many crucial needs for the success of FMCS. Joshi and Smith (1994) define, as key factors for the success of FMCSs, reduction in costs of the software systems, increase in flexibility and the ability of using it, seamless integration, and reusability. Zhang et al. (1999) assert that the minimum desirable characteristics for flexible manufacturing systems are reusability, reconfigurability, and scalability. Venkatesh and Zhou (1998) consider that the functional objective of FMS control software is to maintain high system utilization and throughput. In addition, reusable, modifiable, and extendible control software need to be designed. Aguirre, Weston, Mart´ın, and Ajuria (1999) believe that major obstacles arise because of difficulties associated with generating manufacturing control systems. Finally, software architecture for FMS should embed standard usage, object-orientation, and inherent support for flexibility (Kov´acs, Kop´acsi, Nacsa, Haidegger, and Groumpos, 1999). Actually, the modeling phase plays a crucial role during FMCS design (Xiang and O’Brien, 1995). In the literature several modeling methodologies can be found. Among them, the most relevant are queueing networks (Buzacott and Shanthikumar, 1980), IDEF0 (Gong and Lin, 1994), Petri nets (D’Souza and Khator, 1994), discrete event simulation (Haddock, 1995), and object-oriented techniques (Booth, 1998; Venkatesh and Zhou, 1998). In fact, in the last ten years the supremacy of OO approaches with respect to reusability, extendibility, and modifiability in control software design has been largely proven. Yet, the chaotic proliferation of OO system development concepts is nowadays one of the main concerns expressed by several authors (Van Hillegersberg and Kumar, 1999). The need for a methodology that does not introduce new OO concepts, but instead tries to take the benefits of the OO paradigm using known and standardized technologies (as the UML), is the aim of the research presented in this paper. In this direction, an object-oriented approach for modeling, design, simulation, analysis, and programming of a flexible manufacturing control system is discussed with respect to the other OO approaches for flexible manufacturing system control development that can be found in the literature. Its advantages consist mainly in three items. First it is based on a standardized and wellaccepted OO tool (UML). Then, no further OO system development concepts are introduced so as to avoid additional confusion and methodology divergence. Finally, the proposed approach, throughout all phases of the control system development (analysis, design, and implementation), uses only one modeling tool (yet again the UML), in contrast to other OO

198

BRUCCOLERI, NOTO LA DIEGA, AND PERRONE

approaches (Booth, 1998; Venkatesh and Zhou, 1998) that use more than one tool. This, entirely, makes easier, clearer, and more team-oriented the development of the required FMCS. 3.

Object-oriented modeling, design, and programming

One main activity in software development is the achievement of a conceptual model of it. Furthermore, for the maintenance and modification of such software, the comprehension of its global organization, the relationships among its components and their response to external changes are essential phases. For these reasons, in the object-oriented paradigm the design, modeling, and analysis phases of the software system development play a crucial role. Object-modeling techniques (OMT) are widely recognized as powerful instruments in preliminary phases of software design. This is also because of the existing commercial tools, which aid the designer through visual modeling, code generation, and reverse engineering. The OO paradigm for software development allows the designer to achieve three main advantages. The first concerns software maintenance: the program results are simpler and easier to understand. The programmer can view only the detail degree he retains to be important. The second is relative to code modifications: often it is sufficient to insert a new class into the system without otherwise changing anything. In fact, a new class inherits characteristics of its parent class and the designer must only add the new characteristics of the class. The third advantage is regarding class reutilizing. Once a class has been defined, it can be reused in other programs with no relevant code changes (Bruccoleri, Perrone, and Noto La Diega, 2000). 3.1.

The unified modeling language

Among competing object-oriented analysis and design tools, the authors have selected the unified modeling language. The UML is the standard universal language, approved by the object management group, for representing (i.e., specifying, building, and documenting) every kind of software system. The UML defines a metamodel-based graphical notation for OO analysis and design embracing all the features of the OO paradigm such as reusability, representational versatility, inheritance property, and rapid prototyping (Shaw, 1998). In other words, the UML is a formal semantic metamodel defining basic modeling concepts (object, class, association, etc.) and it also is a graphical notation for system representations including eight different diagram types; it embraces all the features of the OO paradigm through a synergistic combination of various proven techniques including encapsulation, inheritance, polymorphism, and generalization. The UML is not a programming language but a design language. It is a modeling language that specifies semantics and notation but it is not a methodology and does not define a software design procedure. In building the model, the UML may be used to: • display the requirements of a system and its major functions using use-case diagrams and actors;

FLEXIBLE MANUFACTURING CONTROL SYSTEMS ANALYSIS AND DESIGN

199

• illustrate use-case realizations with interaction diagrams (sequence and collaboration diagrams); • represent a static structure of a system using class diagrams; • model the behavior of objects with state transition and activity diagrams; • reveal the physical implementation architecture with component and deployment diagrams. UML, with its use-case view diagrams, logical view diagrams, and component view diagrams, develops three orthogonal models: functional, object, and dynamic models (Booth, 1998). The functional model represents the transformational aspects of the system and it captures what the system does without specifying how it works. The object model represents the static, structural aspects of the system, in which objects, their entities, their attributes, their operations, and their relationships with other objects are described in detail. The dynamic model represents the temporal behavioral aspects of the system, in which any change is described by activities and events, sequences of events, and states. The UML metamodeling is really complex because of its ambition to represent every kind of software system in different abstraction levels. The numbers of diagrams is very high and the designer can choose among similar representational forms. The UML does not suggest sequence utilization of a diagram; it lets the designer free to choose which way to follow throughout the system design (Comai, 1998).

4.

An OO approach for FMCS analysis and design using the UML

Our design methodology for FMCS does not focus on real-time control implementation (online schedulers, controllers, and monitoring system) issues. Our research has been carried out on the FMCS development issues related with modeling, simulation, and analysis. The specific goal of this paper is to formulate an object-oriented methodology for developing reusable, extendible, and modifiable control software for an FMS using UML diagrams. It should be noted that both in the literature and in the market of software development systems, a number of processes and methodologies for using the UML have started to appear. The Rational unified process and the Fusion engineering process (by HewlettPackard) are two examples (Malan, Letsinger, and Coleman, 1996). Nevertheless, they are general-purpose methodologies for developing every kind of software system and thus they have to be adapted to the specific software needs. The aim of the research presented in this paper is not to propose a new general-purpose process methodology for using the UML but, more specifically, to provide a new tool for developing manufacturing system control software by using the UML. By means of few diagrams, the authors have proposed a systematic design methodology to make the task of developing the control software system easier. Also, it is demonstrated that the UML can be used to model such systems without being associated with other modeling tools. Yet, the UML is a modeling language that only specifies semantics and notation. No process methodology is defined within it. Thus, we have suggested a procedural approach that is based on the following analysis steps and is shown in Figure 1:

200

Figure 1.

BRUCCOLERI, NOTO LA DIEGA, AND PERRONE

Proposed methodology for FMS control software development.

1. Functional model design by means of use-case diagrams and sequence diagrams. 2. Object and dynamic model design, respectively, by means of class diagrams and state/ activity diagrams. 3. Discrete-event simulation software implementation to evaluate the system performance through a quantitative analysis technique.

FLEXIBLE MANUFACTURING CONTROL SYSTEMS ANALYSIS AND DESIGN

201

In Figure 1, the phases relating to modeling and code elaboration are represented by gray rectangles, whereas the phases relating to classes and processes identification, analysis and deduction are pictured by white rectangles with rounded ends. The proposed approach is explained in the following sections, where the methodology steps are described in detail. This methodology has been applied to the design of a single manufacturing cell. After developing a single cell model, the designer can reuse and extend such a model to other cells. Then, through a few modifications, one can adjust the model by connecting all the modeled cells and adding a transportation system. 4.1.

Building the functional model

Designing the system functional model is a powerful means for understanding the transformational aspects of the system and captures what the system does without specifying how it works. We have chosen two diagrams from among several UML diagrams for representing the functional model: the use-case diagram and the sequence diagram. The former is made up of actors and use case. An actor is someone or something that must interact with the system under development. A use-case is a pattern of behavior that the system exhibits; each use case is a sequence of related transactions performed by an actor and the system in a dialogue (Rational Software Corporation, 1997). The latter is made up of objects (class instances) and messages. The use-case diagrams present an outside view of the system, whereas the sequence diagrams describe how use-cases are realized as interactions (messages sent) among societies of objects (Hopkins, King, and Culbreth, 1994). 4.2.

Concurrent design of object and dynamic model

In an OO view an FMCS model, S, may be mathematically defined as S = (Oi , Mi j ), where, Oi is the set of objects in the manufacturing system (Oi , i = 1, 2, . . . , I ) and Mi j is a set of messages exchanged among objects (Mi j , i, j = 1, 2, . . . , I ) (Zhang et al., 1999). At the same time, from a class point of view, the control system model can also be stated as S = (Ci , Ri j ), where, Ci is a set of classes in the manufacturing system (Ci , i = 1, 2, . . . , I ) and Ri j is a set of relationship among classes (Ri j , i, j = 1, 2, . . . , I ); a relationship among classes is the base for message interchanging among objects. The basic kinds of relations among classes are association, aggregation, and generalization. The first describes a simple relation between two classes. In the UML graphical notation, it is represented through a line connecting the two classes and is labeled with a name. The second is relative to a relationship between two classes one of which, “is a part of” of the other one. In the UML symbolism, aggregations are typed by a line with a diamond. The third states a relation of inheritance between two classes that are called subclass and super class. The generalization is a particular “is a” association. In this phase of the analysis, by examining objects in the sequence diagram, the designer has to identify all classes involved in the system. So far, only the relationships of classes and their hierarchy have been defined. Yet, to define the structures of classes, their attributes, and operations, it is necessary to analyze the dynamic behavior of the system and of its components during the realization of all of the system use cases. To describe the dynamic behaviors and the process workflows in terms of information flows among objects, activity

202

BRUCCOLERI, NOTO LA DIEGA, AND PERRONE

diagrams should be used. On the other hand, the activity diagram is also used because of its consistency with the subsequent implementation of discrete-event simulation software. Activity diagrams are very similar to a flowchart because they can model workflow from activity to activity or from activity to state. A state represents a condition or a situation during which the object satisfies some conditions or waits for some events. Each state represents the cumulative history of its behavior. An activity represents the performance of a “task” in a workflow. It may also represent the execution of a statement in a procedure. An activity is similar to a state, but it expresses the intent that there is no significant waiting (for events) in an activity. A state transition indicates that an object standing in the source state will perform certain specified actions and it enters the destination state when a specified event occurs or when certain conditions are satisfied. A state transition is a relationship between two states, two activities, or between an activity and a state (Rational Software Corporation, 1999). Every state or activity occurs when a state transition occurs; a state transition is consequential to an event. In this way, the state of an object represents its attributes configuration in a particular moment, whereas a state transition represents a particular behavior. Because every message sent to an object changes the state of such an object, the information exchange is modeled by events. Using these concepts, the designer associates to each event, which modifies the state of an object, an operation of the relative class. The activity diagram explains all of the operations and attributes of the classes that allow the fulfillment of the process. Nevertheless, for a complete modeling of such classes, a more complete analysis of their actions during their entire life is necessary. To accomplish this task, the state transition diagram should be used. Behind the activity diagram, the designer builds a state transition diagram for every object involving the model design process. State transition diagrams model the dynamic behavior of individual classes or any other kind of object. They show the sequences of states that an object goes through, the set of events causing a transition from one state or activity to another, and finally, the actions that result from a state or activity change. State transition diagrams are closely related to activity diagrams. The main difference between the two diagrams is that state transition diagrams are state based, whereas activity diagrams are activity based. A state transition diagram is typically used to model the discrete stages of an object’s lifetime, whereas an activity diagram is suited better to model the sequence of activities in a process. In other words, every state transition diagram describes the evolution of a class during all of its life. This is essential for defining all class attributes and operations that are not defined during the activity diagram development. After the activity diagram and all state transition diagrams have been integrated with each other, the designer is able to define the class structures, their attributes, operations, and definitive associations. All states of an object identify its class attributes; all of its state transitions identify its class operations. 4.3.

Discrete-event simulation software implementation and quantitative analysis

After the system model has been fully developed, i.e., when the functional, the object, and the dynamic models have been defined, a discrete-event simulation software can also be implemented to test the developed FMCS.

FLEXIBLE MANUFACTURING CONTROL SYSTEMS ANALYSIS AND DESIGN

203

To accomplish this task, a proper programming language has to be selected. For this purpose, four types of implementation tools can be chosen: a general-purpose language (i.e., FORTRAN or C), an extension of a general-purpose language (i.e., C++), a simulation language (i.e., MODSIM by CACI, SIMPLE++ by TECHNOMATIX), or a simulation package (i.e., SIMFACTORY also by CACI). The choice of the tools depends mainly on the aim of the simulation itself. Simulation assists in designing FMSs and FMS control. Usually, simulation is used during the manufacturing control system design to compare the results of different scheduling strategies or, in general, operations management policies (Bruccoleri and Pasek, 2002). Also, simulation for an FMSC can be adopted to test control architectures (Renna, Perrone, Amico, and Bruccoleri, 2001) and to facilitate the evaluation and comparison of different FMS designs for the same tasks (Kov´acs et al., 1999). This last mentioned target requires building up several new simulation models. For all these kinds of applications, we believe that high-level simulation languages (in many commercial tools and simulation packages, nowadays the simulation model is automatically created from high-level modeling languages and notations) are well suited, as they allow validation of line performance, including throughput, bottlenecks, resource utilization and congestion, buffer sizing, and part flow-time. These models facilitate evaluating different manufacturing scenarios inR and Slam
R are widely used tools for creasing throughput potential. As examples, Arena
these purposes (Kelton, Sadowski, and Sadowsky, 1998). On the other hand, in the approach presented in this paper, the basic purpose of the FMSC simulation is, primarily, to test whether a developed control system satisfies the initial requirement of software modifiability, reusability, and scalability. For these reasons, an extended general-purpose language has been selected because the dynamic model, in particular the activity diagram, was structured to implement an event-based simulation. A general-purpose language sufficiently adapts to event-based simulation programming. Among several general-purpose languages, C++ has been chosen because of its OO features. Once the simulation software has been developed, a designer can analyze FMCS by evaluating the system performances under different configurations of the system. In fact, by changing the system configuration, several control policies can be tested. For instance, the production lot size (PLS) or the exception handling policy could be tested. In an OO model, code modifications are often obtained by inserting a new class into the system without existing code changes. A new class inherits characteristics of its parent class and the designer needs only to add those characteristics that differentiate the new class from its parent. 5.

Approach implementation by an FMS example

For testing the proposed methodology, an FMS example proposed by Venkatesh and Zhou (1998) has been chosen. Such choice also allows highlighting the differences between the proposed methodology and that of the one chosen, which is based on the use of OMT for static representation and Petri nets as dynamic modeling tool. The sample FMS is shown in Figure 2.

204

BRUCCOLERI, NOTO LA DIEGA, AND PERRONE

Figure 2.

The sample FMS.

The FMS consists of four manufacturing cells. Every cell consists of one machine, a robot, an input buffer, an output buffer, some programmable logic controllers (PLCs), and a cell controller. The FMS produces four part types, which, later, have to be assembled to a final product. The part types to be produced are a, b, c, and d. Their machining sequences and processing times are given in Table 1. Part types a and b have to be processed first in machine M1 and then in M3; part types c and d are processed first in M2 and then in M4. For simplicity, part types a and b (c and d) have to be processed at Cell 1 (Cell 2) before passing to Cell 3 (Cell 4). Furthermore, a new production lot, of the four part types, arrives into the system only when the previous parts, which are being processed, depart from the system. Finally, the robot loading and unloading times are Tl = Tu = 1 time unit. The control system architecture addressed in this paper is a hierarchical control structure. In this way, the highest node of the control hierarchy is the shop floor controller followed by the cell controller (one for each cell) and by the PLC (one for each component of the manufacturing cell).

5.1.

Functional model for the sample FMS

Figure 3 shows the use-case diagram for the sample FMS control software. In such a diagram, three actors are represented: the shop-floor controller, the cell controller, and the PLC. These actors interact with the system “using” it in different manners. Table 1.

Machining sequences and processing times.

Part type

Sequence

M1

M2

M3

M4

a

M1–M3

7

–

9

–

b

M1–M3

8

–

10

–

c

M2–M4

–

5

–

7

d

M2–M4

–

4

–

3

FLEXIBLE MANUFACTURING CONTROL SYSTEMS ANALYSIS AND DESIGN

Figure 3.

205

Use case diagram.

In particular, the first controller controls the FMS, i.e., it controls the cell controller and schedules production tasks among cells. The second controller controls the cell, i.e., it is responsible for controlling the operations in each cell. The third controller controls the elements, i.e., it coordinates the sequencing of different elements in each cell. Each of the three use-cases can be fully explained and represented in a corresponding sequence diagram. In this paper we have focused on the modeling of a production control system at the cell control level. In this way, only the scenario relative to the fulfillment of the control cell use case has been analyzed in detail. This scenario is represented in Figure 4, where the sequence diagram illustrates the realization of the control cell use-case for Cell 1. The realization of this use-case is a complex process performed by message exchanging among the cell controller, machine, robot, and buffer objects. In particular, the cell controller demands for parts to the PLC of the machine, the PLC orders the machine to begin the set-up process necessary to manufacture a part, the machine sends a message to the robot asking to load or unload a part on the machine table and, finally, the robot communicates with buffer 1 to unload the part. At this point of the modeling process, the designer is able to proceed with the system analysis involving the object and the dynamic model. 5.2.

Static and dynamic models for the sample FMS

After having developed the functional model, the designer can recognize which objects are involved in the system. Furthermore, the kinds of relationship relating objects to each other can be identified. In this way, the designer is able to build an object model representing the static architecture of the FMCS. Figure 5 provides the main class diagram, where classes,

206

BRUCCOLERI, NOTO LA DIEGA, AND PERRONE

Figure 4.

Sequence diagram for control cell use case.

Figure 5.

Main class diagram for FMCS.

their relationships, and hierarchy are displayed. All of the represented classes constitute an FMCS structure. Only those shaded in gray are involved in the control cell process. Specifically, they are the classes whose instances appear in the sequence diagram. Note that neither class attributes nor operations have been defined yet. In fact, only after a dynamic

FLEXIBLE MANUFACTURING CONTROL SYSTEMS ANALYSIS AND DESIGN

207

model of the control system has been developed, can properties and behaviors then be specified. However, the detailed architecture of the class relationships is well evidenced by means of the main class diagram. For instance, the cell controller and the PLC are related by a mono-directional association (single arrow) labeled controls; the numbers located near the classes indicate the class multiplicity in the relation; in this particular case this means that the cell controller controls one or more (1 . . .∗ ) PLCs. The cell controller, the machine, and the robot are parts of the flexible manufacturing cell class. A diamond line represents the aggregation association. Finally, the work-in-process, raw material, and finished products classes are specializations of the part class, i.e., a work-in-process is a part. Specializationgeneralization relationships are represented with a triangle line. To describe the process dynamic workflows in terms of information flows among objects, an activity diagram has been chosen. In Figure 6, the activity diagram for the control cell process is given. Note that this diagram and the following diagrams refer to the modeling of the Cell 1. Also, we use the notation “part A” for representing part types a, as well as “part B” in place of part types b. Thus, in the phase of reusing the model of Cell 1 for all of the other cells, part A (part B) stands for part type a (part type b) if the class represents a component of the cells 1 or 3, whereas it stands for part type c (part type d) if it corresponds to a component of cells 2 or 4. The diagram shows five swimlanes, respectively, representing the five performers involved in the complex process, i.e., machine, robot, PLC, cell controller, and buffer. A start state and an end state are represented in the diagram. The former is a cell controller state and the latter is a buffer state. In the activity diagram, the control cell workflow is modeled in detail through a sequences of states, events, and activities of the five process performers. The process starts when the cell controller “demands for part A on M1” to the PLC. Immediately, the PLC “sends signal for machine setup” to the machine that, once “received the signal,” becomes “ready for setup” and finally “completes setup.” After, the machine is “ready to process a part.” At the same time, the PLC sends a signal asking to load the part to the robot, which, once “received signal”, becomes “ready to load part.” A synchronization bar models that the robot “loads the part on machine” only if the machine and the robot itself are ready. So, the robot loads the part on the machine, and the machine changes its status becoming “loaded with part”; after having “processed the part,” it is “ready to be unloaded.” The robot, which has been “released after loading the part,” is “ready to unload the part” and therefore, it “unloads the part” from the machine that becomes “unloaded with part.” Currently, the buffer is increased and the cell controller “verifies the number of parts” and it orders either a new part A or, if the number of parts A in the buffer is adequate, a new part B. The process continues until the buffer becomes “ready to be unloaded.” Moreover, a state transition diagram for each class involved in the control cell process has been designed. In Figures 7–9, the state transition diagrams and the associated class definitions are concurrently described. The attributes are related to the states, whereas operations are associated to those events implying a state transition. Note that in a state diagram of a specific class, the events originated from a different class method, are translated into operations of the class itself. Figure 7, for instance, illustrates the machine state transition diagram. It describes how the history of the class evolves during the control cell process workflow fulfillment. Machine

208

Figure 6.

BRUCCOLERI, NOTO LA DIEGA, AND PERRONE

Activity diagram.

states are indicated by Si (i = 1, . . . , 5) and the events causing state transitions are indicated by E i (i = 1, . . . , 6). Every state corresponds to a particular configuration of the class attributes. In this particular case, the start state is obtained when all the attributes are zero. The S1 state “machine ready for setup” matches with ready for setup: int = 1 and when all the other attributes are zero. Figure 10 shows a partial view of the detailed class diagram that includes all classes involved in the control cell process. It shows the PLC and the cell controller detailed classes and their associations with the machine, robot, and buffer classes. The information, necessary for the control software implementation, is also graphically represented. The

FLEXIBLE MANUFACTURING CONTROL SYSTEMS ANALYSIS AND DESIGN

Figure 7.

Machine class and its state transition diagram.

Figure 8.

Robot class and its state transition diagram.

Figure 9.

Buffer class and its state transition diagram.

209

210

BRUCCOLERI, NOTO LA DIEGA, AND PERRONE

Figure 10.

Detailed class diagram.

complete class structure (name, attributes, and operations) is well embodied and the relationship architecture, that provides a pathway for communication among classes, is fully specified. 5.3.

Discrete-event simulation software implementation and FMCS quantitative analysis

To implement the FMS discrete-event simulation control software, we have selected the C++ language because of its OO features. For objects relationships, their data structures, and operations implementation, Rose 98i C++ Analyzer has been used (Rose 98i package by Rational); this software tool allows the designer to obtain software code generation from the UML model. Such a software tool allows integration between Rational Rose 98i, which is a visual modeling tool, and Microsoft Visual C++. The final FMCS simulation model consists of two C++ files, a header file, and a body file. The former includes the library of all the created classes, their attributes, operations,

FLEXIBLE MANUFACTURING CONTROL SYSTEMS ANALYSIS AND DESIGN

211

and relationships. The latter contains all the instances of the classes and the exchanged messages that implement the discrete-event simulation software. The C++ generator produces the appropriate C++ classes for each class in the UML model. For standard and user-defined operation, the generator produces skeletal member functions that must be filled up with member function bodies. For example, the skeleton code generated for the class machine is shown in Figure 11. Note that the bodies of the functions (represented in italics) have been added after the code generation. When it comes to the simulation implementation of the system, a traditional SCAN– RESCAN event driven procedural program has been written based on the classes already implemented. In particular, the activity diagram of Figure 6 guided the calendar of events, activities, and states during the phase of programming. Also, the instantiation of classes and the implementation of the flow of messages among all the objects have been added in the simulation program as in a usual OO program. Finally, the time advancement mechanism has been programmed as in a classical event-driven software program. Once the software implementation has been completed, a quantitative analysis is required to test the system flexibility and reconfigurability. Such a quantitative analysis has regarded

Figure 11.

Skeleton code for the machine class.

212

BRUCCOLERI, NOTO LA DIEGA, AND PERRONE Table 2.

Performance evaluation under different lot size conditions.

FMS performance PLS processing time

PLS 1

PLS 2

118

228

Makespan

11800

11400

Mean throughput

0.076

0.079

9

18

WIP

system performance evaluation in different control policies. First, system performance has been evaluated in different production lot size policies. Afterward, the system behavior and its performance has been analyzed under different control policies for errors handling. 5.3.1. Production lot size (PLS). With the aim of analyzing system operative adaptability, the PLS has been selected for setting the system configuration. Suppose that the FMS has to produce 100 assembled part of type P and that the required mix is a = 2, b = 1, c = 4, and d = 2. Two different combinations of PLSs for part types a, b, c, and d are considered here, i.e., 2, 1, 4, 2 and 4, 2, 8, 4 respectively. The first PLSs combination consists in manufacturing a, b, c, and d in lot sizes that are equal to the product P bill of material (BOM) requirements. In the second combination, the same parts are produced in a doublesize lot with respect to the BOM requirements. To change the PLS policy, only the cell controller class attributes, “number of part A” and “number of part B,” have to be modified. The performance evaluation for both the operative configurations is reported in Table 2. Table 2 shows that in the second condition, with respect to the first one, the advantages obtained in terms of productivity (makespan and throughput) are lost in terms of work in process. 5.3.2. Exception handling. At a strategic level, the designer can decide to test the system performance under different control policies for error or exception handling. During the production run, exceptions such as tool breakdowns or introductions of new part types, have to be handled in such a way so as to minimize the time when the system is blocked because of the occurrence of the exception. It is well known that PLC tasks are not involved with failure management. The earliest control level enabled to deal with such a problem is the cell controller, then the shop floor controller, and eventually a business host. Suppose that a tool breakdown occurs. Then, two different control policies can be pursued to handle this problem. When the exception occurs, the PLC raises and passes the information to the cell controller. The cell controller, in order to handle this exception, can decide either to transfer the parts in the queue of the broken machine to the next machine (case 1) or to leave all parts in the queue during repair (case 2). Such different policies are reached by means of two different exceptions handling process workflows that are modeled through the two activity diagrams shown in Figures 12 and 13. Figure 12 describes the exception handling process workflow in case 1. In this case, as soon as the cell controller receives the exception signal from the PLC, it starts a control procedure for transferring the parts waiting to be processed at the failed machine,

FLEXIBLE MANUFACTURING CONTROL SYSTEMS ANALYSIS AND DESIGN

Figure 12.

213

Activity diagram for exception handling–case 1.

to the next routing machine. In the activity diagram three swimlanes can be discerned, i.e., three performers are involved in the process: the cell controller, the machine, and the robot (which directly transfers parts from the input buffer to the output buffer of the broken machine). Figure 13 illustrates the exception handling process workflow in case 2. In this case, the control process only involves two actors, the cell controller and the machine. The parts in queue wait for processing until the occurred breakdown is successfully repaired. The performance evaluation for both the error handling control policies is shown in Table 3. It is assumed, for the sake of simplicity, that only machine M3 can break down and its failure rate is λ = 0.05 time units−1 (an exponential distribution). Moreover, suppose that in a first hypothesis, the failure repair mean time is Tr = 5 time units, whereas for a second hypothesis, Tr = 2. Finally, a robot transfer time, from the input buffer to the output buffer, equal to three time units, i.e., Tt = 3, has been assumed. Table 3.

Performances evaluation under different exception handling control policies.

FMS performance PLS processing time

Case 1

Case 2 (Tr = 5)

Case 2 (Tr = 2)

121

123

120

Makespan

12 100

12 300

12 000

Mean throughput

0.074

0.073

0.075

9

9

9

WIP

214

BRUCCOLERI, NOTO LA DIEGA, AND PERRONE

Figure 13.

Activity diagram for exception handling–case 2.

Note that the second solution improves system productivity in relation to the hypothesis on the failure repair time. It is reasonable that the advantage of the first or the second control policies depends on λ, Tr , Tt . 6.

Conclusions

In this paper a new object-oriented approach for developing a flexible manufacturing control system has been discussed. The approach proposes the unified modeling language as an object-oriented tool that can be used without other tools for the modeling and design of FMCSs. It has been demonstrated that the UML can support a static and structural modeling of control systems, as well as dynamic ones. Because UML offers a complete graphical notation but no modeling methodology, our efforts have been focused on the development of a systematic design procedure to make the task of developing the control software system easier. By using UML, we have proposed a new methodology for the analysis of FMCSs based on object-oriented discrete-event simulation software. Such a methodology consists of developing a metamodel of the control system that aims at solving the present limited integration between OO analysis and design and OO programming research. The reusability, extendibility, and modifiability, as well as other characteristics that lead the FMCSs to success, are assured. Reusability is demonstrated by reusing the manufacturing

FLEXIBLE MANUFACTURING CONTROL SYSTEMS ANALYSIS AND DESIGN

215

cell model for constructing the whole flexible manufacturing system model. Extendibility and modifiability are assured by the OO concept of inheritance, thanks to which a new manufacturing element (machine, robot, PLC, and cell) can be introduced in the model as a subclass of another, that is already defined, by only specifying its new properties and behaviors without significant modifications in the model. Moreover, in the example of FMCS development presented, reusability and scalability are also demonstrated by changing system configuration, either operational (changing of PLS) or strategic (changing the exceptions handling policy). Our efforts in future will be focused on applying the methodology to more real FMCS in which, for example, material handling systems and assembly systems are considered. Furthermore, such an approach will be applied to decentralized control architecture, because, in many production conditions, such architectures are recognized to be more advantageous than the centralized ones. Acknowledgments This research was supported by a grant from the Italian Ministry of University and Research in Science and Technology. The authors are grateful to one of the referees for her/his careful scrutiny and her/his helpful remarks, which improved the presentation considerably. References Aguirre, O., Weston, R., Mart´ın, F., and Ajuria, J. L., “MCSARCH: An Architecture for the Development of Manufacturing Control Systems,” International Journal of Production Economics, Vol. 62, pp. 45–59 (1999). Booth, A. W., “Object-Oriented Modeling for Flexible Manufacturing System,” International Journal of Flexible Manufacturing Systems, Vol. 10, No. 3, pp. 301–314 (1998). Bruccoleri, M. and Pasek, Z., “Operational Issues in Reconfigurable Manufacturing Systems: Exception Handling,” in Proceedings of the 5th Biannual World Automation Congress 2002, Orlando, FL, Vol. 3 (June 2002). Bruccoleri, M., Perrone, G., and Noto La Diega, S., “Object-Oriented Modeling for Concurrent Engineering Design,” in Proceedings of the 33rd CIRP International Seminar on Manufacturing Systems, pp. 341–346 (June 2000). Buzacott, J. A. and Shanthikumar, J. G., “Models for Understanding Flexible Manufacturing Systems,” AIIE Transactions, Vol. 12, pp. 339–350 (1980). CACI Products Co., MODSIM II Reference Manual, La Jolla, CA (1994). Comai, A., Analysis and Design Methods, http://www.analisi-disegno.com/ (1998). D’Souza, K. A. and Khator, S. K., “A Survey of Petri Net Applications in Modeling Controls for Automated Manufacturing Systems,” Computers in Industry, Vol. 24, pp. 5–16 (1994). Elia, G. and Menga, G., “Object-Oriented Design of Flexible Manufacturing Systems,” Computer Control of Flexible Manufacturing Systems, Chapman & Hall, New York, Chapter 12 (1994). Gong, D. C. and Lin, K. F., “Conceptual Design of a Shopfloor Control System from IDEF0,” Computers Industry Engineering, Vol. 27, pp. 119–122 (1994). Haddock, J., “Automated Simulation Modeling and Analysis for Manufacturing Systems,” Production Planning and Control, Vol. 6, No. 4, pp. 352–357 (1995). Hopkins, J. M., King, R. E., and Culbreth, C. T., “An Object-oriented Control Architecture for Flexible Manufacturing Cells,” Computer Control of Flexible Manufacturing Systems, Chapman & Hall, New York, Chapter 16 (1994). Joshi, S. B. and Smith, J. S., Computer Control of Flexible Manufacturing Systems, Chapman & Hall, New York, pp. 10–12 (1994).

216

BRUCCOLERI, NOTO LA DIEGA, AND PERRONE

R Kelton, W. D., Sadowski, R. P., and Sadowsky, D. A., Simulation with Arena
, McGraw Hill, New York (1998). Kov´acs, G. L., Kop´acsi, S., Nacsa, J., Haidegger, G., and Groumpos, P., “Application of Software Reuse and ObjectOriented Methodologies for the Modelling and Control of Manufacturing Systems,” Computers in Industry, Vol. 39, pp. 177–189 (1999). Malan, R., Letsinger, R., and Coleman, D., Object-Oriented Development at Work: Fusion in the Real World, Prentice-Hall, Upper Saddle River, NJ (1995). Rational Software Corporation, Analysis and Design with UML, CA (1997). Rational Software Corporation, “Using Rose,” Rational Solutions for Windows, CA (1999). Renna, P., Perrone, G., Amico, M., and Bruccoleri, M., “A New Decision Making Strategy For Distributed Control of Cellular Manufacturing Systems,” Intelligent Engineering Through Artificial Neural Networks, C. H. Dagli, A. L. Buczak, J. Ghosh, M. Embrechts, O. Ersoy, and S. Kercel (Eds.), ASME Press, New York, Vol. 11, pp. 975–980 (2001). Shaw, M., “Introduction to the Special Issue on Information-Based Manufacturing,” International Journal of Flexible Manufacturing Systems, Vol. 10, No. 3, pp. 195–196 (1998). Van Hillegersberg, J. and Kumar, K., “Using Metamodeling to Integrate Object-oriented Analysis, Design and Programming Concepts,” Information Systems, Vol. 24, No. 2, pp. 113–129 (1999). Venkatesh, K. and Zhou, M., “Object-Oriented Design of FMS Control Software Based on Object Modeling Technique Diagrams and Petri Nets,” Journal of Manufacturing Systems, Vol. 17, No. 2, pp. 118–136 (1998). Xiang, D. and O’Brien, C., “Cell Control Research—Current Status and Development Trends,” International Journal of Production Research, Vol. 33, No. 8, pp. 2325–2352 (1995). Zhang, J., Gu, J., Li, P., and Duan, Z., “Object-Oriented Modeling of Control System for Agile Manufacturing Cells,” International Journal of Production Economics, Vol. 62, pp. 145–153 (1999).