<%BANNER%>

Architecture for a Low-Level Functional Specification Language Supporting Multimodeling and Simulation

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

Material Information

Title: Architecture for a Low-Level Functional Specification Language Supporting Multimodeling and Simulation
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: UFE0011609:00001

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

Material Information

Title: Architecture for a Low-Level Functional Specification Language Supporting Multimodeling and Simulation
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: UFE0011609:00001


This item has the following downloads:


Full Text












ARCHITECTURE FOR A LOW-LEVEL FUNCTIONAL SPECIFICATION
LANGUAGE SUPPORTING MULTIMODELING AND SIMULATION















By

JINHO LEE


A DISSERTATION PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
DOCTOR OF PHILOSOPHY

UNIVERSITY OF FLORIDA


2005

































Copyright 2005

by

Jinho Lee

































To my parents, sister, and brother















ACKNOWLEDGMENTS

I would like to express my deepest gratitude to my advisor, Dr. Paul A. Fishwick,

who gave me inspiration and guidance throughout my Ph.D. studies at the University of

Florida. I would also like to give my sincere appreciation to my supervisory committee

members (Dr. Beverly Sanders, Dr. Abdelsalam A. Helal, Dr. Shigan Chen, and Dr.

Sherman Bai) for their precious time and advice.

I appreciate all the colleagues in our research group for sharing valuable ideas.

Special thanks go to Minho Park and Hyunju Shim for their help and companionship.

Also, I am grateful to the National Science Foundation and the Air Force Research

Laboratory for their financial support for my studies in the United States.

I owe great love to my parents, who prayed and encouraged me throughout my

studies; and to my brother and sister. They are the reason for my existence.

















TABLE OF CONTENTS


page

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

LIST OF FIGURES ......... ... .................. ................. ... .... ............. viii

ABSTRACT .............. .................. .......... .............. xi

CHAPTER

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

1.1 M motivations and Challenges ............................................................................1
1.2 Contributions to K now ledge ............... ..... ..... ....... ......... ............ .....................3
1.2.1. Web-Based Modeling and Simulation by Using XML to Represent
S im u lation M o d els ............. .................. .. ...... .... .. ............. .......... .. .. ...3
1.2.2 Multimodeling Using MXL, DXL, and an MXL-DXL Bridge....................4
1.2.3 Flexible Diagrammatic Presentation of Functionality for DXL Blocks.......6
1.2.4 Ports-based Modeling and Simulation Capable of Encoding Documents
Rather Than Data ............... ... .... .... .. ...... .............7
1.2.5 Explicit Support for Discrete Event and Continuous Simulation.................8

2 BACKGROUND .................................... ... .......... ............... 10

2.1 G general M ultim models ................... .. ...................... ........................................10
2.1.1 Intra-level Coupling and Inter-level of Multimodels ..............................10
2.1.2 Homogeneous and Heterogeneous Multimodels................... ..............11
2.2 The RUBE Fram ew ork ............................................................ ............... 13
2.3 SimPack Tools for the RUBE Framework ...................................... ............... 15
2.3.1 Event Scheduling M ethods................................ ................................. 16
2 .3 .2 R source A location ........................................................ ..................... 17
2.3.3 Sim ulation State and Tracing ........................................ ............... 17
2.3.4 Random Number Generators ....................................... ...............18

3 A LOW-LEVEL FUNCTIONAL SPECIFICATION LANGUAGE FOR
MULTIMODELING AND SIMULATION.......................................................19

3.1 The Concept of Dynamic eXchange Language (DXL)...........................19









3 .2 T h e Sy ntax of D X L ..............................................................................................2 0
3.2.1 The Visual Syntax of DXL ........................................................ ........... 20
3.2.2 The XM L Syntax of DXL ................................ .. ......................... 21
3.2.2.1 T he DX L E lem ent ........................................ ......... ............... 2 1
3.2.2.2 The block Elem ent ............................................. ............... 22
3.2.2.3 The port Elem ent...................................... ......................... 24
3.2.2.4 The definition Element .............. ...... ...............25
3.2.2.5 The connect Elem ent......................................... ............... 26
3.2.2.6 The simulation Element ................. ...... ......................... 27
3.3 The Sem antic of D X L ................................................. .............................. 28
3.3.1 The D XL N otation................................................................. ............... 28
3.3.2 The Information Stream Mechanism of DXL .........................................28
3.3.3 The XML-based Dataflow Semantic in DXL .........................................31
3.3.4 Synchronous and Asynchronous Input Semantic in DXL..........................33
3.3.4.1 Synchronous Input Property in DXL ............................................ 35
3.3.4.2 Asynchronous Input Property in DXL ..........................................37

4 M U L T IM O D E L IN G ............................................................................................ 38

4.1 Multimodeling through MXL and DXL....... ........................................38
4.2 M XL-to-DXL Translation ................................... ............... 39
4.2.1 Basic MXL-to-DXL Translation Example............................ ..................39
4.2.2 FBM-to-DXL Translation ................. ................................ 43
4.2.3 FSM -to-DXL Translation................................................. ............... 44
4.2.4 Petri Net-to-DXL Translation.................. ........................................... 45
4.3 M ultim odeling in D X L ................................................................................ .... 46
4.3.1 Multimodeling among Homogeneous Models in DXL..............................47
4.3.2 Multimodeling among Heterogeneous Models in DXL.............................50

5 SIMULATION CODE GENERATION ............... .............................................52

5.1 C concept of Sim ulation C ode.................................... ...................... ............... 52
5.1.1 The Structure of a DXL Block Class........................ .................52
5.1.2 The Structure of a DXL Block Class........... .................................53
5.2 MXL, DXL, AND SIMULATION Translation ................................................56
5.2.1 A MXL Multimodel for a Light Bulb Example .............. ..................... 56
5.2.2 A DXL Multimodel and Simulation for a Light Bulb Example.................58

6 C O N C L U SIO N ......... ...................................................................... .......... ......64

6.1 Sum m ary of R esults........................... ...................................................... 64
6.1.1 Web-based Modeling and Simulation by Using XML to Represent
Sim u lation M odels .................. ....6....... .... .............................. ........ .. .. ... 64
6.1.2 Multimodeling Using MXL, DXL, and an MXL-DXL bridge ..................65
6.1.3 Flexible Diagrammatic Presentation of Functionality for DXL Block......65
6.1.4 Ports-based Modeling and Simulation Capable of Encoding Documents
rath er th an D ata .............................................. ................. 6 5









6.1.5 Explicit Support for Discrete Event and Continuous Simulation .............66
6.2 Future R research ................................................. .................. .... ............. 66
6.2.1 Support of Different Model Types for Multimodeling..............................66
6.2.2 D distributed Sim ulation.......................................... ........... ............... 66

APPENDIX

SIM PA CK FO R PY TH O N .......................................................................... ............. 69

L IST O F R EFER EN C E S ........................................................................... ...............87

B IO G R A PH IC A L SK E TCH ..................................................................... ..................93
















LIST OF FIGURES

Figure p

2-1. General M ultim odel Structure...................................................................... 10

