<%BANNER%>

RUBE_QM: A 3D Simulation and Modeling Approach for Queuing Systems

Permanent Link: http://ufdc.ufl.edu/UFE0005360/00001

Material Information

Title: RUBE_QM: A 3D Simulation and Modeling Approach for Queuing Systems
Physical Description: Mixed Material
Copyright Date: 2008

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0005360:00001

Permanent Link: http://ufdc.ufl.edu/UFE0005360/00001

Material Information

Title: RUBE_QM: A 3D Simulation and Modeling Approach for Queuing Systems
Physical Description: Mixed Material
Copyright Date: 2008

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0005360:00001


This item has the following downloads:


Full Text












RUBE QM: A 3D SIMULATION AND MODELING APPROACH
FOR QUEUING SYSTEMS


















By

NAMKYU LIM


A THESIS PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
MASTER OF SCIENCE

UNIVERSITY OF FLORIDA


2004



























Copyright 2004

by

Namkyu Lim































To my country,

my mother, my wife, my daughter, my son,

my father-in-law, and my mother-in-law















ACKNOWLEDGMENTS


I would like to offer my sincere appreciation to my advisor, Dr. Paul A. Fishwick,

for his insightful advice and suggestions in this research and for giving me the

opportunity to work on this interesting topic. I express my deepest thanks to Dr. Joachim

Hammer and Dr. Sumi Helal for serving on my committee.

I thank my Modeling and Simulation Lab colleagues, Minho Park, Jinho Lee, and

Hyunju Shim, for their time and technical assistance. I would especially like to thank

Jinho Lee for his continual advice during my research. I will never forget all of our

intensive discussions.

I am most grateful to my country, my mother, my wife, and my father-in-law and

my mother-in-law for their support, encouragement, and prayers.
















TABLE OF CONTENTS

page

A C K N O W L E D G M E N T S ................................................................................................. iv

LIST OF FIGURE S ......... ..................................... ........... vii

ABSTRACT .............. ......................................... ix

1 IN TR OD U CTION ............................................... .. ......................... ..

1 .1 M o tiv atio n ...................................................................................................... .... 1
1.2 O organization of This Thesis......................................................... ............... 2

2 BACKGROUND KNOW LEDGE.......................................... .......................... 3

2 .1 Q ueuing M odel (Q M ) ............................................................................. ..... .3
2.2 XM L-based Technologies .............................................................. 4
2.2.1 eXtensible M arkup Language (XM L)..................................... ..................
2.2.2 XM L Schem a...................... ... ...... ... .................. ... ................5
2.2.3 eXtensible Stylesheet Language Transformation (XSLT) .......................5
2 .3 R U B E ..................................................................... ....................... 6

3 R E L A T E D W O R K ........................................................................ ....................... 10

3.1 TOMAS: Tool for Object-Oriented Modeling And Simulation ........................10
3.2 A Meta-Modeling and Model-Transforming (AToM3) .................. .............11
3.3 Simulation Reference Simulator................................ ......................... ....... 12
3.4 JavaSim ........... ......... ....................................... ................... 13

4 RUBE QM FRAM EW ORK S ........................................................ ............. 14

4.1 R U B E Q M O overview ................................................ .............................. 14
4.2 RUBE QM Model Elements................................................... ...................15
4.3 RUBE QM Fram ew works ......................................................... .............. 18
4.3.1 Event Scheduling .............................................. .... .. ................18
4.3.2 RUBEQM Frameworks ................................................................ ...... 18

5 M OD ELIN G IN RU BE QM ........................................................... ............... 21

5.1 M X L M odel Structure ................................................ .............................. 21










5.2 JavaScript Function in RUBE_QM ............................... ...............28
5.3 Scene File in RUBE QM ................ .................................32

6 TRANSLATION IN RUBE QM .............................................................. .....34

6.1 Overview ...................................... .......... ......... ..... 34
6.2 MXL to DXL Translation..............................................35
6.3 DXL to JavaScript Translation .............. ...................... ....................38
6.4 Model Fusion Engine and Translation from X3D to VRML .............................40
6.5 M odel Simulation ....................................... ........ ... .....42

7 CONCLUSIONS ...................................................44

APPENDIX SCHEM A FOR M XL ............................................ ...............46

LIST OF REFERENCES ..................................... ............... ....................63

BIOGRAPHICAL SKETCH .................................................. ............... 65
















