Object-oriented modeling and simulation of flexible manufacturing systems: a rule-based procedure

Object-oriented modeling and simulationof flexible manufacturing systems:

a rule-based procedure

A. Anglani a, A. Grieco a, M. Pacella a,*, T. Tolio b

a Dipartimento di Ingegneria dell�Innovazione, Universit�aa degli Studi di Lecce, Via per Arnesano,Lecce, 73100, Italy

b Dipartimento di Meccanica, Politecnico di Milano, Via Bonardi 9, Milano, 20133, Italy

Received 15 December 2001; received in revised form 22 May 2002

Abstract

Simulation by a software model, is one of the most frequently used techniques for the anal-

ysis and design of manufacturing systems. In the software engineering research area, the ob-

ject-oriented approach has fully demonstrated to be an effective technique with respect to the

design and implementation phases of complex software projects. Even if object-oriented pro-

gramming has proven to be a powerful technique, a systematic design method should also be

used in order to implement reliable software, in particular in the development of simulation

models. This paper presents a new procedure to develop flexible manufacturing system

(FMS) simulation models, based on the UML analysis/design tools and on the ARENA� sim-

ulation language. The two main features of the proposed procedure are the definition of a sys-

tematic conceptual procedure to design FMS simulation models and of a set of rules for the

conceptual model translation in a simulation language. The goal is to improve the software

development efficiency through a rule-based approach and to add some of the fundamental

object-oriented features to the ARENA� simulation environment.

� 2002 Elsevier Science B.V. All rights reserved.

Keywords: Manufacturing discrete-event simulation; Object-oriented programming; Flexible manufactur-

ing systems

*Corresponding author. Fax: +39-0832-320-279.

E-mail address: [email protected] (M. Pacella).

1569-190X/02/$ - see front matter � 2002 Elsevier Science B.V. All rights reserved.

PII: S1569-190X(02 )00100-4

Simulation Modelling Practice and Theory 10 (2002) 209–234

www.elsevier.com/locate/simpat

mail to: [email protected]

1. Introduction

A flexible manufacturing system (FMS) is an integrated production system com-

posed by a set of independent machining centers (MCs). An automatic part handling

system (PHS) interconnects the MCs to a group of part-storage locations such as

loading/unloading positions and input/output buffers. An automatic tool handling

system (THS) interconnects the MCs to a group of tool-storage locations as tool

magazines, tool rooms, exchangers and spindles [10,16]. Either the PHS and THSmechanisms consist of one or more automated guided vehicles (AGVs) or transport-

ers. A central supervisor (the FMS control software) monitors and manages the

whole system. Three different kinds of object flows may be identified: the material

flows (physical objects as parts, tools, pallets and fixtures), the information flows

(abstract objects that describe the system status), and the decision flows (abstract ob-

jects that modify the system status) [12,22].

The FMSs are complex and expansive systems that require an accurate designing

phase. In particular, it is important to examine closely the dynamic behavior of thedifferent FMS components in order to predict the performance of the production

system. The simulation is an essential tool for the design and the operational perfor-

mance analysis of complex systems that cannot be easily described by analytical or

mathematical models [19]. In particular, in the manufacturing field, the simulation

can be used to configure the production system, or to select the more appropriate

management rules [17].

The rapid expansion of the simulation software market accounts for the popular-

ity of this type of tool [14]. Various discrete-event simulation languages oriented tothe manufacturing environment are in use today. For example, ARENA� by System

Modeling [21] and AutoMod� by AutoSimulation [19] are two of the most com-

monly used simulation languages at this moment both in the academic and in the in-

dustrial field. These tools consist of a collection of high-level constructs allowing the

developer to achieve many of the tasks routinely required in the developing of a sim-

ulation project. Since their abstractions are focused to represent independent entity

flows between processes, each of these tools is commonly referenced to as transac-

tion-oriented discrete-event language. On the other hand, the object-oriented (O-O)simulation languages are based on a set of object classes that model the behavior

of real system components. An example of O-O simulation language that has been

adopted in manufacturing is eM-Plant� by Tecnomatix. An O-O software system

operates by allowing the objects to pass messages. Each message represents a request

to an object to perform certain functions.

Generally, an object model of a manufacturing system is designed by means of in-

termediate steps in which the real system components are described in an abstract

mode through three different types of flows: materials, information, and decisions[6]. However, the implementation of the relative simulation model is a difficult task

if the adopted approach does not guide the developers to associate their ideas of the

system under study with the simulation tools. Indeed, in many of current simulation

approaches, despite the existence of well-developed tools, it is often difficult to trans-

210 A. Anglani et al. / Simulation Modelling Practice and Theory 10 (2002) 209–234

form system requirements into the simulation program and the whole implementa-

tion process is still carried in an intuitive manner.

This paper presents a new O-O procedure to implement FMS simulation models.

The goal of the research is to provide developers of an integrated procedure that cov-

ers the whole development process (from the domain analysis to the software imple-

mentation). The modeling phase is based on the unified modeling language (UML)

[7]. The UML is a set of notations that have been standardized in order to represent

object-oriented software system. For the implementation phase, even if an object-ori-ented coding environment can be chosen, the ARENA� transaction-oriented simu-

lation language has been selected in the proposed procedure. The main advantage of

a language such as ARENA� is that it is commonly used in the industrial field for the

simulation of manufacturing and material handling systems (MHSs).

In the following sections of this paper the presented procedure will be referenced

to as UMSIS (UML Modeled SIMAN Implemented Simulation software) [2]. The

remainder of the paper is structured as follows. In Section 2, current literature

is analyzed. In Section 3, a brief overview of the tools exploited in the proposed pro-cedure, namely ARENA� and UML, is provided. The main features of UMSIS

are presented in Section 4. Section 5 describes in detail the conceptual model

design while the basic rules to translate the UML model in ARENA� code are illus-

trated in Section 6. The application of UMSIS to develop a part of a FMS simula-