2-2. Homogeneous Refinement: declarative declarative...............................11

2-3. Homogeneous Refinement: functional functional ...............................12

2-4. Heterogeneous Refinement: functional declarative...............................12

2-5. Heterogeneous Refinement: declarative functional.............................. 13

2-6. The RUBE Fram work ............................................................................14

3-1. The V isual Syntax of D XL ........................................ ......... ............... 20

3-2. The Visual Syntax for a multimodel of DXL............................................ 21

3-3. The Schema of DXL Elem ent...................................................................... 22

3-4. The Schem a of B lock Elem ent..................................................................... 23

3-5. The Schem a of Port Elem ent................................... ...................... .. .......... 24

3-6. The Schem a of Definition Elem ent...................................... ............... 25

3-7. The Schema of Connect Element...... .................. ..............26

3-8. The Schem a of Simulation Elem ent..................................... ............... 27

3-9. Block N otation of D XL ...................................................................... 28

3-10. Diagrammatic Presentation of DXL.............. .............................................29

3-11 Model of DXL for Figure 4-2 Example.............. .... .......... ............... 30

3-12. Examples of SEND Pseudo Code .............. ........................................... 31

3-13. The XML-based Dataflow in DXL..........................................................32

3-14. Exam ple of Synchronous Inputs ....................................... ............... 33









3-15. Source of DXL for Figure 3-14..................... ....................34

3-16. Example of Asynchronous Inputs ............ ............................................ 35

3-17. Source of DXL for Figure 3-16............... ....... .................36

4-1. M ultimodel Structure of M XL ............................ .................................... 38

4-2. Heterogeneous and Homogeneous Models................... .......................... 39

4-3. Model of MXL as the Wrapper of the Four-Stroke Gasoline Engine.............40

4-4. Model of MXL for the Four-Stroke Gasoline Engine...............................41

4-5. Model of DXL for the Four-Stroke Gasoline Engine ...............................42

4-6. Translation an FBM into a DXL Model...............................43

4-7. Translation an FSM into a DXL Model ................... ......................... 44

4-8. Translation a Petri Net into a DXL Model.................... ......................46

4-9. Multimodeling between Functional Block Models in DXL .........................47

4-10. Multimodeling between FSA Models in DXL ............................................48

4-11. Multimodeling for an FBM Including an FSM in DXL ............................49

4-12. Multimodeling for an FSM Including an FBM in DXL ............................50

5-1. Structure of a DXL class in Python............... ....................52

5-2. Structure of a DXL class in JavaScript ...................................53

5-3. Event-based Sim ulation ............................................................................ 54

5-4. Structure of Simulation File............................ ....... ..................... 55

5-5. Model of FBM for a Light Bulb Example .................................... ................56

5-6. Model of FBM for a Light Bulb Example ........................... ............... 56

5-7. 2D Diagram for a Light Bulb Example................................ ............... 57

5-8. Light Bulb Example for MXL of an FBM..................... .....................57

5-9. Light Bulb Example for M XL of an FSM ................................. ...............58

5-10. Light Bulb Example for DXL FBM Model .................... ............... 58









5-12. Light Bulb Example for DXL FSM Model........................ .................60

5-13. Source of FBM Model in DXL and JavaScript................................. 61

5-14. Light Bulb Example for DXL M ultimodel ................................................ 62

5-15. Source of Multimodel in DXL and JavaScript............ .......................63

5-16. Partial R esult of Sim ulation ........................................ ....... ............... 63

6-1. Web Architecture and DXL Approach for Web-based Modeling and
S im u lation ...................................... .......................................... 6 7















Abstract of Dissertation Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Doctor of Philosophy

ARCHITECTURE FOR A LOW-LEVEL FUNCTIONAL SPECIFICATION
LANGUAGE SUPPORTING MULTIMODELING AND SIMULATION

By

Jinho Lee

August, 2005

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

Multimodels are models composed of heterogeneous dynamic system components.

Since most normal models like FSM and FBM represent only a part of the overall system

behavior, they make only a subset of solution for analyzing the prediction and diagnosis

of our real world. Multimodels can, on the other hand, give abstraction perspectives for a

complex real-world system. There is a need for a unified, low-level functional

specification language (and associated diagrammatic presentation) for simulations that

may be expressed in a wide variety of modeling visualizations and formalisms.

Our objective was to design a low-level functional specification language, with a

circuit-like appearance and functionality, to more efficiently support eXtensible Markup

Language (XML)-based multimodeling and simulation. For the multimodeling and

simulation, there are three stages in our approach.

For the first stage, we have defined traditional heterogeneous models using the

Multimodeling eXchange Language (MXL). These models are transformed into a low-









level functional specification language through eXtensible Stylesheet Language

Transformation (XSLT) translator.

For the second stage, we have designed a low-level functional specification

language and its diagrammatic presentation for multimodeling and simulation, the

Dynamic eXchange Language (DXL). DXL is an XML-based language that positions

itself between higher-level modeling languages and a programming code

For the last stage, by using the XML Document Object Model (DOM), we

demonstrate a translation approach that yields a target code for simulation such as

JavaScript and Python. Through these three stages, we have developed the multimodeling

methodology through the low-level functional language and its translation from MXL to

simulation codes.














CHAPTER 1
INTRODUCTION

1.1 Motivations and Challenges

Computer modeling and simulation fields have been applied to analyze and expect

a variety of complex real-world problems, spreading over academia, the military, and

industry. They have tried to satisfy all the requirements of modeling and simulation from

the representation to the execution procedure to reasonably simulate and analyze a

complex system. But, the complexity of a real-world system has made it difficult to

develop a methodology for the specification and analysis of the system. Most of the

researchers have specified and analyzed the system having only a simplified and different

viewpoint [28, 34, 68].

On the other hand, Web-based modeling and simulation [22, 48, 49] is one of many

paradigms for the modeling and simulation. Many problems must be solved for the

paradigm to prosper. An XML [6] -based modeling and simulation methodology can

satisfy requirements of the Web-based modeling and simulation as well as the traditional

modeling and simulation.

Therefore, a unified XML-based methodology is need to support all the properties

of those modeling methodologies and simulation techniques to specify and analyze the

real-world system. An objective was to design a unified, functional specification

language and associated diagrammatic presentation to allow simulations to be expressed

in a wide variety of modeling visualizations and formalisms.









Among many existing methodologies, an XML-based functional block diagram

methodology might play an important role in accelerating the growth of the fields and

satisfying the above requirements. Our two main approaches were the decomposition and

the integration of existing modeling methodologies based on an XML-based functional

block methodology. We designed a unified low-level functional specification language

based on XML for this purpose.

Decomposition has two steps: defines its atomized elements to specify a model and

its behaviors using XML. translate each heterogeneous traditional model into

homogeneous models consisting of the atomized elements.

Generally, because it is easier to integrate homogeneous components than

heterogeneous components of models, sub-models of heterogeneous components are

integrated after they are translated into sub-models of homogeneous components. Uniting

the notations also helps to reuse model components.

This flexibility and reusability led to creation of two XML-based languages for the

RUBE framework. The low-level functional specification language we used is called the