LIST OF FIGURES

Figure pge

2-1. R U B E architecture....... ......................................................................... ....... .... ....

4-1. Model elements to define the queuing model semantics....................................... 15

4-2. MXL topology of RUBEQM............................................... ............... 17

4-3. A 2D example of a queuing model file in MXL.................................................... 19

4-4. A 2D example of a queuing m odel in DXL..................................... .....................19

5-1. M odel topology in M X L .................................................. ............................... 22

5-2. 2D diagram of CPU Disk queuing model.............................. .............23

5-3. MXL definition of one CPU four Disks queuing model ................. .................23

5 -3 C o n tin u ed .............................. ............................................................ ............... 2 5

5-4. Queuing model elem ents and attributes.................................. ........................ 27

5-5. Qnet.js: user-defined model behavior file ......................................................... 28

5-6 sou rce F l.js ................................ .......... ........ ................................2 9

5-7. requestQ .j s .................................... .......................................... ...... 30

5-8. release_Q .js ......................................................................... 30

5-9. fork F 2j s. ....................................................... ................. 30

5-10. j oin F 5.j s ......... .... .............. ................................ ....................... 3 1

5 -1 1 sin k F 5.j s ...................................................... ................ 3 2

5-12. An Avatar and CPUDisk presentation.................................. ........................ 33

6-1. A DXL segment of CPUDisk model ................. ................................ 36

6-2. A DXL segment of CPUDisk facility........................... ............................... 37









6-3. Queuing model DXL diagram for CPUDisk......................................................38

6-4. Simulation JavaScript and VRM L file ............................................ ............... 40

6-5 Final RUBE_QM Output segm ent ........................................ .......................... 41

6-6. Example of a VRML Script node................................................. 42

6-7. A snapshot of CPUDisk VRML file with dynamic............................... ...............43














Abstract of Thesis Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Master of Science

RUBE QM: A 3D SIMULATION AND MODELING APPROACH
FOR QUEUING SYSTEMS

By

Namkyu Lim

August 2004

Chair: Paul A. Fishwick
Major Department: Computer and Information Science and Engineering

The RUBE architecture was developed in the Graphic, Modeling and Art Lab at the

University of Florida to support a Web-based customized multimodel modeling and

simulation development. An emergence of eXtensible Markup Language (XML) brought

a new way of representing information and knowledge on the World Wide Web. XML is

convenient for modeling and configuring graphical elements, and it opens a new method

of sharing these entities over the Web. The RUBE architecture takes advantage of these

XML technologies.

The goal of this research is to expand the supporting model type of RUBE to a

queuing model. Currently, RUBE supports modeling and simulation of FBM (Functional

Block Model) and FSM (Finite State Machine) model types with a 2D or 3D model

representation. Since RUBE was built based on the XML technologies, it is easy to add

new modeling and simulation development frameworks in the RUBE architecture. In

order to add new model frameworks to the RUBE architecture, the architecture must be









compatible with the RUBE architecture. It must support the main goal of RUBE, which

supports an easy construction of a personalized and customized model with a Web-based

visualization.

To achieve the above requirement, RUBE_QM follows the methodology of the

RUBE system. In order to support the queuing model, RUBE_QM needs to define the

new model elements and semantics in Multimodel eXchange Language (MXL) written in

XML. The XML document handling mechanism is used along with the name

correspondence. Therefore MXL easily expands its model type definition.

In addition to the MXL definition, RUBE_QM requires a new data structure to

store events for a given amount of time inside of the simulation environment. The

RUBE_QM translator generates JavaScript files to support the queuing model event

handling mechanism, and uses an event scheduling method to execute the model. Other

model types in RUBE architecture are also executed by the event scheduling method.

Since events in RUBE_QM are executed by the identical execution method as the other

model types in RUBE, RUBEQM can be used for modeling and simulation with

heterogeneous model types.

The RUBE_QM is an expanded version of RUBE supporting FBM, FSM, and the

queuing system modeling and simulation. The XML-based technologies are used with

ease as leverage in expanding the application boundary of RUBE














CHAPTER 1
INTRODUCTION

1.1 Motivation

RUBE is a modeling and simulation framework for 2D or 3D dynamic models. The

main purpose of RUBE is to provide users the freedom of presentation from the

complicated modeling and simulation development. The RUBE project started in 2000 as

a continuation of the research in multimodeling and Web-based modeling and