tion model is demonstrated in Section 7.

2. Related researches

The choice of the O-O approach [4,11,25] to design manufacturing models is

mainly due to the complex nature of the problem. This paradigm requires that the

developers identify a set of objects from the problem domain and express the oper-

ations of the system as interactions (message passing) between these objects. In liter-

ature, several O-O applications and methodologies for the manufacturing can be

found [13,15,20,29]. Each author recognizes in the object orientation a valid ap-

proach in order to develop manufacturing simulation model. The main advantageof the O-O approach is the possibility to translate each component of the real system

in an equivalent element of code: the object. With this feature, the developer may

achieve a better and faster transition of the conceptual model into the software im-

plementation. Narayanan et al. [19] provide a review of the most diffused O-O meth-

odologies to design manufacturing system software models. A framework of analysis

for production system modeling approaches is also proposed in their work.

Different authors have proposed various modeling approaches that share a series

of well-known object-oriented concepts despite the fact they express them in differentways with different notations. For example, Chen and Lu [6] have presented an ob-

ject-oriented methodology to design production system software-models by means of

the Petri nets, the ERD (entity relationship diagram) and the IDEF0 (Integrated

DEFinition language for functional modeling). Wang [30] has suggested that an

A. Anglani et al. / Simulation Modelling Practice and Theory 10 (2002) 209–234 211

integrated approach is necessary in order to enhance the model designing efficiency.

Therefore, the author provides a methodology that is based on an integrated envi-

ronment, which covers the whole implementation process by means of a rule-based

procedure.

In the OOSIM methodology (Object-Oriented Simulation In Manufacturing

[3,18]) the requirement analysis is conducted by means of two domain decomposi-

tions: plant/control vs. processing/logistic. A method to model a general FMS behav-

ior framework and a procedure to design the related object-oriented simulationmodel has been both presented by Kellert et al. [12]. The aim of the study is mainly

to show that the O-O approach, for FMS simulation, confers characteristics of gen-

erality and modularity to the model and it allows the automatic translation into the

simulation language. For this purpose, a set of rules, for a systematic development of

SLAM II simulation code from a conceptual model, is provided. The work of Kellert

et al. underlines the need to make reworking of conceptual models, developed

through an object-oriented paradigm, into simulators that are implemented through

a proven discrete event transaction-oriented simulation language.In this work, the ARENA� simulation language has been used to develop

FMS simulation models. In the following section, a brief overview of both the ARE-

NA� simulation language and of the adopted object-modeling notation UML is pro-

vided.

3. Background of UMSIS tools: ARENA and UML

ARENA�, by System Modeling Corporation [21], is a graphical transaction-ori-

ented language for the discrete-event simulation; it is one of the most commonly used

simulation languages at this moment [1,8,15,23,26]. In the ARENA� software, the

language functionality is incorporated in the building blocks, called modules, with

which simulation models can be implemented. Basing on type and level of function-

ality, these modules are grouped together in panels called templates. In many cases, it

is rather simple to build a running model from the high-level modules available in the

language. Nevertheless, it may be difficult to implement a model if a required func-tion has not built in the language. Indeed, the native high-level ARENA� templates

may not be sufficient to build any simulation models, and the developers need to im-

plement their own object models in customized ARENA� modules.

The UML is a set of object-oriented modeling notations that have been standard-

ized by the object management group in order to represent every kind of software

system. [5,24,28]. It defines a meta-model based graphical notation that can be used

as a support for formal modeling [9,27]. The UML uses graphical notations to illus-

trate a system specification, and since the specification is usually complex, there areseveral diagrams available to provide different views (structural/static and behav-

ioral/dynamic) of the analyzed system. The UML diagrams include use case dia-

grams, class diagrams, interaction (sequence and collaboration) diagrams, state

transition diagrams, deployment diagrams, activity diagrams etc. In this paper, only

a subset of UML diagrams is used.


The UML reflects some of the best modeling experiences and it incorporates no-

tations that have been proven useful in practice. However, the UML in it-self does

not address problems of how using such notations or how translating a conceptual

model in a particular simulation language. Therefore, the implementation of a com-

plex system model may be a non-trivial task for the non-expert developer, as well as

for the expert one.

The proposed procedure aims to guide the developer to implement FMS simula-

tion models by means of the UML notation and the ARENA� language. More spe-cifically, the goal is to provide a design framework in which three developing tools

are integrated. The first one consists in a set of concepts that assist the developer

in the domain analysis phase. The second tool is a group of rules that guide the de-

veloper to translate a general model of the real system into the O-O model. Finally,

the third tool is a set of rules that help the developer to code each object class into the

ARENA� language.

4. The UMSIS procedure

The proposed procedure, graphically illustrated in Fig. 1, is composed of four dis-

tinct phases. While the first three ones aim to obtain a sound UML conceptual model

for the actual FMS reference environment, in the fourth phase the remarks related

with the ARENA� simulation code (i.e. the formal model) implementation are re-

ported.

UMSIS is based on specific abstraction concepts expressed by the UML notation.Two essential terms capture the essence of the UMSIS abstraction concepts: compo-

nents and use cases. A manufacturing system can be considered as a group of differ-

ent interacting components that are properly combined in order to process raw

materials. The components of a system react to events by executing activities based

on their roles and functions. When a component interacts with one another or re-

sponds to events, it may employ inputs, consumes resources and generates outputs.

Moreover, the component internal state may change as a result of interactions. A

simulation-system models these interactions, and it records their effects. The usecases are used to model interactions among components, each use case is considered

a particular functionality of the system. A use case spells out the action or the se-

quence of actions that a component should perform at the occurrence of certain

events. An action is a discrete activity that a component is able to perform. It usually

entails the change of a component�s internal state.The first step is the functional model design. It is developed through the UML use

case diagrams and it aims to identify the components and the use cases. The functional

model represents the system transformational aspects and it clarifies what the systemdoes (e.g. processing raw parts in order to obtain products) without specifying how