DXL [37, 38]; and it includes a higher-level dynamic model wrapper language, the MXL

[31, 32, 33].

MXL is an XML-based modeling language to support traditional heterogeneous

model types such as Finite State Model (FSM), Functional Block Model (FBM), or Petri

net [24, 25, 26, 30, 31]. DXL is an XML-based simple functional block language to

support actual simulated execution on the RUBE framework.









The independence between traditional abstract model types and the contemporary

actual simulation programs makes it easy to provide model composability and reusability,

which are key characteristics for multimodeling.

1.2 Contributions to Knowledge

1.2.1. Web-Based Modeling and Simulation by Using XML to Represent Simulation
Models

Web-based modeling and simulation have many advantages. Models can be

reviewed with clients on the Internet during model development. Developers can make

changes to a model on the Internet without traveling to a client site. The model can access

actual model files and data files from any location in the client network [20, 65].

Both MXL and DXL use XML to support model composability and reusability for

Web-based modeling and simulation. Heterogeneous traditional models use MXL, and

homogeneous primitive models use DXL. Each XML-based model might include its own

type of zero or more XML-based models as well as its own atomic XML elements. The

MXL might support heterogeneous multimodeling and DXL might support homogeneous

multimodeling through the hierarchy of the models. Because both languages use XML, it

is easy to transform a heterogeneous model into a homogeneous model using XSLT.

Simulation Reference Markup Language (SRML) [57] is an XML-based modeling

and simulation language for a discrete event simulation. SRML is an XML application

that can describe the behavior of distributed simulation models, and its runtime

environment is software capable of executing those models based on script codes defined

in its documents. It defines specific simulation, item, and script elements and their

attributes, to support a centralized discrete event simulation. But SRML is a language for









a traditional discrete event simulation. So, it has some limitations to represent the

multimodels providing synthetically a variety of viewpoints for a system.

Extensible Modeling and Simulation Framework (XMSF) [8, 9] is a composable

set of standards, profiles, and recommended practices for Web-based modeling and

simulation. It integrates XML, Internet technologies, and Web Services for supporting its

modeling and simulation framework. Its members work for three representative fields

which are Web and XML technologies, Internet and networking, and modeling and

simulation fields. Their research focuses on Web-based Distributed Interactive

Simulation (DIS).

The Simulation Modeling Language (SML) is an open source, web-based, and

multi-language simulation project guided by a consortium of industrial, academic, and

government simulation consultants and developers [29]. The objective of SML is to

produce reusable simulation software at both the simulation source code and modeling

source-code levels. The properties of SML are readability, modularity, and extendibility

and it supports Java-based, any object-oriented language using design patterns like the

common object-oriented, process-oriented modeling design pattern or the entity-object-

thread design pattern.

1.2.2 Multimodeling Using MXL, DXL, and an MXL-DXL Bridge

Our approach supports multimodeling using an MXL-DXL bridge where

heterogeneous multimodels are specified with MXL and then translated into

homogeneous multimodels using a low-level functional specification language for

multimodeling and simulation (DXL). Multimodeling is an extension of the more

traditional combined modeling techniques [47, 65] which normally combine discrete

event and continuous model formalisms in the same model. We approached









multimodeling transforming heterogeneous models into homogeneous models, and

approached functional composition with coupled ports of the same data type.

The approach to multimodeling and simulation is interleaving design and

simulation. The design process consists of decomposition and composition. High-level

functions are hierarchically decomposed into functions for subsystems like intra-level

coupling of multimodeling. These subfunctions are then mapped to physical components

[50, 62, 63]. During composition, interactions among components are defined. These are

similar to inter-level coupling of multimodeling.

Ptolemyll [10, 41] provides heterogeneous, concurrent modeling and design for an

embedded system using MoML, which is an internal language for Ptolemyll. MoML [36]

is an XML-based functional block modeling language and supports multimodeling for

Ptolemyll. This project focuses on inter-level coupling of heterogeneous and

homogeneous models like MXL in the RUBE framework [30, 31, 32, 33]. But they try to

compose heterogeneous models directly to support multimodeling unlike our MXL-DXL

bridge. DXL supports a multimodeling methodology [20, 46, 72] using simple

homogeneous blocks, unlike the more complex blocks of MoML.

There are many object-oriented languages for discrete event systems [71, 72] and

continuous systems [2, 16, 17, 23, 55]. An object-oriented model derived from a parent

model inherits the parent's interface and equations. The child model can be extended by

including additional interactions through the interface and implementation of additional

equations [16, 17, 55, 71]. Designing an object-oriented model produces a hierarchical

organization of models, and supports reuse and extension of simulation models.









1.2.3 Flexible Diagrammatic Presentation of Functionality for DXL Blocks

In DXL, models are specified by connecting inputs and outputs of primitive models

such as multipliers or adders. Each block can be encoded in either JavaScript or Python.

Multiple programming languages such as JavaScript and Python [7] become target codes

for DXL-to-Simulation translators and an actual data flow for simulation is achieved if

we use XML data and schema. DXL supports the combination of lower-level models of

subsystems for complex systems hierarchically, which translates to homogeneous

multimodeling.

We created a visual formalism for DXL and MXL that operates like a digital

circuit. The circuits are fairly flexible, allowing for the three specified modes of

operation: sequential, distributed, and hardware. While most work has supported

sequential operation, distributed and hardware modes are forthcoming. For sequential

simulation, the simulation models described by DXL are translated into programming

languages (such as Java, JavaScript, and Python). This DXL-to-Simulation translation

approach supports information streaming that operates according to the different modes.

For example, message passing can result in future-event list scheduling (for sequential

architectures), actual messages (distributed network), or communications busses

(hardware). Distributed simulation mode might be based on XML-based message passing

protocol, Simple Object Access Protocol (SOAP).

Bond graph modeling [54, 60] defines a system in terms of a group of elements

with bonds connecting each element to the rest of the network, and is based on energy-

conserving junctions that connect energy storing or transforming elements through bonds.

Even though the domains, such as mechanical, electrical, and thermal, are different, each

domain has an analogous component in every other domain such as power and energy.









But, bond graphs are inconvenient for the 3D mechanics [67] modeling or continuous-

discrete hybrid systems [14, 18].

Linear graphs represent the energy flow through the system component expressed

using terminal variables like Kirchhoff s voltage and current laws. An edge shows an

energy flow in a system using an equation expressing relations between terminal

variables, and the terminals of components are the nodes of the graph. Linear graphs are

more convenient for the 3D mechanics [3, 43] or hybrid systems [45] because of their

domain independence and direct representation of the system topology.

Architecture Description Languages (ADLs) [13, 35, 44] are modeling notations

for architecture-based development of computer software. Many ADLs for specific

domain and general purpose in the software engineering field have been proposed.

Though their main focus is an architecture-based design methodology of software, they

use similar terminologies as DXL components and generate actual programming code.

But most of the ADLs are not XML-based except for a few languages [13]. The XML-

based ADL provides a mechanism for rapidly developing new ADLs and the reusability

of software components like DXL provides a mechanism for developing and reusing