simulation. To support multimodeling and Web-based modeling and simulation, RUBE

initially employed Virtual Reality Modeling Language (VRML) for the model

presentation and programming language. A special node of VRML, PROTO, was used to

add behaviors of objects using ECMAScript (commonly known as JavaScript) [1]. The

ROUTE function, which is provided by VRML, was used to connect the model behaviors

to the model objects. To provide more expandability, RUBE evolved to an XML

technology-based method. By the nature of XML, which supports separation of content

from representation, RUBE easily supports decoupling of model definition from model

presentation.

Up to this point, RUBE supports modeling and simulation of synchronous model

types, such as FBM (Functional Block Model) and FSM (Finite State Machine). By

adding the modeling and simulation frameworks for the queuing model to RUBE, RUBE

expands its application boundary to the asynchronous model types. Adding a new

modeling and simulation architecture to RUBE, while maintaining the current capability









of RUBE, is easily accomplished due to the fact that RUBE was based on the XML

technologies.

The primary motivation of this research is to expand the application area of RUBE

to the queuing model. The procedures to accomplish this goal are as follows. First,

extract the queuing model components and their characteristics to define model semantics

from their application fields. Second, based on the defined model semantics, find the

behavioral elements, which control themselves or other model components. Third, make

modeling and simulation frameworks. The most important thing while adding the new

framework is that the new framework should be compatible with RUBE.

1.2 Organization of This Thesis

In Chapter 1, we give the motivation behind the thesis. We discuss the background

knowledge of this thesis in Chapter 2. We introduce the related works in modeling and

simulation in Chapter 3. In Chapter 4, we give the detailed discussion of RUBEQM. In

Chapter 5, we provide descriptions of the RUBE_QM model topology and the design of

the model behavior. In Chapter 6, we discuss the modeling and simulation process in

RUBEQM. In Chapter 7, we offer our conclusions















CHAPTER 2
BACKGROUND KNOWLEDGE

2.1 Queuing Model (QM)

The queuing model is described as functional modeling using a function-based

approach. The functional modeling relies on the functional elements as the building

blocks upon which to construct a dynamic model [1]. Queue, Customer, and Server were

described as the main elements of the queuing model by Randolph W.Hall in the queuing

method [2]. The term Customer can refer to people or objects waiting for service, such as

parts, machines, and aircraft. Servers are bank tellers, machine operators, maintenance

mechanics or anyone else providing the service. Finally, Queue is a line of entities or a

group of people waiting to be served [3]. To define the queuing system, the timing of the

customer's arrival at the queue is defined as the arrival pattern. To define arrival patterns

(interarrival time at queue between customers) of customers on the queue, random

functions are usually used at the modeling and simulation. The server process defines the

time taken to serve customers, commonly referred to as the service time. The standard

notation for the queuing system is one involving a five-character code such as

A/B/C/D/E: A defines arrival patterns, which means the interarrival time distribution; B

defines the server process, which is the service-time distribution; C means the number of

parallel servers; D represents the system capacity; and E refers the size of population. For

example, the code M/M/1/oo/oo defines a single server (1) system with unlimited queue

capacity (oo) and the infinite queue size (oo). Interarrival times and service times are

exponentially distributed (M). Using this notation, several types of queuing systems can









be defined: M/M/1, M/G/1, M/D/1, M/M/1/M, and M/M/c. The characters, defining

service time and arrival pattern mean as follows: M indicates an exponential random

distribution, G refers the general distributions, and D indicates a constant service time

[4].

2.2 XML-based Technologies

2.2.1 eXtensible Markup Language (XML)

eXtensible Markup Language (XML) is a simple and flexible text format derived

from Standard Generalized Markup language (SGML), originally designed to meet the

challenges of large-scale electronic publishing. XML is playing an increasingly important

role in the exchange of a wide variety of data on the Web [5].

The main goal of XML is to build upon the flexibility of SGML without the

complexity and the presentation limitation of HyperText Markup Language (HTML).

While HTML mainly represents information, XML deals with the nature of the

information. This characteristic of XML allows users to manipulate the data in an XML

document for the representation, distribution, and so forth [6]. To facilitate flexibility and

transformability, XML provides a method to define its own tags and structure of

documents using an XML schema [7]. It also provides a way to convert one XML

document into a different XML document using an XSLT stylesheet [3]. The XML

features, as previously described, motivate many research groups and enterprises to use