it works (e.g. how parts are moved among MCs). In UMSIS, the use case diagrams

are used in order to describe the high-level functionality for the modeled system.

The second step is the dynamic model design. It is developed by means of the UML

interaction diagrams (both the sequence diagram and the collaboration diagram). In


this phase the dynamic behaviors among each component, which interacts in a spe-

cific use case, are modeled (in detail) by means of actions and messages. The se-

quences of messages among components are modeled through a UML sequence

diagram. In the diagram, the messages passed among components are modeled withhorizontal lines, while the passing of time is indicated by a vertical position. A col-

laboration diagram shows a view of the interaction or structural relationships among

the components involved in the same use case. The difference between these diagrams

is that while the collaboration diagram specifies the relationships among the compo-

nents, the sequence diagram specifies the timing of the messages.

The third step is the object model design. It is developed through the UML class di-

agrams and it aims to specify the components internal structures and relationships. In

particular, in this step the functional and the dynamic specifications, derived from the

Fig. 1. Schema of the proposed procedure.


previous diagrams, are combined in order to obtain an appropriate objects class

group. A class diagram specifies the object internal structure by defining for each ob-

ject a specific name, the attributes, the methods and the relationships (such as inheri-

tance, aggregation or association) with the other objects. A particular feature of the

proposed procedure is that the object model designing is based on a set of rules

and on a general class framework. Such a framework enables to define an association

between the elements of a typical FMS and the equivalent object model, by deriving

the object attributes and methods from the functional and the dynamic model, respec-tively.

Since the developing of each phase may have effects on the previous ones, the

UMSIS procedure should not be considered a sequential approach. Nevertheless,

we suggest to build the dynamic model before the object model. Indeed, knowledge

about messages between components can be derived simply by analyzing the real-

system behavior (e.g. timing specifications). Afterwards, by applying the proposed

rule-based method, developers can build the more appropriate information struc-

ture. This is similar to a function-oriented approach, commonly used to buildreal-time software models (e.g. FMS control software). From our experience, this

approach may be more suitable for non-expert developers.

After the conceptual model has been fully developed, the discrete-event simulator

software is implemented in the fourth phase of the UMSIS procedure: the formal

model implementation. Of course, in order to that, a proper object-oriented program-

ming language can be selected (e.g. MODSIM by CACI or the general-purpose lan-

guage Cþþ). In addition, UMSIS provides a procedure that allows coding the

simulation software in the ARENA� language. This procedure consists in a set ofrules allowing to code in a detailed way for each object both the MODEL and the

concerning EXPERIMENT. This code is then encapsulated in a customized module

of a template that guarantees reusability of implemented software. The collection of

modules represents resources available for use in future development tasks; their reuse

occurs when developing new systems or extending currently implemented systems.

5. The conceptual model implementation

The definition and implementation of manufacturing simulation software is not a

trivial task. The complexity of the manufacturing environment makes difficult basic

questions like to recognize the correct starting point in particular when a new simu-

lation model must be built for the first time. The formal identification of the basic

simulation components and of their fundamental features may help to overcome

these difficulties.

Generally, a functional model shows the information flow inside a system: it de-scribes the resources and destinations of data as well as the activities of the transfor-

mation functions. In the UMSIS functional model design phase a domain analysis is

executed. The goal of this phase is to abstract the components of the system under

study and to represent the knowledge of the system functional rules in appropriate

uses cases diagrams.


The use case diagrams used in this phase are made up of actors that interact in use

cases. The use case diagrams are hierarchically organized. In this way the developers

may focus their attention only on a limited set of system behaviors and the real sys-

tem complexity may be described in subsequent steps of more detailed analysis. The

model hierarchy depth (i.e. the number of diagram levels) depends on the details re-

quired by the system analysis. Once identified, the system components are repre-

sented by classes. The UML class stereotypes (actor and interface) are used to

represent the general roles of the components within the system, while UML use caseassociations are used to formalize the specific roles assumed in each use case.

Since the result of this important phase will reflect the developer view about the

application domain, the proposed procedure provides a set of fundamental abstrac-

tion concepts. This set may be considered as the general abstraction of the basic

elements common to the main manufacturing environment. In detail, any FMS may

be decomposed into the following three sub-systems. The physical sub-system com-

posed by machines, tools, transporters, storage facilities and operators. The informa-

tion sub-system, which is in charge of storing, transmitting and communicating theinformation related to the system functioning and, finally, decision sub-system,

which controls the physical sub-system.

Hence, any FMS can be considered as a set of managers that control a set of re-

sources in order to perform some activities (as processing, movement and storage) on

a set of materials (physical or information).

Two orthogonal role types are defined for each component. Indeed, each compo-

nent has a specific role both in the whole system and in every single use case in which

it is involved. Consequently, each component has a single role in the system but itcan have different roles in different use cases.

The component roles in the model defined by UMSIS are the following ones,

while the component use-case roles are reported in Table 1:

1. outer component represented by UML stereotype actor (it will be not implemented

in the simulation code);

2. inner component;

3. interface component represented by UML stereotype interface.

Table 1

UMSIS component use-case roles

(a) The role material is assigned to those components which provide an input to a use case and/or receive

output from a use case; moreover they may be classified as:

(a1) physical material (represented by physical input and/or physical output use case association

stereotype)

(a2) information material (represented by information input and/or information output use case

association stereotype)

(b) The role resource is assigned to those components, which provide the mechanism exploited by other

components to execute the activity of use case. It is represented by mechanism use case association

stereotype

(c) The role manager is assigned to those components which provide the control of the use case to

execute the related activity. It is represented by control use case association stereotype


The UMSIS concepts that are used for the domain analysis are schematically rep-

resented by the following Fig. 2.

By adopting these concepts, the developer may represent the actual production

system under study in terms of several physical and information components, aug-

mented by decision-making components. These last components are the ones able

to make decisions that affect the behavior of the system. The model will create a dy-

namic operational plan in terms of time-phased decisions that need to be made to