actual simulation codes to analyze a system. ACME [35], which is called an interchange

language, supports integration of different ADLs and proposes a formal semantic to

facilitate architecture connection [1].

1.2.4 Ports-based Modeling and Simulation Capable of Encoding Documents Rather
Than Data

Ports constitute the interface that defines the boundary of components or sub-

systems in a system configuration. MXL and DXL ports are used for port coupling,

where all ports match in number and data type. MXL ports are ports for conceptual









multimodeling in rube framework and DXL ports maintain the conceptual multimodeling

and support the multimodel execution. Because of the XML-based environment, DXL

ports are capable of encoding documents rather than data, or more specifically XML

documents. Thus, a DXL or MXL model supports XML "information streaming" and not

only streaming of simple data types. The "types" are accompanied by XML schemata that

define the typing structure.

Physical-based modeling and simulation researchers adopt port-based modeling

and simulation [16, 17, 39, 42, 66]. They use the ports as an interface for components.

Their ports express relations like an energy flow between physical objects like

mathematical equations. Port-based product models can be used to generate multiple

simulation models at different levels of abstraction. Mechatronics or complex hybrid

systems could use port-based modeling and simulation efficiently.

1.2.5 Explicit Support for Discrete Event and Continuous Simulation

For high-fidelity simulation of multidisciplinary systems, hybrid modeling and

simulation is required to support a combination of continuous time physical behavior and

events occurring at discrete time and space. Because mechatronic systems combine both

continuous time phenomena and discrete time events, they require mixed continuous-

discrete models [4, 24, 72]. DXL explicitly supports simulation in terms of the

development of commonly used simulation blocks found in both discrete-event and

continuous simulation.

Modelica [16, 17, 42, 66] is an object-oriented modeling language using the

approach for complex and heterogeneous physical systems. It has been developed

primarily by the continuous systems community. Modelica provides a 2D-based design in

a high-level abstraction, as well as a detailed model execution by using equations for









specifying interrelation of components for the physical system. Modelica has the

advantage that is object-oriented with support for model inheritance and sub-typing. It

also supports the definition of aggregate connections and signal variables from different

energy domains can be combined. It is possible to reuse many physical-based

components and simulation analysis tools. But this approach has some limitations to

represent a general model using different model types, since it is based on a physical

system.

Very High-Speed Integrated Circuit Hardware Description Language-Analog and

Mixed-Signal (VHDL-AMS) is an extension from VHDL to support Analog and Mixed-

Signal components. VHDL-AMS has more modeling primitives for discrete-event

simulation than continuous time simulation. VHDL is limited to encapsulation but has

been standardized by IEEE.

















CHAPTER 2
BACKGROUND

2.1 General Multimodels

2.1.1 Intra-level Coupling and Inter-level of Multimodels

Multimodels are models that are composed of heterogeneous models. Since most

normal models like FSM and FBM represent only a part of the overall system behavior,

they make only a subset of a solution for analyzing the prediction and diagnosis of our

real world. Multimodels can, on the other hand, get a number of abstraction perspectives

for a complex real-world system. Therefore, they can more correctly represent and

analyze a complex real-world system. Different component models in a multimodel can

define the activity at different stages of the simulation.


Level 1 M1

Refinement
.................................................... ... ............................. ....... .......................... ....

Level 2 mi : m = m2 *==* Abstraction
SConnection

Level--------------- -- -- ------- -------
Level 3 = 3

.....................................................................................................................................................I

Figure 2-1. General Multimodel Structure

Figure 2-1 shows a multimodel example having an abstraction hierarchy of

heterogeneous models. Double dotted lines in this figure mean the relation of its

components to compose an upper level model. This relation should ensure intra-level

coupling. Intra-level coupling defines model components coupled to one another in the









same model. In Figure 2-1, there are two intra-level couplings. M2 is composed of ml,

m2, and m3. M3 is composed of sl, S2, and s3. The intra-level coupling in M2 defines how

the sub-models of M2 are formed to represent a model M2 and the intra-level coupling in

M3 defines how the sub-models of M3 are formed to represent a model M3.

p l(i)





P2(i)





Figure 2-2. Homogeneous Refinement: declarative declarative

In Figure 2-1, down-arrows mean refining a model and up-arrows mean the

abstraction of a model. These two relations should ensure inter-level coupling. Inter-level

coupling defines rules as to how model components from one model can be refined into

models of different types. In Figure 2-11, there are two inter-level couplings. M2 refines a

model M1 and M3 refines m2. A model m2 abstracts M3 and M1 abstracts M2. To refine m2

into M3, we should ensure the intra-level coupling in M2 when we change the sub-model

m2 and M3.

2.1.2 Homogeneous and Heterogeneous Multimodels

In Figure 2-2, the Finite State Automata (FSA) shows top-down homogeneous

decompositions which means intra-level coupling because the element of the upper

model is defined by the same type of models. State s, is decomposed into the lower level

of FSA. The predicates p(i) andp2(i) involves external input variable i such as i=0.










f o =(il, i2)
i2



iiii 0

f3 O =f3(f(il),f2( i2))

i2 f2


Figure 2-3. Homogeneous Refinement: functional functional

Figure 2-3 shows a two-level functional hierarchy where functionfis defined in

terms of a composition of three other functionsf,f2, andf3.



f
p(i)
1 0






Figure 2-4. Heterogeneous Refinement: functional declarative

Heterogeneous decomposition of models in intra-level coupling describes the

semantics of a model using different models semantics. The model of Figure 2-4 shows

FSA that defines the internal state transitions associated with function The predicate

p(i) tests input variable i. All FSAs should have this kind of functional box around them

to represent explicit external input and output semantics even though the functional box

is not always explicit in the FSA graphical representation.

Figure 2-5 shows a state-to-state space mapping, which is not immediately apparent

from the figure. Specifically, most functional block models that represent some aspect of









physical reality involve state transitions which meansfi andf2 contain internal state

transitions. There is a transition with two possible types of semantics coming out of state

s in Figure 2-5. An external transition would be of the form p2(i) and an internal

transition would be based on a variable o that is a component of internal state space offi

andf2.




P2(i)

fi f2................ ..................
P2(0) "'""






Figure 2-5. Heterogeneous Refinement: declarative functional

2.2 The RUBE Framework

The RUBE framework is an XML-based dynamic modeling and simulation

framework permitting the users to specify and execute a dynamic model, with an ability

to customize a model presentation using 2D or 3D visualization [11, 12, 26, 40, 52, 61].

The purpose of RUBE is to facilitate a dynamic multimodel construction based on XML,

and visualize and execute the model within a 2D environment [52] or a 3D immersive

environment [53]. The overall process of the XML-based RUBE framework is shown in

Figure 2-6.

In Figure 2-6, the entire process of the RUBE framework is described by starting

independently two flows of methodologies which are model representation and model









creation, and then merging the flows and creating final model visualization and execution

codes.


2D interface Sccene file ine RUB3 2D m 3D
F (Sodipodi) 2-6 Te- RUBE dynamic
(So od i i)I modeling file
3D interface MXL fe Simulation file
(Blender)ation th Ds