XML as a tool or a software environment. RUBE uses XML as a core language to

facilitate the separation of data from its presentation and to support transformability for

modeling and simulation [6].









2.2.2 XML Schema

The XML schema is a structured definition for describing the structure of

information. The definition can be described as an arrangement of tags and text in a

document and applied to an entire class of documents in XML. The schema might also be

viewed as an agreement of on a common vocabulary for a particular application that

involves exchanging documents [7].

The structures of the XML document are described in terms of constraints in a

schema. The constraint defines what can appear in any given context. Two kinds of

constraints are used in a schema definition: content definition and data type constraints.

Content definition constraints describe the order and the sequence of elements while data

type constraints describe valid units of the data [8]. One of the purposes of the schema is

to allow the machine validation of a document structure. A valid document means that it

is suitable within the described definition of a class of documents. Any specific,

individual document, which does not violate any of the constraints of the definition, is

valid according to that schema. When applications are designed to send and receive much

information via the Web, the ability of testing the validity of a document is an important

aspect.

Also, the XML schema uses the XML elements and attributes to express the

semantics of it. It can be edited and processed with the same tools that users employ to

manipulate other XML documents.

2.2.3 eXtensible Stylesheet Language Transformation (XSLT)

eXtensible Stylesheet Language Transformations (XSLT) is a language which is

primarily designed for transforming one XML document and its structure into another

[9]. With XML, it is easy to create, read, and write to a document, but an intermediate









process is needed to convert one XML document into another type of document. To

convert an XML document to the required document or structure, XSLT takes two steps:

1) the data are converted from the structure of the incoming XML document into a

structure that reflects the desired structure; and 2) the new structure is used to generate an

output in the required format such as JavaScript or PDF [10]. XSLT allows the data to be

supplied to one of the new sources of applications that accept XML at the second step.

XSLT relies on the XML parser to convert the XML document into a tree structure in

which XSLT manipulates the document representation. XSLT translates an XML

document into another document based on template rules that describe how each element

must be processed for transformation. The rule for transformation expressed in XSLT is

called a stylesheet.

The principal role of an XSLT processor is to apply an XSLT stylesheet to an XML

source document and produce a result document with tree structure. The XSLT processor

handles three types of trees: the source tree, the stylesheet tree, and the result tree [10].

RUBE uses xalan as an XSLT processor to support the transformation [11].

RUBE employs the following XML-based technologies: 1) a schema to define the

model types in MXL (Multimodel eXchange Language), namely, MXL.xsd; and 2)

XSLT to define the model translation template rule, MXL2DXL.xsl and MFE.xsl. The

RUBEQM framework also maintains the RUBE methodology to be compatible with

other model types in RUBE and to support multimodel modeling and simulation. These

topics will be discussed in detail in Chapters 3 and 4.

2.3 RUBE

The contributions of RUBE are providing a customized modeling and simulation

tool and employing an XML-based specification for dynamic models [12]. The initial









RUBE used the VRML specific node and structure to facilitate dynamic multimodel

constructions and implementation within the 3D immersive environment. RUBE changed

the vehicle to XML to expand its application area. The architecture of RUBE is shown in

Figure 2-1.


Scene File SimPackJ/S Model File Scene File
(VRML) (JavaScript) (MXL) (SVG)

MXL2DXL
VRML2X3D
F DXL

DXL2J/S
X3D
I JavaScript


MFEfor3D MFE for 2D

X3D
User- Defined X3D2VRML
Translator
Intermediate
Final result

Figure 2-1. RUBE architecture

The modeling and simulation in RUBE consists two separate files: 1) a scene file,

which defines model representation in a 2D or 3D modeling language; and 2) model files,

which define the model semantics in Multimodel eXchange Language (MXL) [12, 13].

RUBE supports a 2D or 3D model representation. To create a scene file, users may

use a 2D or 3D representation language such as Virtual Reality Modeling Language

(VRML) or SVG (Scale Vector Graphic). VRML and SVC support the internal scripting

in JavaScript and Java so that the scene can be presented dynamically using script. RUBE

translates VRML into X3D by the translation step when the scene file is 3D geometry









language. When users define 2D scene file, the 2D scene file is moved directly into the

Model Fusion Engine for 2D geometry (MFE for 2D) and transformed into a dynamic

embedded 2D simulation model file. X3D is the XML version of VRML that describes

the 3D geometry [13]. MXL defines the model topology and the dynamics of the model