drive the system towards a desired state.With the following list, a simple method of four steps is provided in order to de-

sign the functional model. In this method, the classification of the components and of

the use cases is obtained simply by means of the identification of the physical and

information flows within the system. By means of the recognition of these flows, it

may be possible to apply the UMSIS abstraction concepts.

1. The physical flow identification: by employing a top–down analysis and a func-

tional decomposition, the input/output relationships, among distinct activities(i.e. use cases) performed in the system, are identified by means of physical mate-

rial flows. The resources used to actualize such activities should also be specified

in the functional model.

2. The collaboration identification: any activity (i.e. use case) that has two or more

resources must be decomposing into sub-activities that are more detailed as to

each sub-activity has only one resource. An elementary use case will be referred

as a collaboration.

Fig. 2. Functional model design tools.


3. The decision flow identification: a manager for collaboration is identified by means

of a decision flow analysis.

4. The information flow identification: material flow analysis is completed by the

identification of information that each manager needs in order to control use

cases.

The result of this first phase is the functional model, which is a static representa-

tion of the system behavior without any explicit description of the activity sequences.In order to define the class structures in terms of attributes and operations, it is nec-

essary to analyze the dynamic system behavior, during the execution of all the col-

laborations. In the proposed procedure, this phase is defined as to the dynamic

model design. This model describes the temporal evolution, for each component,

of a specific collaboration, both in terms of sequences of events and of state trans-

actions. The objective is to define what actions must be accomplished by each com-

ponent and the derived effect, in term of component state changes. The UML

interaction diagrams are suitable tools that can be used for a complete and detailedrepresentation of software dynamic specifications. Therefore, in this particular

phase, no additional modeling procedure is provided by UMSIS. The interaction

diagrams are composed of components (objects) and interactions (messages and ac-

tions). They show how use cases are performed in terms of interactions (messages

sent) among a set of components. In order to achieve a more comprehensive analysis,

another UML tool can be used: the state transition diagrams. They show the se-

quence of states that a component goes through, the set of events that cause a tran-

sition from one state to another, and finally, the actions that result from a statechange or from an interaction.

After the definition of the functional and the dynamic models, the following step

is to design the object model. In this model, the developer can recognize what object

classes are involved in the simulator software. Furthermore, the relationship typol-

ogies among the defined classes must be provided.

The object model is based on three categories of analysis.

• The class identification. Since class finding depends on the particular consider-ations of each developer, there is no standard method for finding all the classes

in a system. In the proposed procedure, class finding through use cases diagrams

and interaction diagrams is suggested.

• The class relationship identification. The relationships among classes are estab-

lished because suitable generalizations or aggregations may lead in the possibility

of reusing the existing classes reducing furthermore the software development

time. Moreover, the generalization relationship may contribute to define new

classes.• The class structure identification. The attributes and the methods of each class

(i.e. the class structure) may be derived from the functional and the

dynamic models. In particular, the attributes are mainly derived from the use

case diagrams, while the class methods may be derived from the interaction

diagrams.


In order to implement the object model based on all the previous remarks, a com-

prehensive procedure is described in the following Table 2. The procedure is com-

posed by seven sequential rules that aim to support the developer to construct the

object model from the functional and the dynamic models previously implemented.

An integration of these rules is represented by a general framework developed

within the proposed procedure. The UMSIS Framework is a set of object classes that

represent typical FMS components. In particular, it is a set of elementary classes, or-

ganized according to a specific hierarchy. The reference classes are: Resource,Mate-rial and Manager. The classes and the related relationships are shown in Fig. 3.

A resource is a system component that can be used to execute a specific task (e.g.

to move a pallet or to process raw materials). In the proposed framework, a resource

can be represented at three levels of specialization. The first one is the more general.

At this level, a resource is simply represented by its status (e.g. idle, busy, etc.). The

classes at the second level of specialization are referred as StaticResource and

DynamicResource. They model, respectively, a fixed resource as a MC, and a non-

fixed resource as a transporter that moves material through the production system.The StaticResource is specialized (at the third level of hierarchy) in a Location

Resource class, used to abstract the parts of the FMS that can hold on materials

in processing (both physical and information). For example, it may models a buffer

in which pallets are deposited, or a queue of requests that are waiting for a specific

service.

Table 2

Object model implementing procedure

R1 IF a component system role is identified as an inner element THEN the component will be mapped

to an object class or to an attribute of an object class

R1.1 IF the component use case role is identified as a manager or a resource THEN the component

will be mapped to an object class

R2 IF the component system role is identified as an interface element THEN it will be mapped to an

object class method to perform the input and/or output operations

R3 IF a use case is collaboration THEN it maps to a method of the object class obtained by rule R1.1.

Moreover, the Manager or the Resource role must be referred to the specific collaboration

R4 IF the component use case role is identified as a material input THEN

R4.1 the component will be mapped to an object class IF the role is of physical material input;

R4.2 OTHERWISE, the component will be mapped to an attribute of the object class with the

method modeling the use case to which it is addressed

R5 IF the component use case role is identified as a material output THEN

R5.1 the component will be mapped to an object class IF the role is of physical material output;

R5.2 OTHERWISE, the component will be mapped to an attribute of the object class with the

method modeling the use case from which the output is produced

R6 each interaction between two components is mapped to an equivalent object class method associated

with the component that received the interaction

R7 the object class relationships (if any) must be identified by a further domain analysis. Moreover, any

other necessary attributes to completely define the classes must be introduced in this phase


A Material is an object class on which a transformation process, during the sim-

ulation, is performed from a raw material to a finished stage. The super type class, at

the first level is specialized into two subtypes PhysicalMaterial and InformationMa-

terial. They model objects of physical and information nature respectively. At thethird level, the information material class is specialized into the InInformation and

OutInformation on the base of their role respect to the simulation environment.

The decision control of the FMS is modeled by a set of Manager classes each su-

pervises a specific resource and co-ordinates other manager classes. Indeed, a man-