... .. "- D- Simulation file
SMX oDXL n DXLtoJavascript
MXL file transla or using DXL file translator using imulation c
X, LT D DOM t

SimPackJ/S



Figure 2-6. The RUBE Framework

For model representation, a dynamic model is a scene file, which contains 2D or

3D geometry objects. The RUBE framework has a 2D or a 3D interface using Sodipodi

[64] and Blender [5, 58, 59] for each representation of the 2D or the 3D model scenes.

The scene files just represent the appearance of geometric objects in the model and do not

have any information about model behavior or dynamics. The scene files can be either

standard 2D or 3D XML documents which are specified by Scalar Vector Graphics

(SVG) [15] or eXtensible 3D (X3D) [69] respectively. Therefore, any 2D or 3D tools

which can generate SVG or X3D files might be applied as a part of the RUBE framework.

For model creation, there are two stages: model translation and model simulation.

For model translation, a dynamic model is an actual model file which is represented by

MXL. The MXL file describes the behavior of the model and represents the model file

that includes the specification of a heterogeneous multimodel in an abstract level such as

FBM (Functional Block Model) and FSM (Finite State Machine). The MXL-to-DXL

translator using eXtensible Stylesheet Language Transformation (XSLT) [27] translates a









model file written in MXL into a low-level functional specification language called DXL,

which can be described with a homogeneous block diagrammatic presentation. For model

simulation, the DXL is translated into an executable programming code for the model

simulation using the DXL-to-Simulation translator. The programming code can be

executed using SimpackJ/S or Simpack Python [19, 51], which provides the underlying

code foundation for libraries, classes, and objects for simulation.

For model merging, a 2D or a 3D merge engine, which are created with XSLT,

merges two XML documents: a scene file and the actual model execution file. And then,

the engine generates the final RUBE visualization and execution file of the model. The

file might visualize and execute the model within a 2D environment, Sodipodi, or a 3D

immersive environment, Blender. The current RUBE framework also supports integrative

multimodeing providing a human-computer interaction environment that allows

components of different model types to be linked to one another [53].

The red line rectangle in Figure 2-6 shows my contributions in the RUBE

Framework. They are the design of the output DXL of the MXL-to-DXL translator, the

design of DXL, DXL-to-Simulation translator, and the final simulation code.

2.3 SimPack Tools for the RUBE Framework

SimPack is a software toolkit for event scheduling and queuing model simulations.

It is a collection of multiple programming languages tools for computer simulation such

as C, C++, Java, JavaScript, and Python. The RUBE framework especially uses Java,

JavaScript, and Python to support Web-based modeling visualization and simulation as

well as traditional programming language simulation. The generated simulation codes in

the RUBE framework reference SimPack as basic simulation APIs. SimPack provides

four sorts of methods according to the functionality.









2.3.1 Event Scheduling Methods

Five methods are used to provide a means to simulate basic models involving event

scheduling by dealing with managing the future event list (FEL).

* Sim. init: This method initializes the discrete event simulation, and it is therefore
mandatory to call it at the top of the code.

* Sim. schedule: This method schedules an event to occur in the future. This inserts
the event within the future FEL according to increasing time for each event. The FEL
is ordered on simulation time at which the future event will occur, so no matter in
what order events are scheduled, or put into the FEL, they come out of the FEL in
ascending order of their occurrence times. In other words, events with smaller times
are placed toward the head of the list since they will be processed first. Events with
the same occurrence time are scheduled FIFO. In the FEL, the time associated with
each event is converted to and stored as a simulation time which is the elapsed time
since the start of the simulation, measured in arbitrary time units. The FEL times are
absolute virtual times when events are to occur in the simulation. FEL items are each
composed of 1) time for the event to occur, 2) the event to occur, 3) the token (which
stores attribute data and information for this event), and 4) the priority of this token.
Higher priority tokens get scheduled before lower priority ones in the FEL.

* Sim. next event: This method causes the occurrence of whatever future event
has the minimum occurrence time, taking this event as the next event from the FEL.
Whereas Sim. schedule inserts items into the FEL, Sim.next event removes
the item in the head of the list. Within the same priority level, this means the smallest
time value for a token. The order of activities for this function is: to check to see if
(1) the list is empty, or (2) whether the synchronization with the physical clock and
the virtual time is likely to be less than the physical time. If either of these conditions
is true, this function returns a value of"-l". Otherwise, it returns the event (an
integer value). If an event is to be returned (i.e., not "-1"), the virtual clock time is set
to the time of the event which has been removed from the head of the FEL.

* Sim. cancel event: This method removes the first item from the FEL with an
item specified by the event. If this method is successful in finding this event then 1)
the event is removed from the FEL, and 2) the corresponding token number is
returned. On the other hand, if there is no such item in the FEL, the FEL remains
unchanged.

* Sim. cancel token: This method cancels the first item from the FEL with an
item specified by the token identifier. If this method finds this token then 1) the event
is removed from the FEL, and 2) the corresponding event identifier is returned. On
the other hand, if the token cannot be found then the FEL is unchanged. The token is
identified only by its first attribute attr [ 0 ] item.









2.3.2 Resource Allocation

There are four resource allocation methods that deal with queuing for a resource or

server

* Sim. create facility: This method creates a new facility or resource, which
will develop a service queue behind it. A facility is a shared resource consisting of
service and queues where tokens vie for service. For example, a facility can be a row
of cashiers, a door (for entering and exiting a room), or a machine that accepts raw
parts for processing. The service could be check-in at an airport ticket counter. The
queue could be the line in which passengers stand and wait until the service is
available at the counter. A facility is a container, or collection, of servers (greater
than or equal to 1). If there is one server, the entire facility creates a "single server
queue", otherwise, there are multiple server queues where one facility has more than
one server. A queue is composed of tokens, with only one queue per facility.

* Sim. request: This method requests service from a facility. In other words, this is
the mechanism by which an incoming token requests a server in the facility. The
return value of this method is FREE or BUSY. FREE means that the facility had an
available server for this token and the token has now started receiving service from
the facility. BUSY means that the facility had no available server for this token, and
the token has been put into the facility's priority queue to await availability of a
server.

* Sim. preempt: This method preempts the server which means a facility. An
incoming token requests a facility, and will usually preempt (or replace) the token
already being serviced. The difference between preemption and a request is that with
preemption, a token does not normally wait in the queue at all which means it
bypasses the queue completely to obtain immediate service. The mechanisms are as
follows. If the incoming token's priority is lower than or equal to all tokens currently
being served in the facility then that token will be queued. But, if the incoming
token's priority is higher, the server token will be preempted and placed back at the
head of the facility queue, time-tagged with its remaining time for service.

* Sim. release: This method releases the server for the next token waiting in the
queue. This is generally performed after a token has obtained service. That token
then releases the facility to the next waiting token at the head of the queue. This is
done by automatically scheduling the token on the head of the queue if there is any.
The automatic scheduling uses Delta time = 0.0 and the type of event that was used
by the token that made the facility request (i.e., prior to having to wait).

2.3.3 Simulation State and Tracing