in the XML schema. Multimodeling in RUBE can be defined as a hierarchically

connected set of dynamic behavioral models where each model is a specific type. The set

of models are either homogeneous or heterogeneous [14]. In RUBE, when users define

model file(s) and a scene file, the model file is translated into a homogeneous block

diagram, namely, Dynamic eXchange Language (DXL) [12]. When the model file is

translated into DXL, RUBE uses an XSLT stylesheet that defines the transformation rules

of each model (MXL2DXL.xsl). DXL is the intermediate representation of model types

between the user-defined model file and the RUBE-created simulation model in

JavaScript. DXL is translated into a JavaScript simulation model using DXL.class in Java

programming language. Document Object Model (DOM) is employed to generate the

DXL.class file. JavaScript and the X3D or SVG file are fused with MFE.xsl to generate

the script containing X3D files [12].

RUBE allows users to create the scene file in VRML or SVG. To visualize the

X3D contents describing the 3D model geometry, RUBE uses a mechanism to convert

the X3D file into the VRML file, which can be viewed in most Web-based browsers. By

using the RUBE output, VRML scene objects can be controlled dynamically and

simulated when users makes a connection. Users can make a connection between the

model behavior JavaScript output and the model geometries using the VRML structure,

such as ROUTE and PROTO. The ROUTE is a specific structure of VRML and can be






9


described as a pipe which links the model behavior output with a model scene or between

model scenes [14].














CHAPTER 3
RELATED WORK

In this chapter, we discuss related topics in the queuing model modeling or XML-

based modeling and simulation development toolkits. The Tool for Object-oriented

Modeling And Simulation (TOMAS) is the process-oriented modeling and simulation

development software which contains the queuing model element. The AToM3 is a

simulation and modeling software to support meta-modeling and multi-transformation.

XML is used for transforming to other types of simulation languages. The Simulation

Reference Simulator is a simulation execution environment to perform the simulation in

SRML (Simulation Reference Markup Language). SRML uses XML to define simulation

and modeling at Boeing. JavaSim will be discussed in the final section.

3.1 TOMAS: Tool for Object-oriented Modeling And Simulation

TOMAS is presented as a software package specially developed for the discrete

event simulation of complex control problems in a logistics and a production

environment. The model in TOMAS is described by means of a process-oriented

approach and supports 3D animation in Delphi. The TOMAS provides TomasElements to

define simulation elements using Delphi, and specific elements can be defined as

descendents of a TomasElement. Each element contains implicit methods to control the

sequencing mechanism [15].

The TomasQueue is a basic class to represent a set of TomasElements for modeling

waiting lines, jobs in progress, and so forth. The TomasQueue automatically gather









statistics, such as the number in queue (minimum, mean, maximum) and waiting times

(mean, maximum) for the model [16].

RUBEQM is distinguished from TOMAS in terms of the methodology of

modeling and simulation. RUBE_QM separates model semantics from presentation, and

this gives the freedom to users to choose their own metaphor for the model. An aesthetic

aspect of modeling can also be integrated with the model creation. However, TOMAS

provides animation for verification and presentation with its own visual model.

3.2 A Meta-Modeling and Model-Transforming (AToM3)

The two main tasks of AToM3 are meta-modeling and model-transforming

proposed by Hans Vangheluwe and Juande Lara to support the distributed simulation and

modeling. Meta-modeling refers to the description, or modeling of different kinds of

formalisms used in modeling. Model-transforming refers to the (automatic) process of

converting, translating, or modifying a model given in certain formalism into another

model that might or might not be in the same formalism [17].

In AToM3, formalisms and models are described as graphs. Relationships between

model formalisms are described using Entities Relationship meta-model formalism (E-R).

Constraint conditions are inserted in the E-R when constraints are needed. AToM3

provides the graphical model definition and manipulation.

Model transformations are performed by graph rewriting, such as add Entities

Relationship or constraint conditions. Individual model definitions (even E-R and

constraints conditions) are saved and shared in the XML format while the transformation

is performed in AToM3 [18].

RUBE defines the relationship between models using model topology and XML-

based schema whereas in AToM3, the model E-R is defined in its own model formalism.










The main difference is that RUBE supports separation of presentation and model

definition whereas AToM3 supports distributed modeling and simulation even though

each of them also uses XML technology and supports multimodeling.

3.3 Simulation Reference Simulator