ager class is the active object of the simulation environment. The following Figs. 4

and 5 show in detail the UMSIS framework.

6. The formal model design

In this paragraph, a procedure to translate the UML conceptual model into an

ARENA� formal model (i.e. a software simulation model) is proposed. The ARE-

NA� version used is 3.5 (professional edition). Even if newer versions of this simu-

lation language have been released, they are only of minor importance in the context

of this paper. A basic description of the ARENA� language is presented in Section 3.

The reader is referenced to [21] for more details.Generally, the simulation software of a complex production system such as FMS

contains many modules with low functionality but high flexibility. For this reason,

Fig. 3. UMSIS framework architecture.


among the ARENA� templates, ELEMENTS and BLOCKS have been exploited asthe most basic panels. Each module of ELEMENTS and BLOCKS templates is

equivalent to one line of SIMAN code (the underlying code of ARENA�). All the

other templates are developed by aggregating the modules of the ELEMENTS

and BLOCKS panels. These high-level templates offer superior functionality but

only for specific environments.

A typical ARENA� simulator program consists of two complementary parts: the

EXPERIMENT (i.e. the static structure of the program) and the MODEL (i.e. the

processes that are simulated in the program). The ELEMENTS template is used toimplement the EXPERIMENT. In fact, the ELEMENTS describe all the static com-

ponents and their associated characteristics. These can include RESOURCES, STA-

TIONS, VARIABLES, ATTRIBUTES, QUEUES etc. On the other hand, the

BLOCKS template provides modules to implement the processes of the MODEL ex-

ploiting the information in the ELEMENTS. This logic may include modules as

SEIZE (of a resource), RELEASE (of a resource), ASSIGN (a value to a variable

or to an entity attribute), QUEUE (queuing an entity) etc. Once the various modules

have been inserted in the modeling area, they need to be connected to indicate theroutes that might be followed by the ARENA� ENTITIES. In practice, this consists

in a graphical programming of the SIMAN language.

Fig. 4. Resource classes framework.


In order to implement the object-oriented architecture designed in previous steps,

each object class needs to be mapped to a customized ARENA� module composed

by a proper EXPERIMENT and an appropriate MODEL.In detail, the simulation code is obtained by:

1. a mapping between the static structure of object classes (i.e. their attributes) and

the ENTITIES and/or ELEMENTS modules;

2. a mapping between the dynamic structure of object classes (i.e. their methods) and

the BLOCKS modules.

The EXPERIMENT is implemented to reproduce the class architecture defined inthe object model, while the MODEL is build to execute the methods that have been

specified in the dynamic model.

In particular, the EXPERIMENT is made up of (1) various ELEMENTS mod-

ules and/or (2) ENTITIES produced by the block CREATE. The object class attri-

butes can be modeled in the former case by the VARIABLES module and, in the

latter, by the ATTRIBUTES module.

In the class diagrams of the UMSIS framework (Figs. 4 and 5) the relationships

between the classes and the ARENA� modules are schematically described. For

Fig. 5. Material and Manager classes framework.


example, it can be noticed that the super-class �StaticResource� is derived from the

class RESOURCES (that is a module of the ARENA� basic template ELEMENTS).

Yet, the same class � StaticResource� is also derived from the class VARIABLES (an-

other module of the ARENA� basic template ELEMENTS) that is inherited by the

class �Resource�. In order to help the developer to implement the simulation softwarein Table 3 a useful set of mapping rules are derived from the UMSIS framework.

For example, if a class of the conceptual model (e.g. �Machine�) specializes a spe-cific UMSIS class (e.g. �StaticResource�), then the appropriated modules for theEXPERIMENT are those indicated in the associated column of Table 3 (i.e. VARI-

ABLES and RESOURCES).

As may be noticed, the cardinality of the relationship between the UMSIS classes

and the ARENA modules is of type �1 to n�. The multiplicity depends on the specificcase. For example, a class that is derived from the super-class �StaticResource� (e.g.�Machine�) can be implemented just using the module RESOURCES. In this way, itis possible to code typical attributes of a �Machine� class. Nevertheless, the developerwould want to add more attributes (e.g. the status of machining) by means of theVARIABLES module.

Since collaborations has been coded as networks of BLOCKS modules, before ap-

plying the mapping table, it should to be checked that the element that initiates a col-

laboration has been coded into object classes derived from �Manager� or �Material�.In fact, as reported in Table 3, only �Manager� and �Material� classes map to a per-manent entity and only a permanent entity can generate a method entity (e.g. by a

DUPLICATE block).

The ENTITIES can assume a double role, namely:

• object-entity, if it is used to code a specific object class; it can be a permanent en-

tity (�Pentity� if it is never disposed during simulation) or a transient entity (�Ten-tity� on the contrary);

• method-entity, if it has been created only to active a specific process that models a

class method (a method-entity is a �Tentity�).

While an object-entity is used to code a specific object class instance, a method-entity is used to code an object-method invocation from another object. For exam-

ple, in the case of a client-object that calls a server-object method with assigned

parameters, the ARENA� implementation may be the following. The client creates

a method-entity with some attributes set up in order to carry all the input parameters

and sends this new method-entity to the proper ARENA� block sequence that mod-

els the server-method. Each of this sequence has a starting block that is commonly a

STATION-block (to identify the object method) and an ending block that is nor-

mally a DISPOSE-block (to stop the object method). In detail, starting block is usedto recognize both the method and the object, which is associated to, while ending

block is used to end the method-execution by destroying the method-entity. To rec-

ognize the method it is necessary to send a method-entity to the proper STATION

block. This is obtained naming each method STATION block with a name in a par-

ticular format: �<Object Name>_<Class Name>_<Method Name>�. Furthermore,


Table 3

Conceptual to formal model mapping table

UMSIS classes

Manager Material Resource

Physical Information Physical Dynamic Static

Information In Out Static Location

Pentity � �Tentity � � �

Elements modules Variables � � � �Files � �Report �Resources � �Transporters �Conveyors �Stations �Storages �Queues � �

224

A.Anglanietal./SimulationModellin

gPractice

andTheory10(2002)209–234

each of these station blocks is labeled in a special format: �IN<station name>�; either�IN<Object Name>_<Class Name>_<Method Name>�.The DUPLICATE module is the block that can be used to create a method-entity

by a client-object-entity. Such an instruction allows duplicating an entity with all its

attribute values. In order to recall the client-entity that called the method, method-

entity is marked with a special attribute named �IDENT_PARENT� that providesthe IDENT value of the object-entity that has generated it. Since each entity has

its specific IDENT value, server can recognize client i.e. to set some of its attributes(as the output method results). After a method-entity has been created, and sent to

the proper STATION block, the client-object-entity waits for the fulfillment of the

method execution in a WAIT block. The method execution completion is underlined

by a signal send by method-entity (coded by ARENA� SIGNAL block) before it will

be disposed. Since signal code must be exclusively associated with the client-object,

its value is choosing equal to the IDENT (either IDENT_PARENT attribute of the

method entity).

Finally, the MODEL and the EXPERIMENT, which code the behavior of a par-ticular class may be encapsulated in a template that guarantees reusability of the im-

plemented object class. The proposed procedure results in a particular ARENA�

programming approach in which the developer may build a simulation program

by means of customized modules that do not need to be interconnected. The modules

are grouped in templates, and the resulting simulation software is a collection of in-

stantiations of such modules (i.e. the objects). Each module interacts with the others

via a message-passing schema rather than entity flows among independent processes.

Moreover, each module encapsulates its inner working, which is hidden to a finaluser that can use it by means of a specific interface.

Furthermore, the implementation of a simulation program by means of custom-

izes modules may provide the simulator of the O-O hierarchy feature. In fact, once

a �super-type� class is coded and packaged in a module of a specific template it canbe reused in order to build a �sub-type� module. This is obtained by including

in the ARENA� code of the �sub-type� module the template that contains the�super-type� one. The �sub-type� code is then implemented by adding the necessarycode to specialize its behavior without any modification to the �super-type� modulecode.

7. An UMSIS application example

In this section, the modeling procedure is illustrated by a simple case study. The

basic description of the UML semantic used in the following diagrams is provided in

Section 3; for a detailed explanation the reader is referenced to [5,28].In the following application example, the reference environment is a FMS com-

posed by several MCs and managed by a central supervisor. The main purpose of

an MC is to transform raw parts in final products. The overall-machining phase ex-

ecuted by an MC on a part is composed by a sequence of elementary machining pro-

cesses, referenced to as operations. The list of operations for each part is called the


part program. Usually each operation is executed by means of a specific tool, and it

requires a certain amount of time. Parts are moved by the MHS between MCs and

load/unload tables. The MHS is based on AGV managed by the central supervisor.

The decisions of the central supervisor are based on a set of move requests each re-

porting source–location and destination–location. When a part has been transported

by AGV system to a MC, the MC controller retrieves from the part program infor-

mation about the machining operations (tool type, technological constraints etc.).

When all operations are executed, the MC controller stores information about themachining process executed and it sends to the central supervisor a request of move-

ment. In the remainder of this section the UMSIS procedure schematically described

in Fig. 1 is applied to build the simulation code of the MC.

The first phase is implementation of the functional model. This is obtained by

means of the identification of physical and information flows within the system.

(1) Starting from previous description, two main functions (or use cases), namely

MANAGE PART FLOW and WORK, are identified. The former models themovement of the Part component using the PartTransporter resource. While

the Part component represents a �physical output� for the MANAGE PART

FLOW function (i.e. the change of position within the system) the PartTrans-

porter component represents the �mechanism� that is used by the same function.The WORK function models the machining of Part. Hence, Part component

represents the �physical input� for WORK function, while theMachine represents

the �mechanism�. Since Part has a physical nature, it is modeled as a �physicalmaterial� while the PartTransporter and the Machine components are modeledas �resources� because they are used by other components.

(2) Each of the identified activities can be considered as an elementary collaboration

indeed each of they is based on a single resource use.

(3) The MANAGE PART FLOW function has to be �controlled� by a specific �man-ager� component. This new component is called PartFlowManager.

(4) The information components in order to execute the activities are the following.

(1) The Production Data component that models the information needed by the

PartFlowManager component. (2) The System Performance component thatprovides the MC performance results. (3) The Part Program component, it re-

ports for each part type the complete operation list. (4) The PartMoveRequest

component that represents the movement request from one position to another

one.

While Production Data, System Performance and Part Program components are

modeled as interface components, the PartMoveRequest component represents an in-

ternal information because it models an inner behavior of the system. The resultingfunctional model is illustrated in Fig. 6. It can be noticed that all the component

roles are defined by means of the class stereotypes and the association stereotypes

that have been discussed in Section 5.

Once defined the functional model, it is necessary to specify the dynamic view of

the system behavior. The goal is reached by identifying the dynamic specification for


each component and their relative interactions within a specific use case. The use

case that is analyzed in this example is the WORK use case.

In Fig. 7, the sequence diagram detailing the WORK use case is depicted while

Fig. 8 shows the collaboration diagram. In particular, the collaboration diagram

shows the relationships that occur between components in the WORK use case. Itmay be observed that the collaboration WORK is started by the Part component.

Fig. 6. Use case diagram for the application example.

Fig. 7. Sequence diagram for the WORK use case.


The first interaction (i.e. Seize) is created in order to simulate the arrival of a Part

component on the actual MC. The second message (Read) simulates the retrieval of

the operation information (i.e. the duration and tool type). The execution of eachoperation is simulated by means of the third message (Delay), while the modification

of the Part component status is modeled with the forth message (Assign). When all

operations on the actual machine are performed, a new request (PartMoveRequest) is

created with the fifth message (Assign). The PalletFlowManager component receipts