There is one method used to get state of FEL and facilities, or print their contents.









* Sim. state: This method gets the simulation state at any point in time (i.e.,
wherever this method is invoked in the code).

2.3.4 Random Number Generators

There are five methods generating random numbers for different probability density

functions

* Sim. random : This method is a uniform random number generator.

* Sim. uniform: This method is a uniform random number generator for double
floating point.

* Sim. normal: This method is a normal random number generator for a distribution
with mean x and standard deviations

* Sim. expntl: This method is an exponential random number generator with mean
x.

* Sim. erlang: This method is an erlang random number generator for a distribution
with mean x and standard deviations














CHAPTER 3
A LOW-LEVEL FUNCTIONAL SPECIFICATION LANGUAGE FOR
MULTIMODELING AND SIMULATION

3.1 The Concept of Dynamic eXchange Language (DXL)

DXL is a unified, low-level functional specification language, and associated

diagrammatic presentation, for simulation on the RUBE framework [26, 37, 38]. In

simple DXL models, models are specified by connecting inputs and outputs of primitive

models such as multipliers or adders.

In multimodels, the models might be abstracted upper-layer block as sub-layer

models. DXL supports the combination of lower-level models of subsystems for complex

systems hierarchically which means homogeneous multimodeling. Because all DXL

models have its outermost block as a wrapper, the important characteristics for

multimodeling, composability, and reusability can be supported clearly.

When each block plays a role as a leaf node in the structure of a multimodel, it can

be encoded in one of the programming languages such as JavaScript or Python. Multiple

programming languages become the target codes for DXL-to-Simulation translators and

an actual data flow for simulation is achieved if we use XML data and schema.

In this chapter, a diagrammatic presentation and formalism for DXL, which

operates like a circuit, is created. Ports constitute the interface that defines the boundary

of components or sub-systems in a system configuration. MXL and DXL ports are used

for port coupling, where all ports match in number and data type. MXL ports are for

conceptual multimodeling in rube framework and DXL ports are there to maintain the










conceptual multimodeling and support the multimodel execution. Because of XML-based

environment, DXL ports are capable of encoding documents rather than data, or more

specifically XML documents. Thus, a DXL or MXL model supports XML "information

streaming" and not only streaming of simple data types. The "types" are accompanied by

XML schemata that define the typing structure.

3.2 The Syntax of DXL

3.2.1 The Visual Syntax of DXL

The right part of Figure 3.1 shows visual syntax elements of DXL. DXL elements

are blocks, input and output ports, and connects. Generally, a DXL model is composed of

"block" elements and "connect" elements. A DXL block element is composed of

"port" elements and "its actual computation codes". DXL block elements are

connected by each connect element through input and output port elements. Input

and output port elements can be included in a block element and each port element

is connected to the corresponding output and input port element of other block

elements for its data flow, which each connect element controls.



Block
Output Input
Block port port Block
1 2 Input port

Output port

Connect


Figure 3-1. The Visual Syntax of DXL

The left part of Figure 3.1 shows a simple DXL model consisting of two blocks and

one connect. The meaning of this model is that after the computation of "Block 1" is










finished, the output becomes the input of "Block 2". Therefore, "Block 2" can execute its

own computation using the output of "Block 1" as its input.



Outer Block B
Block A Block C
B.IP a.IP b. IP B.OP

A.OP a.OP b.OP C.IP
Inner Block a Inner Block b



Figure 3-2. The Visual Syntax for a multimodel of DXL

DXL block element might include another DXL model when it represents a

homogeneous multimodel. In Figure 3-2, "Outer Block B" doesn't have "its actual

computation codes" but another DXL model. Therefore, when "Outer Block B" starts, the

input of "Outer Block B" becomes the input of "Inner Block a". On the other hand, when

"Outer Block B" finished, the output of "Inner Block b" becomes the output of "Outer

Block B". According to the flow of "connect" elements, after the inner blocks of "Outer

Block B" are executed, the output of "Outer Block B" becomes the input of the "Block

C" in Figure 3-2.

3.2.2 The XML Syntax of DXL

3.2.2.1 The DXL Element

The DXL element is the root of a multimodeling and simulation. Each DXL

element is an individual model definition in a DXL file. The FBM and FSM in MXL are

translated into each homogeneous block model of DXL. It contains block and

connect elements as children.













































Figure 3-3. The Schema of DXL Element

3.2.2.2 The block Element

The block elements are basic components for a model execution. In other words,

these block elements become not only schematic elements of a DXL element but also

basic units of actual simulation codes used in an event-based scheduling. The block

element contains port, block, and definition elements as children elements.






































Figure 3-4. The Schema of Block Element

id attribute: The id attribute specifies the name of the block element.
The value of id attribute generated by MXL-to-DXL translator has the
meaning of a hierarchical structure because the name of the blocks in the
higher layer in a multimodel are included.

type attribute: The type attribute specifies the input property of the
block element. DXL blocks support two sorts of properties for input,
synchronous and asynchronous.

delta attribute: The delta attribute specifies the delta time which
means a delay time for the block. If the value of delta attribute is greater
than 0, its output is transferred to its next blocks after the delaying time passes.

internal attribute: The internal attribute specifies the block
generated by MXL-to-DXL translator for the special purpose. For example, we
need the special blocks, INPUT and OUTPUT DXL blocks, for the declarative
model such as FSM.










3.2.2.3 The port Element


















ional" />
ional />


="data_type" type="xsd:string" use="required" />
="initial" type="TypeName" use="optional" />


Figure 3-5. The Schema of Port Element

An element port is included in a block or connect element that is a direct

component of a DXL element. It has four attributes such as id, type, source, and target

attributes.

id attribute: The id attribute specifies the name of the port element.
The value of id attribute generated by MXL-to-DXL translator has the
meaning of a hierarchical structure because the name of the blocks in the
higher layer in a multimodel are included.

type attribute: The type attribute specifies the type of data value used
in the port element. Objects as well as primitive data types are supported
because of the characteristics of script and object-oriented programming
language. If simulation codes generated by a DXL model use the APIs creating
XML documents into programming objects, XML documents can be










considered as the same objects as other programming objects in this DXL
model.

source attribute: The source attribute specifies the attribute id of the
output port element that transfer data to current port element. In a single
layer DXL model, the value of the source attribute is the attribute id of the
output port element of other block elements, but it can be the attribute id
of the input port element of its own outer block element in a DXL
multimodel.

target attribute: The target attribute specifies the attribute id of the
input port element to which current port element transfer data. In a single
layer DXL model, the value of the target attribute is the attribute id of the
input port element of other block elements, but it can be the attribute id of
the output port element of its own outer block element in a DXL
multimodel.

initial attribute: The initial attribute specifies the initial value of
the port element.

3.2.2.4 The definition Element






















Figure 3-6. The Schema of Definition Element

The definition element defines the behavior for its own outer block element

corresponding to the enclosing element. In a definition element, the actual program










codes for the simulation of the corresponding block element are located using their file

name. Each code is composed of functions. A called function is referenced by an attribute

func.