Simulation Reference Markup Language (SRML) is an XML application that can

describe the behavior for distributed simulation models. SRML uses XML and scripts to

define the structure and behavior of all items comprising a simulation, such as items

classes, event classes, scripts, and other elements for connecting and identifying

behavioral elements [19]. SRML can be executed in a Simulation Reference Simulator

(SR Simulator), which provides a runtime environment that includes the standardized

XML Document Object Model (DOM). The runtime environment provides the item and

event management, random number generation, mathematics and statistics, supporting

plug-in, and so forth. The runtime environment intrinsically uses the DOM in item

management and plug-in compilers for behavior.

Using the SR Simulator, a user can choose any host environment to create a

simulation object and use its interface, such as Microsoft Internet Explorer, Microsoft

Office applications, Microsoft Visual Basic, and Java [20].

SR Simulator supports defining model topology using its own tag. Users create a

simulation program to control each item using encapsulated simulation objects control

functions. SRML provides flexibility by allowing model developers to define their own

XML schema rather than being constrained to use a specific set of tag names. As with

SRML, RUBE gives the users the flexibility in defining models and the dynamics of the

model, and it provides an executable Web-based simulation program and environment.









3.4 JavaSim

L.B. Arief and N.A. Speirs proposed a UML tool for an automatic generation of

simulation programs. They developed a simulation framework called Simulation

Modeling Language (SimML) to bridge the transformation from the design to the

simulation programs. A UML tool that supports this framework has been constructed in

the Java programming language using the JFC/Swing package [21], namely, JavaSim

[22]. The simulation programs are generated in the Java programming language using

JavaSim. JavaSim framework uses XML-based DTD to store the information and

structure of the data. JavaSim also manipulates data using Java packages, such as the

Simple API for XML (SAX) through IBM's XML4J parser. In this framework, new

simulation objects and activities can be added to the components of SimML [23].

The JavaSim framework is constructed in UML, Java, and XML to use component

information while RUBE is constructed mainly in an XML-based environment. RUBE

supports dynamic visual modeling using the XML nature, which separates presentation

and information from data. RUBE supports separation of model representation and model

semantics, which gives the user the flexibility of model presentation.














CHAPTER 4
RUBE QM FRAMEWORKS

In this chapter, the RUBE queuing model (RUBE_QM) frameworks are discussed

in detail. In the first section, we introduce the description of RUBE_QM, and then we

will discuss The RUBE_QM modeling components and the overall structure of the

RUBE_QM frameworks in section 2 and 3, respectively.

4.1 RUBEQM Overview

RUBE is an XML-based multimodel modeling and simulation development toolkit

with a 2D or 3D visualization. RUBE supports multimodel modeling and simulation of

the Functional Block Model (FBM) and Finite State Machine (FSM) with Web-based

capability.

RUBE_QM adds the capability of modeling and simulation of the queuing model

to RUBE. By adding the modeling and simulation frameworks for queuing model to

RUBE, RUBE expands its application boundary to the asynchronous model types

The main development base of RUBE is XML. In RUBE, model representation

files and model semantic files are defined in XML. New model semantics can be added

with ease in the original RUBE model semantics. This comes from the XML document

handling mechanism, name correspondence, which allows RUBE to work with different

XML documents to copy and manipulate the corresponding elements from other XML

documents [6].

RUBE_QM also supports a Web-based modeling and simulation as RUBE. The

RUBE_QM structures can be divided into the model semantics and the representation as









in the original RUBE. The model semantics in the RUBE_QM architecture include

queuing model semantics with the semantics of FBM and FSM model types.

4.2 RUBE QM Model Elements

RUBEQM extends the application area to events that have various time intervals

and delays between event execution sequences. In order to support customized modeling

and simulation of the queuing model, we need to ascertain what kinds of elements are

needed to create the queuing model semantics. The general elements for the queuing

model are shown in Figure 4-1.

Element Usage Attribute

Generates a stream of arriving customers, jobs, or

entities.

A system resource that acts as a collection of a
queue and servers. It can contain one queue and
one server or more.
Data Structure for entities to wait until service is i

provided when demand for server exceeds the Size>
capacity of provided service.
A mechanism to provide services or processes to

the arriving entities.

Make a decision to send entities (job, customer)
positions using function for distribution.
Pick a single fork output using a cumulative
distribution generated from the probability attached
to each branch using random number generation.
Collect specific number of entities and pass an