this information and it schedules the missions of the PalletTransporter component

(not reported). Finally, with the sixth message (Release) is simulated the release of

the Machine component. This final message concludes the WORK use case.

The last step in order to complete the conceptual model is the design of the objectmodel. By applying the UMSIS translation rules reported in Table 2, it is possible to

derive the model reported in Fig. 9.

TheMachine component is mapped to the class �Machine� (rule R1.1), so as to thePartProgram component is mapped to the class �PartProgram� (rule R2). All the in-formation about operations is mapped to attributes of the �PartProgram� class. Thecollaboration WORK is mapped to a public method of the class �Machine� (rule R3).With the rule R4, the �Part� class is derived from the Part component, while by means

of the rule R5, �PositionMoveRequest� attribute of the �Machine� class is also ob-tained from the PartMoveRequest component.

A further information analysis of real system allows the completion of the object

model. In particular, the attribute �PartCode� is included in the �Part� class: it allowsthe association of a part to a production lot. The �WorkStatus� is the attribute of�Part� class that represents the operation performed on each �Part� object. The attrib-

Fig. 8. Collaboration diagram for the WORK use case.


ute �name� is associated to the �Machine� class in order to identify each object. Theassociation relationship between �Part� and �Operation� �Realize� is also created.It is useful to note that the rule-based approach allows developers to derive the

more appropriate object model from the dynamic model. In this way, non-expert de-

velopers can focus their attention only on the functionality of real system rather than

on the information analysis of the software model.

Once defined the conceptual model, the formal model can be implemented in the

ARENA� environment. The goal is reached by implementing the EXPERIMENTand the MODEL for each object class. In this example, the interest will be focused

on the �Machine� class. The EXPERIMENT, obtained using the relationships re-ported in Table 3, consists of one RESOURCE module, one STATIONS module

and one VARIABLES module. The RESOURCE module is used to code the status

of the resource (i.e. busy, idle, inactive or failed). The VARIABLES module is used

to implement the attribute �PositionMoveRequest� of the same class, while the STA-TIONS module is used to implement the unique method of the class (i.e. WORK).

The MODEL is composed by a single STATION that is used to model theWORK method of the class. The name of this module is obtained linking the name

Fig. 9. Class diagram.


of the instantiation (reference to as �name�), to the name of class (�Machine�) and tothe name of method (WORK). Comparing the MODEL (Fig. 10) with the collabo-

ration diagram (Fig. 8) it can be observed the association between the six actions of

Fig. 10. ARENA� implementation details.


the method WORK and the modules of the BLOCKS template that have been used.

Moreover, the final module SIGNAL is used to inform the calling object that the

method has been accomplished, while the module DISPOSE is used to end the meth-

od running.

Fig. 10 depicts both the EXPERIMENT and MODEL that are implemented to

simulate the method WORK of the �Machine� class.It can be observed in particular what the role of �PositionMoveRequest� is. It is

equivalent to a public attribute of the class �Machine� that can be accessed by �Part-FlowManager� object for scheduling the AGV missions. The decision logic of such

an object, that for simplicity has not been included in the example, results as not de-

pendent by the simulated layout. This is so because modules do not need to be con-

nected for indicating the route that must be followed by entities. Developers need

only to place modules in the modeling area; next, they can implement an arbitrary

decision logic that interacts with the modules via a message-passing paradigm. This

way of programming in ARENA� language is more close to object-orientation and

it allows obtaining programs that can be re-utilized in various cases and for differentsimulation models.

Once the EXPERIMENT and the MODEL, that implement a particular class,

have been built, the software code may be packaged in a specific template module.

In the analyzed case study, the �Machine� class is coded into a customized ARENA�

module named MACHINE. Each instantiation of this module has a unique identifier

that is referenced to by means of the prefix �name�. This identifier is equivalent tothe attribute �name� of the �Machine� class. Fig. 11 shows the MACHINE module

Fig. 11. Two Machine module instantiations and relative dialogue window.


interface obtained by means of the ARENA� template window. The dialog window

is usually divided into two sections. The first one reports the attributes of the class

while the second the related methods. The first section of the MACHINE dialog win-

dow shows the class attribute values, namely: the �name� and �PositionMoveRequest�values of the Machine object. Even if the users may assign the value of the attribute

name, they cannot modify the value of the �PositionMove� Request attribute. Indeedthis attribute reports only the name of a global VARIABLE that can be referred by

other objects.For each class �Machine�, more than one instantiation can be implemented. Fig.

11 depicts two instantiations of the Machine class. Of course, each object instantia-

tion of the Machine class will have a unique �name� (e.g. Machine 1 and Machine 2).The second section of the dialog window shows the labels for each method imple-

mented by the object class. In this case is showed the label of the WORK method.

To invoke the WORK method of the �Machine 2� object, an object-entity (i.e. a part)has to duplicate itself in a method entity that will be sent to the ARENA� block la-

beled �INMachine 2_Machine_WORK�. This block is the STATION block named�Machine 2_Machine_WORK� implemented by the second instantiation of MA-

CHINE module.

The use of the MACHINE module allows developers to model arbitrary layout

just inserting modules in the modeling area. Each MACHINE module is character-

ized by a specific attribute that indicates if AGV mission is required or not (�Position-MoveRequest�). The decision controller may analyze this information and,

independently by system layout, it may schedule the AGV missions. As result, the

same decision code can be re-utilized for different scenarios and different simulationstudy.

8. Conclusions

In the field of FMS simulation, a need exists to develop a modeling procedure in

which an object-oriented design phase is integrated to an implementation phase that

is made with a common transaction-oriented simulation language [12]. In this paper,a new procedure to develop FMS simulator software (UMSIS) is presented. The

object is to formulate a new procedure for developing reusable, modifiable and ex-

tendible discrete-event simulation-software using an object-oriented approach imple-

mented in a transaction-oriented language.

The work involved here includes the use of UML for specifying the system�s re-quirements, a set of concepts to model FMSs, and a procedure that can be used