id attribute: The id attribute specifies the file name of a document that
provides the script code for the current block element. Because it can have
paths, the id attribute specifies the location of a document that provides the
script code for the current block element.

func attribute: The func attribute specifies the starting function name
to execute a file in the id attribute. Generally, because inputs of the function
are the values of input port elements of the current block, its arguments are not
required.

lang attribute: The lang attribute specifies the language of a particular
script in the DXL document.

3.2.2.5 The connect Element












Figure 3-7. The Schema of Connect Element

An element connect connects a source port element and a target port element

that are declared using an attribute source and target. It plays a role of a similar

channel to a communication path. Generally, an output port element of the source

block element becomes a source port element of connect element. And an input

port element of a target block element becomes a target port element of a


connect element.









id attribute: The id attribute specifies the name of the connect
element. The value of the id attribute generated by MXL-to-DXL translator
has the meaning of a hierarchical structure because the name of the blocks in
the higher layer in a multimodel are included.

3.2.2.6 The simulation Element











Figure 3-8. The Schema of Simulation Element

The simulation element includes the properties to execute generated simulation

codes and customize the behavior of an actual simulation model relatively according to a

physical time. So, the attributes of this element are different according to the simulation

environment. This element is defined in the outermost DXL element.

start time attribute: The start time attribute specifies the
virtual starting time in simulation for a current DXL model.

end time attribute: The end time attribute specifies the virtual
ending time in simulation for a current DXL model.

delta time attribute: The delta time attribute specifies the
virtual unit time in simulation for a current DXL model. So, end time-
start time/delta time is the number of generated ticks for current
simulation.

cycle time attribute: The cycle time attribute is used to
compensate the difference between virtual time and physical time. So, we can
control the speed of moved or animated objects according to physical time.










3.3 The Semantic of DXL

3.3.1 The DXL Notation


Notation
IPi: a set of input ports for a block i
IPi(n): the nth input port of a block i
OPi: a set of output ports for a block i
OPi(n): the nth output port of a block i
OBi(j): a set of output blocks for the jth port of a block i
SEND(t, DATA(i), IPk(j)): Current block sends data of ith output port
to jth input port of block k after time t


Figure 3-9. Block Notation of DXL

Figure 3-9 defines a notation to describe the functionalities of DXL blocks. We can

describe algorithmic semantic of blocks using a set theory and some pseudo codes. IP

and OP mean input port and output port of a block. The order of the port is an argument

and the identifier of its outer block is subscripted. So, the 1st and the 2nd input ports of

block B1 are IPB1 (1) and IPiB (2) The 1st and the 2nd output ports of block B1 are

OPB1 (1) and OPB1 (2). OB means output blocks of current block. The input ports of

these output blocks get the output after the current block finishes its computation. The

order of an output port of the current block is an argument and the identifier of the

current block is subscripted. So, the output blocks of the 1st and the 2nd output ports of the

current block B1 are OBBi (1) and OBBi (2).

3.3.2 The Information Stream Mechanism of DXL

Figure 3-11 shows DXL contents for the left DXL model of Figure 3-10. Generally,

a DXL model is composed of "block" elements and "connect" elements. A DXL

block element is composed of "port" elements and "definition" elements but it









might include another DXL model when it represents a homogeneous multimodel. DXL

block elements are connected by each connect element through input and output

port elements. Input and output port elements can be included in a block element

and each port element is connected to the corresponding output and input port

element of other block elements for its data flow, which each connect element

controls.



Block