entity or entities to the next step. This element can
be used as a synchronizing function.
Destroy event.
Figure 4-1. Model elements to define the queuing model semantics

I use the bank (computer system) for the example of the queuing model. When guests

enter the bank, The guests (entities) may enter the bank (system) without any information

(at random time interarrival) about how many customers are waiting for the service and









when the last guests (entities) entered in the bank. RUBEQM needs to provide a

function which generates interarrival time according to the user definition, which can be a

specific time or a time generated by a random number generation function. This function

can be defined using the source element. To define interarrival time between guests or

entities, the source element needs an attribute such as Interarrivaltime. The guest must

wait his turn to be served by the teller (server) at the designated waiting place or data

structure. The waiting place or data structure is defined as a queue and teller (server) as a

server. In some cases, the waiting line has an upper bound (finite queue size) to limit the

waiting line. In order to support this case, the Size attribute is added to the queue

element. Without any specific definition about the queue size, RUBEQM acknowledges

the queue size as infinite. To move into the server, the guest may need a service time

with/without any relationship with the previous guest or entity. In this case, the server

needs an attribute to define the service time function, which generates the service time as

user-defined. This attribute name is serviceTime.

The facility is a collection of one queue and server(s), which acts only as a

container of the queue and server(s). A facility has only one queue regardless of the

number of server(s). The guest (entity) may want to be re-serviced or to proceed to the

next service so RUBEQM needs an element to tell the guest (entity) where to move. We

define this action as the decision element.

The fork element can be used to move guests (entities) with the given probability. To

pick a single fork output, a random number generation function can be used which is

provided in SimPackJ/S [24].









In order to sort guests (entities) according to the entering sequence of the bank or

system, the join element can be used. The guests (entities) are sorted by the non-

decreasing order of the bank-entered time at join element. The sink element may be used

to destroy the node after the entire event has been accomplished. The node types

described earlier are defined using the XML schema with its required attributes. Figure 4-

2 shows the model topology of RUBE_QM.

mxl


models simulations
^ -----V A-------
handles functionalModels declarativeModels

output scripts bm sdm queuin fsmp-net

qmNode qmEdge


facility source decision fork loin sink trace

queue server

Figure 4-2. MXL topology of RUBE_QM

RUBE supports the modeling and simulation of FBM in the functional model

category and FSM in the declarative model category. The queuing model is in the

functional model category. With this model topology and attributes, the MXL schema

validates the user-defined model semantics. The RUBE QM framework is introduced in

the next chapter.


er.









4.3 RUBEQM Frameworks

4.3.1 Event Scheduling

Executing a system model sequentially by the time slicing method and event

scheduling method is used in the simulation field based on the von Neumann-style

architecture definition [24]. The time slicing method and the event scheduling method

use a global clock to control events. The main difference between the two methods is

how the events are executed using time. The time slicing method increases the given

amount of time to the global clock value. It executes the event that matches the event

time with the global clock time. In the event scheduling method, events are executed

when the event time is the minimum time on the future event list. Events in the event list

are sorted by the non-decreasing order of the system entering time and stored. The global

clock time is then set by that event time so the globe time is increased irregularly. The

time slicing method has the problem of encoding a delay between the model elements

[24]. RUBE_QM uses the event scheduling method for simulation because the

interarrival times are irregular

4.3.2 RUBEQM Frameworks

The RUBE_QM architecture has the same translation steps as RUBE. However,

certain steps perform additional works. The dynamic modeling and simulation in

RUBEQM is achieved by decoupling the model into two components: the model

representation (a scene file) and the model semantics (model files). The model

representation and the model semantics are defined using geometry modeling language

(VRML and SVG) and MXL model topology, respectively. We will discuss the model

representation file and MXL in detail in the next chapter.










The model file in RUBE_QM is an abstract description of a heterogeneous model

semantic. Figure 4-3 shows an example in which the user defines a model using a source

element, a facility element containing a queue and two servers, and a sink element. As

shown in Figure 4-3, the elements have different shapes and model definitions.

RUBEQM translates the model file into a homogenous block diagram file and

creates JavaScript using the model translator, MXL2DXL.xsl, written in XML XSLT.

Figure 4-3 shows the 2D presentation of the queuing model, and the corresponding DXL

model is shown in Figure 4-4.