to automate the construction of ARENA� programs from UML specifications.

The proposed procedure aims responding to the need of simulation developer byidentifying the objectives of the model development and by guiding the modeler in

the execution of the process to achieve those objectives. UMSIS includes methods,

techniques to accomplish individual tasks, and it prescribes an order in which each

task is made.


The procedure described in this paper has been used in a FMS simulation project.

The authors would welcome suggestions and remarks for the use of UMSIS in dif-

ferent contexts or for different tasks.

Acknowledgements

The work described in the paper has been partially funded by Ministry of In-

struction, University and Research (MIUR) of Italy project PRIN2000––prot.

MM09164148_004 �Models for capacity planning in advanced manufacturing sys-tems�. The authors thank also the anonymous referees who have contributed to im-prove the quality of the paper.

References

[1] 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.

[2] A. Anglani, A. Grieco, M. Pacella, Q. Semeraro, T. Tolio, SIMAN implementation of manufacturing

model defined with UML: application to a real case, in: Proceedings of the 13th European Simulation

Multiconference, Warsaw, Poland, 1999, pp. 194–199.

[3] D.A. Bodner, T. Govindaraj, L.F. McGinnis, C.M. Mitchell, An integrated approach to modeling

distributed manufacturing control and human operators, Proceedings of the 1995 IEEE International

Conference on System, Man, and Cybernetics, Vancouver, Canada, 1995, pp. 3437–3442.

[4] G. Booch, Object-Oriented Analysis and Design with Application, second ed., Benjamin/Cummings,

Menlo Park, CA, USA, 1994.

[5] G. Booch, J. Rumbaugh, I. Jacobson, The Unified Modelling Language User Guide, Addison-

Wesley, Longman, Reading, MA, USA, 1999.

[6] 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.

[7] C.A. Costa, J.A. Harding, R.I.M. Young, The application of UML and an open distributed process

framework to information system design, Computers in Industry 46 (2001) 33–48.

[8] H. de Swaan Arons, C.A. Boer, Storage and retrieval of discrete-event simulation model, Simulation

Practice and Theory 8 (2000) 555–576.

[9] R. France, A. Evans, K. Lano, B. Rumpe, The UML as a formal modeling notation, Computers

Standards and Interfaces 19 (1998) 325–334.

[10] A. Grieco, Q. Semeraro, T. Tolio, S. Toma, Simulation of tool and part flow in FMSs, International

Journal of Production Research 33 (3) (1995) 643–658.

[11] I. Jacobson, M. Christerson, P. Jonsson, G. Overgaard, Object-Oriented Software Engineering,

Addison–Wesley, Longman, Reading, MA, USA, 1992.

[12] P. Kelleret, N. Tchernev, C. Force, Object-oriented methodology for FMS modelling and simulation,

International Journal of Computer Integrated Manufacturing 10 (6) (1997) 405–434.

[13] R.E. King, K.S. Kim, AgvTalk: an object-oriented simulator for AGV systems, Computers in

Engineering 28 (3) (1995) 575–592.

[14] P. Klingstam, P. Gullander, Overview of simulation tools for computer-aided production engineering,

Computers in Industry 38 (1999) 173–186.

[15] G.L. Kov�aacs, S. Kop�aacsi, J. Nacsa, G. Haidegger, P. Groumpos, Application of software reuse and

object-oriented methodologies for modelling and control of manufacturing systems, Computers in

Industry 39 (1999) 177–189.


[16] W.W. Luggen, Flexible Manufacturing Cells and Systems, Prentice Hall, New Jersey, USA, 1991.

[17] R.D. Macredie, R.J. Paul, Simulation modelling in manufacturing system design: an overview,

International Journal of Manufacturing System Design 2 (3) (1995) 233–247.

[18] S. Narayanan, D.A. Bodner, U. Sreekanth, T. Govindaraj, L.F. McGinnis, C.M. Mitchell, Modeling

control decision in manufacturing systems simulation using object, in: Proceeding of the 1994 IEEE

International Conference on Systems, Man, and Cybernetics, San Antonio, USA, 1994, pp. 1392–

1397.

[19] 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.

[20] 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.

[21] C.D. Pegden, R.E. Shannon, R.P. Sadowski, Introduction to Simulation Using ARENA, McGraw-

Hill, New York, USA, 1995.

[22] H. Pierreval, On the simulation modelling of control activities in manufacturing systems, in:

Proceedings of the 13th European Simulation Multiconference, Warsaw, Poland, 1999, pp. 439–445.

[23] T. Perera, K. Liyanage, Methodology for rapid identification and collection of input data in the

simulation manufacturing systems, Simulation Practice and Theory 7 (2000) 645–656.

[24] Press release, Object Management Group adopts Unified Modeling Language and Meta Object Faci-

lity Specification, November 17, 1997, Available from <http://cgi.omg.org/news/pr97/umlpr.html>

(January �02).[25] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen, Object-Oriented Modeling and

Design, Prentice Hall, New Jersey, USA, 1991.

[26] Y.J. Son, R.A. Wysk, Automatic simulation model generation for simulation-based real-time shop

floor control, Computers in Industry 45 (2001) 291–308.

[27] The UML Group, UML Metamodel, Version 1.1, Rational Software, Santa Clara, CA-95051, USA,

September 1997.

[28] The UML Group, Unified Modeling Language, Version 1.1, Rational Software, Santa Clara, CA-

95051, USA, July 1997.

[29] J.M. Usher, A tutorial and review of object-oriented design of manufacturing software systems,

Computers in Engineering 30 (4) (1996) 781–798.

[30] L.C. Wang, An integrated object-oriented Petri net paradigm for manufacturing control systems,

International Journal of Computer Integrated Manufacturing 9 (1) (1996) 73–87.


http://cgi.omg.org/news/pr97/umlpr.html

Documents

Object-oriented modeling and simulation of flexible manufacturing systems: a rule-based procedure