Block OP (1) IP ( Block
1 2 Input port

SEND(tl, DATA(1), IP2(1)) Output port
SConnect


Figure 3-10. Diagrammatic Presentation of DXL

The pseudo code SEND is the code to support information streaming which

operates according to the different modes. For example, the pseudo code SEND means

"generate next event" based on discrete event scheduling methods [19, 27] in sequential

simulation and "send message" based on message-passing protocols in distributed

simulation. This information streaming abstraction approach used to generate different

target codes on heterogeneous environments makes it easy to create DXL-to-simulation

translator and integrate model components.

In Figure 3-9, the meaning of SEND pseudo code is "transfer DATA in an output

port OP of a block B1 to an input port IP of a block B2 and generate next event B2,

after time t passes" based on discrete event scheduling methods. If this model is based

on message-passing protocols in distributed simulation, this SEND pseudo code means











"create DATA in an output port OP of a block B1 as a message and send the message to


an input port IP of a block B2, after time t passes"































Figure 3-11 Model of DXL for Figure 4-2 Example

In Figure 3-10, the meanings based on discrete event scheduling methods of SEND

pseudo codes are as the follows:


* SEND(ti, DATA(1),
block B, to an input port
time tl passes.

* SEND(tm, DATA(1),
block BM to an input port
time tm passes.


IPi (1) ) : Transfer DATA in an output port OP of a
IP1 of a block Bi and generate next event Bi, after



IPi (m) ): Transfer DATA in an output port OP of a
IPm of a block Bi and generate next event Bi, after


* SEND (ti, DATA(1) IP1 (1) ) : Transfer DATA in an output port OP1 of
a block Bi to an input port IP of a block B, and generate next event B1, after
time ti passes.










SEND (ti, DATA(1) IPn (1) ) : Transfer DATA in an output port OPn of
a block Bi to an input port IP of a block BN and generate next event Bn, after
time ti passes.



Block (1) IP Block
1 SEND(t1, DATA(1) IP,(1)) SEND(t,, DATA(1) IP1 (1) )
tIPi(1) OPi (1)
0
Block


IPi (m) OPi(n) I
Block Block
B OPM SEND(tm, DATA(1) IP (m)) SEND (tM, DATA (1) IPn (1) )
m n
It OPM(1) IPn(1)


Figure 3-12. Examples of SEND Pseudo Code

In Figure 3-12, the meanings based on message-passing protocols in distributed

simulation of SEND pseudo codes are as the follows:

SEND (t DATA(1) IPi (1) ) : Create DATA in an output port OP1 of a
block B, as a message and send the message to an input port IPi of a block Bi,
after time tj passes.

SEND (tm, DATA(1) IPi (m) ) : Create DATA in an output port OP1 of a
block Bm as a message and send the message to an input port IPm of a block Bi,
after time tm passes.

SEND (ti, DATA(1) IP1 (1) ) : Create DATA in an output port OP1 of a
block Bi as a message and send the message to an input port IP1 of a block B1,
after time ti passes.

SEND (ti, DATA(1) IPn (1) ) : Create DATA in an output port OPn of a
block Bi as a message and send the message to an input port IP1 of a block Bn,
after time ti passes.

3.3.3 The XML-based Dataflow Semantic in DXL

XML schema provides a syntax structure of an XML document. It can be used to

check the validity of XML data when models exchange their data in a modeling and










simulation environment. Figure 3-13 describes two sorts of data-relationships in XML-

based modeling and execution.



'.......................'****
XML schema


Including schema
information

XML data m Model B
FXMTL data


Figure 3-13. The XML-based Dataflow in DXL

Assume Java and JavaScript simulation programs to describe XML data exchange

between different program languages on Web-based modeling and simulation

environment. If we can support the data conversion between programming languages and

XML data, it is possible to exchange the simulation data between different simulation

programs. Basic relationships between programming and modeling data are described as

follows:

Actual programming Java data for simulation are converted to XML data based
on their own XML schema.

An output port sends its own XML data to the input port of a receiving block,
where the XML data include their own XML schema link.

After checking XML validity, the input port of the receiving block converts the
XML data to actual JavaScript data.










The relationships between different models are the same as the basic relationships

except for XML data conversion using XSLT. For data compatibility between two

different models, we had to convert the XML data of model A to the XML data of model

B. Because both models have their data with an XML format, the conversion has the

same meaning as an XML document transformation if we use XSLT for our converter.

This usage of XML data with parameters makes it easy to use different

programming languages for a model. Current DXL-to-simulation translator supports

JavaScript and Java language using DOM. We will expand the supporting languages.

3.3.4 Synchronous and Asynchronous Input Semantic in DXL

Algorithm for a block having synchronous inputs
if(for VxEIPi, x has input data) then
The computation of the function in a DXL block
For VyEOPi, if(y has output data) then for zEVOBi(y), SEND(t,
DATA(y) z) elseif
elseif


Algorithm for block B3
if (for VxEIPB3, x has input data)

B1 IP1 OP1 B4 then
OPB3 () IPB3(1)/IPB3(2)
B3 OPB3(2) IPB3(1)%IPB3(2)


B2 W IP2 OP2 1 B5 SEND(tB4, DATA(OPB3(1)) B4)
SEND(tB5, DATA(OPB3(2)) B5)
elseif


Figure 3-14. Example of Synchronous Inputs

If a DXL block has more than one input, there are two options, synchronous and

asynchronous, in DXL. These two properties can not only support the properties of












multiple other model types but also expand the flexibility and efficiency of MXL-to-DXL


translation.








































:"B3.OPl">
lang="JavaScript">



="B3.OP2">
lang="JavaScript">


="INPUT" source="B1.OPl">
="OUTPUT" target="B3.IPl">


="INPUT" source="B2.OPl">
="OUTPUT" target="B3.IP2">


="INPUT" source="B3.OPl">
="OUTPUT" target="B4.IPl">


end time="" delta time="" cycle time"">


Figure 3-15. Source of DXL for Figure 3-14


If the DXL block has the same property as a programming function, this means that


the DXL block should execute its code after it has all its inputs like programming










functions to do. In DXL, the block is called "The block has synchronous input property".

In short, the block is a synchronous block in DXL.

Otherwise, the DXL block has the same property as a network node, this means

that the DXL block executes its code only if it has one of its inputs like a network node

service. In DXL, we say that "The block has asynchronous input property". In short, the

block is an asynchronous block in DXL.

Algorithm for a block having asynchronous inputs
if(for xIxEPi, x has input data) then
The computation of the function in a DXL block
For VyEOPi, if(y has output data) then for zEVOBi(y), SEND(t,
DATA(y) z) elseif
elseif



Algorithm for block B3
if (IPB3(1) has input data) then
OPB3 (2) IPB3 (1)
B1 I1 P B4 SEND(tB5, DATA(OPB3(2)) B5)
elseif
B3 if (IPB3(2) has input data) then
switch r/
OPB3 (1) IPB3 (2)
B2 I O B5 SEND(tB4, DATA(OPB(1)) B4)
elseif



Figure 3-16. Example of Asynchronous Inputs

3.3.4.1 Synchronous Input Property in DXL

Block B3 in Figure 3-14 divides the output of block B with the output of block B2

and then sends its quotient to block B4 and remainder to block B5. To make the division,

block B3 should have two inputs at the same time, which means that it is a synchronous

block in DXL. Note that the block has two output ports to support a different output at the












same time unlike the functions of traditional programming languages, which have just


one output. The right part of Figure 3-14 describes the processing algorithm of block B3.












func" lang="JavaScript">


















"B3.OPl">
lang="JavaScript">



"B3.OP2">
lang="JavaScript">
























Figure 3-17. Source of DXL for Figure 3-16






37


3.3.4.2 Asynchronous Input Property in DXL

In Figure 3-16, block B3 plays a role in switching input data. It is not necessary to

receive both inputs to relay its data. In other words, the block just relays its input to its

next block whenever it receives the input. The block should therefore have an

asynchronous input property. The switch block algorithm is described in the right part of

Figure 3-16. In DXL, the above combinations of simple blocks and their properties create

an actual model for a system.















CHAPTER 4
MULTIMODELING

4.1 Multimodeling through MXL and DXL

Multimodeling is a modeling process to model a system at multiple levels of

abstractions and a multimodel can be created to represent and analyze a complex system

through this process. Multimodeling is achieved through functional composition and

ports coupling. How can we achieve the functional composition and ports coupling? How

can we achieve multimodeling based on the two methods? In the RUBE framework, the

functional composition and ports coupling are described through MXL for heterogeneous

multimodeling and DXL for homogeneous multimodeling.


M2
Sl S3





Figure 4-1. Multimodel Structure of MXL

MXL [10] is an XML-based dynamic modeling language to represent traditional

model types on our RUBE framework. For MXL, the functional elements for each model

type are clearly identified and then entry points of the functional elements are defined as

ports. The functional elements are model components that behave as functions, or where

functions naturally fit as part of the model description. Figure 4-1 shows MXL

multimodel structure of MXL. Multimodeling is permitted wherever the appropriate

model component can be "extended" or "expanded" to another model whose outermost










definition is a function. These couplings achieve multimodeling through inserting one

function inside of another (inter-level coupling) or connecting the function to another

(intra-level coupling).



M1 M4 D1 D4
MXL-to-DXL
Translation M3 D3
M5 D
M1 -D1 M2 M5 D25
M2 D2
M3 D3
M4 D4
M5 D5 MXL Model Port DXL Model Port Connect
S-- Q Input port

I Output port


Figure 4-2. Heterogeneous and Homogeneous Models

The left part of Figure 4-2 shows an abstract view for our MXL. Each model can be

a heterogeneous model and is coupled using ports, which are interfaces for compatibility

of input and output types. Each model in the abstract MXL can be defined as a traditional

heterogeneous model by XML, which are FSM, FBM, Petri net, etc. Then each MXL

model can be translated into the contemporary DXL models by our model-specific

translators using XSLT. As the last process, our DXL-to-simulation translator generates

program language-specific simulation programs. The right part of Figure 4-2 shows a

simple view for the translated DXL for the left part of Figure 4-2. Each translated DXL

model is connected through input and output ports.

4.2 MXL-to-DXL Translation

4.2.1 Basic MXL-to-DXL Translation Example

MXL models are heterogeneous models. Each heterogeneous model is defined by

the corresponding MXL. The MXL model of Figure 4-3 contains fbm element and

simulation element as sub-elements. fbm element represents a Functional Block











Model (FBM). It has two elements, namely block element and trace element. Each


block element has an attribute, id, to specify the names of blocks. In addition, the


element has the information of port element, input and/or output, as well as its


functionality, script element.





index="0"/>