facility s
server
(source queue sink
server


Figure 4-3. A 2D example of a queuing model file in MXL


Figure 4-4. A 2D example of a queuing model in DXL

DXL is a low level (assembly level) modeling language [12]. It represents a

multimodel containing more than one heterogeneous sub-model type within a

homogeneous block diagram [16]. When the queuing model files are translated into a

DXL level block diagram, RUBE_QM inserts block control behavior elements into the

DXL block diagram and creates JavaScript files. For example, RUBE_QM creates an

event generation JavaScript file, while the source element is translated into a DXL level









modeling language. To create an event generation JavaScript file, MXL2DXL.xsl uses a

random number generation function provided in SimPackJ/S [24]. The SimPackJ/S is a

library of simulation programs written in Java and JavaScript. When the facility element

is translated into a DXL level block diagram, RUBEQM creates a queue and server

element control JavaScript files user-defined at MXL model file. We will discuss how to

translate MXL to DXL in detail in the next chapter.

After the DXL level homogeneous block model is generated, RUBE_QM

translates this model file into an executable JavaScript file using Java DOM, DXL.class.

The DXL.class merges the user-created JavaScript file and the RUBE_QM-created

JavaScript files into a single JavaScript file. MFE integrates the scene file in X3D or

SVG with the RUBEQM-generated JavaScript code and produces a dynamic model file,

which contains the model dynamics in X3D or SVG. This RUBEQM MFE has an

identical functionality with the MFE in RUBE. In order to convert into a Web-based 3D

simulation and model file, RUBE QM uses file converters to transform X3D into

VRML. This file is provided as an open source. The Model Fusion Engine (MFE) in

RUBEQM will be discussed in detail in Chapter 6.














CHAPTER 5
MODELING IN RUBE QM

RUBEQM is a framework for modeling and simulation in a queuing model.

RUBE divides modeling into a representation file and a model semantic file. The

RUBE_QM maintains this main principle. In this chapter, modeling in RUBEQM is

discussed in detail.


5.1 MXL Model Structure

The model semantic file (model file) of the RUBEQM defines the model

structure and dynamics of the model. The model file is defined in Multimodel eXchange

Language (MXL) which is written in XML. Up to this point, RUBE MXL provides the

effective way in presenting model topology, the dynamic behaviors, and the simulating

information of the FBM (Function Block Model) and FSM (Finite State Machine). The

RUBEQM architecture provides model topology and the semantic of the queuing model

using XML while maintaining the support of FBM and FSM. RUBE_QM is XML-based

and it can easily extend its boundaries while maintaining its current support.

The main difference between FBM and FSM and the queuing model is that the

queuing model events may be processed asynchronously. Events in FBM and FSM are

processed without delay but the queuing model events may be stored and delayed for a

given amount of time. The model translation steps in RUBE_QM are made to provide

asynchronous and synchronous event simulation. Basically, the main structure of RUBE

MXL supports asynchronous event simulation.









Model files are defined using XML, so XML terms are used here to explain model

topology. The schema of MXL, which defines the model topology and semantics in

RUBEQM is provided in Appendix A. The topology of the model definition elements is

shown in 2D diagrams in Figure 5-1.

mxl


models simulations
^ -----V A-------
handles functionalModels declarativeModels

output scripts bm sdm queuing fsm p-net

qmNode amEdge


facility source decision fork join sink trace

queue server

Figure 5-1. Model topology in MXL

The type attribute of model elements defines the type of the model. The model

elements are represented by model node elements. The model edge elements describe the

connectivity between the node elements. Some node elements have script elements as

sub-elements. Script elements have an id attribute represented in the JavaScript file URI

containing the dynamic behaviors of the node or edge elements. The func attributes in the

Script element indicate the name of the function and contain the model dynamics in the

JavaScript file. The id attribute of the node elements refers to the unique name of the

element among all the MXL model files. The simulation element contains information

needed for simulating the model that is already defined. These model topology elements










can be defined recursively using the XML technology, which makes it possible to define

multimodel modeling and simulation.

For example, the queuing system, which consists of one CPU and four Disks, is

used from the Modeling and Simulation class (CAP 4800 or CAP 5805) textbook. Each

facility has one queue and one server.


Figure 5-2. 2D diagram of CPU Disk queuing model

The 2D queuing model diagram, which is composed of a source, a fork, a sink,

and five facility nodes, is shown in Figure 5-2. The identical representation of the MXL

definition for the queuing model file is given in Figure 5-3.