DEVS-Vezbe-Racunarske simulacije-Infomratika, Vežbe' predlog Računarske simulacije. Univerzitet Singidunum
dcplover
dcplover

DEVS-Vezbe-Racunarske simulacije-Infomratika, Vežbe' predlog Računarske simulacije. Univerzitet Singidunum

85 str.
821broj poseta
Opis
Devs, racunarske simulacije, vezbe, informatika,modeling and simulation using devs, vezbe su na engleskom, beleske sa vezbi su na engleskom, atomic devs, coupled devs, inputport, outputport, base devs, constructor, run ...
20 poeni
poeni preuzimanja potrebni da se preuzme
ovaj dokument
preuzmi dokument
pregled3 str. / 85
ovo je samo pregled
3 prikazano na 85 str.
preuzmi dokument
ovo je samo pregled
3 prikazano na 85 str.
preuzmi dokument
ovo je samo pregled
3 prikazano na 85 str.
preuzmi dokument
ovo je samo pregled
3 prikazano na 85 str.
preuzmi dokument

Moon Ho Hwang DEVS# version 1.2.1

ii

Copyright c©20062007, Moon Ho Hwang (moon.hwang@gmail.com). All rights reserved.

You can cite this manual in the form of BibTex as follows.

@MANUAL{DEVSsharp,

TITLE = "{Modeling and Simulation using DEVS\#}",

author = "Moon Ho Hwang",

address = "http://xsy-csharp.sourceforge.net/DEVSsharp",

edition = "first",

month = "May",

year = "2007",

}

Preface

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.

- Antoine de Saint Exupery

DEVS# is an open source library that is an implementation of discrete event system specification (DEVS) formalism in C# language. More than 30 years ago, Dr. Zeigler introduced DEVS to the public through his first book [Zei76], and its second edition [ZPK00] became available in 2000 due to the help of other two authors, Dr. Praehofer and Dr. Kim.

In 2005 when I tried to make DEVS# which is an another open source library of DEVS formalism in C++, I had a chance to use C# language in a project. During the project, I realized that C# has some advantages over C++ such as garbage collection, type checking functionality, Web functionality, etc. Then, I compared the execution speeds of these two languages. Surprisingly, C# is not slower than C++ (frankly speaking, C# was little bit faster than C++ in my test case). After the speed testing, I got started to implement a DEVS open library in C# through the sourceforge.net in 2006. Finally, I could open DEVS# library at http://xsy-csharp.sourceforge.net/DEVSsharp.

Although the main objective of developing DEVS# is to provide not only a modeling and simulation environment but also a modeling and verification software based-on DEVS theory, this document would focus on the first func- tionality: modeling and simulation. However, since this document is not a C# programming book, this book doesn’t cover the syntax of C# and how to use Visual Studio developing environment in depth. Thus, I would recommend you to read introductory book of C# first if the reader is not familiar with C# language.

This document consists as follows. Chapter 1 provides a belief review of DEVS formalism including a verbal

description of DEVS behavior. Chapter 1 also gives sample codes for a ping- pong game using DEVS# so we can see what the DEVS# codes look like.

iv Preface

Chapter 2 explains the DEVS# library in terms of the object oriented pro- gramming paradigm of C#. We will see the class hierarchy and some of the virtual or the abstract functions the user is supposed to override to make a con- crete class. In addition, this section introduces a menu that DEVS# provides when we run DEVS# from a console.

Chapter 3 demonstrates several simple examples from atomic DEVS models to a coupled DEVS network. In these examples, we can check the knowledge learned from the previous chapters.

Chapter 4 deals with one of major goals of simulation study, that is, how to measure some performance indices. To do this, the mathematical definitions of throughput, cycle time, utilization and average queue length are addressed first, then their implementations in DEVS# are introduced using a practical example.

As an appendix, Chapter 5 briefly covers the structure of DEVS# library, how to compile examples which are provided in DEVS#, and how to add our own project or solution using Visual Studio 2005. If you want to compile, build, and run the examples first, you’d better read this chapter first.

Acknowledgements

I would thank Dr. Tag Gon Kim and Dr. Bernard. P. Zeigler for introducing me the world of DEVS.

Many thanks to Dr. Russ Mayers who read the entire document of DEVS++ [Hwa07], corrected some of my not so excellent English expressions, and sug- gested some interesting systems engineering ideas. Without his devoted help, [Hwa07] that provides the foundation of this book, could never have been com- pleted.

Special thanks are also due to my wife, Su Kyeon Cho, my mom Kyoung-Ai Kim, and my dad, Seung Hun Hwang who passed away in 2005 when I got started to implement DEVS#.

Tucson, Arizona May, 2007

Moon Ho Hwang

Contents

Preface iii

1 DEVS Formalism and DEVS# code 1 1.1 Atomic DEVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Coupled DEVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3 Building Ping-Pong Game using DEVS# . . . . . . . . . . . . . 5

2 Structure of DEVS# 11 2.1 Event=PortValue . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1.1 Named . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.1.2 Port, InputPort, and OutputPort . . . . . . . . . . . . . . 12 2.1.3 PortValue . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2 DEVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.2.1 Base DEVS: Devs . . . . . . . . . . . . . . . . . . . . . . 14 2.2.2 Atomic DEVS: Atomic . . . . . . . . . . . . . . . . . . . . 15 2.2.3 Coupled DEVS: Coupled . . . . . . . . . . . . . . . . . . 17

2.3 Scalable Real-Time Engine: SRTEngine . . . . . . . . . . . . . . 18 2.3.1 Constructor . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.3.2 Run console menu . . . . . . . . . . . . . . . . . . . . . . 18

2.4 Random Variables . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.4.1 Probability Density Functions . . . . . . . . . . . . . . . . 23 2.4.2 Probability Mass Function . . . . . . . . . . . . . . . . . . 24

3 Simple Examples 27 3.1 Atomic DEVS Examples . . . . . . . . . . . . . . . . . . . . . . . 27

3.1.1 Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.1.2 Vending Machine . . . . . . . . . . . . . . . . . . . . . . . 29

3.2 Coupled DEVS Examples . . . . . . . . . . . . . . . . . . . . . . 34 3.2.1 Monorail System . . . . . . . . . . . . . . . . . . . . . . . 34

vi CONTENTS

4 Performance Evaluation 43 4.1 Performance Measures . . . . . . . . . . . . . . . . . . . . . . . . 43

4.1.1 Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.1.2 Cycle Time . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.1.3 Utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.1.4 Average Queue Length . . . . . . . . . . . . . . . . . . . . 46 4.1.5 Sample Mean, Sample Variance, and Confidence Interval . 47

4.2 Practice in DEVS# . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.2.1 Throughput and System Time in DEVS# . . . . . . . . . 49 4.2.2 Utilization in DEVS# . . . . . . . . . . . . . . . . . . . . 54 4.2.3 Average Queue Length in DEVS# . . . . . . . . . . . . . 56

4.3 Client-Server System . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.3.1 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.3.2 Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.3.3 Performance Analysis . . . . . . . . . . . . . . . . . . . . 62

5 Appendix: Building Projects using DEVS# 67 5.1 Directory Structure of DEVS# . . . . . . . . . . . . . . . . . . . 67 5.2 Building Simulation Examples in DEVS# . . . . . . . . . . . . . 68 5.3 Adding Our Own Project . . . . . . . . . . . . . . . . . . . . . . 68

List of Figures

1.1 Symmetric Structure of Atomic DEVS . . . . . . . . . . . . . . . 2 1.2 State Transition Diagram of Ping-Pong Player . . . . . . . . . . 3 1.3 DEVS Model of Ping-Pong Game . . . . . . . . . . . . . . . . . . 5 1.4 References of Ex PingPong . . . . . . . . . . . . . . . . . . . . . 7

2.1 Classes in DEVS# . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2 Relations of Times . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.3 PMF f(s) and its cumulative function F (x) . . . . . . . . . . . . 25

3.1 Timer (a) State Transition Diagram (b) Event Segment (c) te Trajectory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2 State Transition Diagram of Vending Machine . . . . . . . . . . . 30 3.3 Monorail System . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.4 Phase Transition Diagram of Station . . . . . . . . . . . . . . . . 35

4.1 A System having a Buffer and a Processor . . . . . . . . . . . . . 44 4.2 State Trajectory of a Processor . . . . . . . . . . . . . . . . . . . 45 4.3 A State Trajectory of Vending Machine . . . . . . . . . . . . . . 45 4.4 Trajectory of Queue . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.5 IID random variants X1 . . . Xn from n simulation runs . . . . . . 48 4.6 State Transition Diagrams of Generator: (a) Autonomous Mode

(b) Non-Autonomous Mode . . . . . . . . . . . . . . . . . . . . . 50 4.7 State Transition Diagrams of Transducer . . . . . . . . . . . . . . 53 4.8 Configuration of Client Server System n = 3 . . . . . . . . . . . . 58 4.9 Server and Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.10 Performance Indices . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.1 Directory Structure of DEVS# . . . . . . . . . . . . . . . . . . . 67 5.2 Screen Capture of Visual Studio 2005TM when opening DEVSsharp.sln

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 5.3 New Project Dialog . . . . . . . . . . . . . . . . . . . . . . . . . 70

viii LIST OF FIGURES

5.4 My Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 5.5 Menu Selection of Add Existing Project... . . . . . . . . . . . . . 72 5.6 Menu Selection of Add Reference... . . . . . . . . . . . . . . . . . 72 5.7 Dialog of Add Reference . . . . . . . . . . . . . . . . . . . . . . . 73

List of Tables

4.1 Performance Indices for each n = i of Servers . . . . . . . . . . . 63

Chapter 1

DEVS Formalism and

DEVS# code

This chapter introduces DEVS formalism in terms of the atomic DEVS to define the dynamic behavior, and the coupled DEVS to build the hierarchical network structure.

1.1 Atomic DEVS

An atomic DEVS model is defined by a 7-tuple structure

A =< X,Y, S, s0, τ, δx, δy >

where

• X is a set of input events.

• Y is a set of output events.

• S is a set of states.

• s0 ∈ S is the initial state.

• τ : S → T ∪ {∞} is the time advance function where T = [0,∞) is the set of non-negative real numbers. This function is used to determine the lifespan of a state.

• δx : P ×X → S × {0, 1} is the input transition function where

P = {(s, ts, te)|s ∈ S, ts ∈ T ∪ {∞}, te ∈ T}

2 DEVS Formalism and DEVS# code

Figure 1.1: Symmetric Structure of Atomic DEVS

is the set of states with times such that ts and te are the lifespan of the state, s, and the elapsed time since the last reset of te, respectively. δx defines how an input event, x, changes a state as well as the lifespan that the system can be in that state and the elapsed time that the system has been in that state.

• δy : S → Y φ × S 1 is the output transition function that defines how a state generates an output event and, at the same time, how it changes the state internally. This function can be invoked when the elapsed time reaches the lifespan. 2 ¥

Figure 1.1, also used as the cover illustration, shows the symmetric structure of DEVS in the sense that the input event set (X) and the input transition function (δx) are on the input side; the output event set (Y ) and the output transition function (δy) are on the output side; and a set of states (S) and its time advance function (τ) are in the middle.

Verbal Description of Dynamics

Suppose that A is an atomic DEVS such that A =< X,Y, S, s0, τ, δx, δy >, s is the current state of A, and p = (s, ts, te) ∈ P . Then the possible discrete state transitions are:

1. If an external input x comes in, A executes δx(p, x) = (s′, b) where b ∈ {0, 1} and the lifespan and the elapsed time with s′ can change or be preserved as follows.

(a) update ts = τ(s′) and te = 0 if b = 1;

1where Y φ = Y ∪ {φ}, φ 6∈ Y is the silent event 2In [ZPK00], δy is split into two functions: the output function λ : S → Y and the internal

transition function δint : S → S.

1.1 Atomic DEVS 3

Figure 1.2: State Transition Diagram of Ping-Pong Player

(b) keep ts and te preserved if b = 0.

2. If no external input comes in, then when the elapsed time reaches the lifetime, A executes δy(s) = (y, s′) and update ts = τ(s′) and te = 0.

Notice that the elapsed time te increases linearly over time so it is a continu- ous variable whose time derivative is constant 1. However, the lifetime ts is not changing continuously but it is determined discretely at the time of executing either δx or δy.

In other word, suppose that there is p = (s, ts, te) ∈ P at time tl ∈ T , there is another p′ = (s′, t′s, t

′ e) ∈ P at time tu ∈ T and tl ≤ tu. If there is no event

between tl and tu, it implies that the only difference between p and p′ is that their elapsed time such that (s′ = s) (t′s = ts) (t′e = te + tu − tl).

Example 1.1 (Ping-Pong Player) Figure 1.2 shows an atomic DEVS model for a ping-pong player. This model has an input event “?receive” and an output event “!send”. And it has two states: “Send” and “Wait”. Once the player gets into “Send”, it will generates “!send” and backs to “Wait” after the sending time which is an random variant in the uniform probability distribution function (pdf) of [0.1, 1.2]. When staying at “Wait” and if it gets “?receive”, it changes into “Send” again.

Formally we can rewrite this player as MPlayer =< X,Y, S, s0, τ, δx, δy > where X={?receive}; Y ={!send};S={Send, Wait}; s0=Send; τ(Send)[0.1, 1.2], τ(Wait)=; δx(s, ts, te, x) = δx(Send,,[0,ts],?receive) =(Send,1), δx(s, ts, te, x) = δx(Send,[0.1, 1.2],[0,ts],?receive)=(Send,0); δy(s) = δy(Send)=(!send,Wait); ¤

4 DEVS Formalism and DEVS# code

1.2 Coupled DEVS

The coupled DEVS provides the hierarchical and modular structure necessary to describe system networks. Formally, a coupled DEVS is defined by

N =< X, Y,D, {Mi}, EIC, ITC, EOC >

where

• X is a set of input events. • Y is a set of output events. • D is a set of names of sub-components • {Mi} is a set of DEVS models where i ∈ D. Mi can be either an atomic

DEVS model or a coupled DEVS model.

• EIC ⊆ X × i∈D

Xi is a set of external input couplings where Xi is the set

of input events of Mi.

• ITC ⊆ i∈D

Yi ×

i∈D Xi is a set of internal couplings where Yi is the set of

output events of Mi.

• EOC ⊆ i∈D

Yi × Y is a set of external output couplings. ¥

Verbal Description of Coupled DEVS Behavior

The coupled DEVS’s behavior is described verbally as follows.

1. When N receives an input event, the coupled DEVS transmits the input event to the sub-components through the set of external input couplings.

2. When a sub-component produces its output event, the coupled DEVS transmits the output event to the other sub-components through the set of internal couplings. The coupled DEVS also produces an output event of N through the set of external output couplings.

Example 1.2 (Ping-Pong Game) Consider a ping-pong game with two play- ers that each represented by the Player model introduced in Example 1.1 except the initial state.

This block diagram can be modeled by a coupled DEVS such as NPPGame =< X,Y, D, {Mi}, EIC, ITC, EOC > where X = {};Y = {}; D={A,B}; {Mi} ={Playeri} where Playeri is the atomic DEVS introduced in Example 1.1 with initial states Send for i=A, Wait for i=B, respectively; EIC={ }, ITC={ (A.!send, B.?receive), (B.!send, A.?receive)}, EOC = { }. ¤

1.3 Building Ping-Pong Game using DEVS# 5

Figure 1.3: DEVS Model of Ping-Pong Game

1.3 Building Ping-Pong Game using DEVS#

This section shows what DEVS# code looks like using the ping-pong game in- troduced in Example 1.2. When you open DEVSsharp\DEVSsharp.sln, you can find Ex_PingPong project in which there are two source files: Player.cs and Program_PingPong.cs. Let’s take a look at Player.cs first.

using DEVSsharp; //--- (1)

namespace Ex_PingPong

{

public class Player : Atomic //-- (2)

{

public InputPort receive; //-- (3)

public OutputPort send; //-- (3)

enum PHASE { Wait, Send}

PHASE m_phase; //-- (4)

bool m_width_ball; //-- (4)

RVofGeneralPDF rv; //-- (4)

public Player(string name, bool with_ball): base(name, TimeUnit.Sec)

{

receive = AddIP("receive"); //--(5)

send = AddOP("send"); //--(5)

m_width_ball = with_ball;

rv = new RVofGeneralPDF(); //-- (6)

init();

}

6 DEVS Formalism and DEVS# code

public override void init() { //-- (7)

if (m_width_ball)

m_phase = PHASE.Send;

else

m_phase = PHASE.Wait;

}

public override double tau() //-- (8.a)

{

if (m_phase == PHASE.Send)

return rv.Uniform(0.1, 1.2);

else

return double.MaxValue;

}

public override bool delta_x(PortValue x) //-- (8.b)

{

if (m_phase == PHASE.Wait && x.port == receive)

{

m_phase = PHASE.Send;

return true;

}

else

{

Console.WriteLine("Do we have more than one ball?");

}

return false;

}

public override void delta_y(ref PortValue y) //-- (8.c)

{

if (m_phase == PHASE.Send)

{

y.Set(send);

m_phase = PHASE.Wait;

}

}

public override string Get_s() //-- (9)

{

return m_phase.ToString();

}

}

}

1.3 Building Ping-Pong Game using DEVS# 7

Figure 1.4: References of Ex PingPong

1. using DEVSsharp: First of all, we can find Ex_PingPong project uses a reference of DEVSsharp project which is indicated in Solution Explorer windows of Visual Studio 2005 as shown in Figure 1.4. 3 By using DEVSsharp, we can load information of name space, classes interfaces defined in DEVSsharp that is the kernel project name of DEVS#.

2. Deriving from Atomic: In this example, Player is a concrete class derived from Atomic which is an abstract class. We will see the class Atomic in Section 2.2.2.

3. Interfacing Ports: The port pointers are useful to identify the added ports. Without these pointers, we would have to search for each pointer by its name, and that can be a burden. For more information of the class Port, the reader can refer to Section 2.1.2

4. State Variables: The derived and concrete class of atomic DEVS will have its state variables to describe its dynamic situations. In DEVS#, we use member data of C# for the state variables.

5. Adding Interfaces: The interfacing port pointers mentioned in (5) are assigned by calling either the AddIP or the AddOP function in which mem- ory allocations and parent assignments are performed. A set of port re- lated functions defined at Atomic can be referred to Section 2.2.2.

6. Random Variable: The lifespan of Send is a random variable with uni- form probability density function (PDF) of [0.1,1.2]. To generate the ran-

3For more information of adding a reference, you can refer to Chapter 5.

8 DEVS Formalism and DEVS# code

dom number, Player defines a random variable rv as a general PDF random variable in (4), and pick the uniform PDF in the range[0.1, 1.2] in tau() function in (8.a). The PDFs available in DEVS# are addressed in Section 2.4.

7. The initial State s0: To make the initial state s0, all concrete classes derived from Atomic are supposed to override the function init() in which the associated atomic model is reset to the initial state s0. In this case of Player, the initial phase can be determined as Send or Wait depending on another variable, m_width_ball which is indicating to have a ball initially or not.

8. Characteristic Functions τ, δx and δy: all concrete classes derived from Atomic should override the characteristic functions: τ, δx, and δy.

(a) τ of Player returns the random number from [0.1, 1.2] when the state is Send, otherwise it returnsthat is represented by double.MaxValue.

(b) δx of Player changes the state Wait to Send when receiving the input event receive.

(c) δy of Player generates the output event send, at the same time, it changes the state Send to Wait.

9. Displaying Status: To show the current state, we will override the Get_s() function which is supposed to return a string representing the current state. Player returns the string value of m_phase variable.

A ping-pong match we are considering here needs two players that are in- stances of the previous class Player. We use the coupled DEVS in Program_PingPong.cs to model the match as shown in the following codes.

using DEVSsharp;

namespace Ex_PingPong

{

class Program_VM

{

static Devs MakePingPong(string name)

{

Coupled game = new Coupled(name); //-- (1)

Player A = new Player("A", true); //-- (2)

Player B = new Player("B", false);//-- (2)

game.AddModel(A); //-- (3)

1.3 Building Ping-Pong Game using DEVS# 9

game.AddModel(B); //-- (3)

game.AddCP(A.send, B.receive); //-- (4)

game.AddCP(B.send, A.receive); //-- (4)

game.PrintCouplings(); //-- (5)

return game;

}

static void Main(string[] args)

{

Devs md = MakePingPong("PingPong");

SRTEngine Engine = new SRTEngine(md, 10000, null);//--(6)

Engine.RunConsoleMenu();//--(7)

}

}

}

1. Making the Ping-Pong Game as coupled DEVS: We make an in- stance of Coupled in DEVS# for the ping-pong game.

2. Instancing Two Players The ping-pong game has two sub-components that are instances of Player having different initial states.

3. Adding Components We add two players A and B by calling the function AddModel of the class Coupled.

4. Adding Couplings We add couplings between players A and B calling the function AddCP of the class Coupled .

5. Print Couplings Even though it is not necessary, we can call the func- tion PrintCouplings() of Coupled to check the coupling status. The couplings of the ping-pong game are displayed as follows.

Inside of PingPong

-- External Input Coupling (EIC) --

------ # of EICs: 0-----

-- Internal Coupling (ITC) --

A.send --> B.receive

B.send --> A.receive

------ # of ITCs: 2-----

-- External Output Coupling (EOC) --

------ # of EOCs: 0-----

10 DEVS Formalism and DEVS# code

6. Making a simulation engine Instancing a scalable simulation engine SRTEngine can be done by calling its constructor that needs the model supposed to be simulated. In this example the model is the coupled model of the ping-pong game, pp. For more detailed information of SRTEngine, the reader can refer to Section 2.3.

7. Running the console menu We can use the console menu of SRTEngine by calling RunConsoleMenu(). After that, we will see the following screen on the selected console.

DEVS#: C# Open Source of DEVS Formalism, (C) 2005~2007,

http://xsy-csharp.sourceforge.net/DEVSsharp/

The current date is 5/6/2007.

The current time is 1:05:52 PM.

scale, step, run, mrun, [p]ause, pause_at, [c]ontinue, reset,

rerun, [i]nject, dtmode, animode, print, cls, log, [e]xit

>

The first part shows the header of DEVS# and current date and time. The second part shows the available command set. Even we don’t have clear idea of each command, let’s try“ run” and then “exit”.

The detailed information of each command will be provided in Section 2.3.

Chapter 2

Structure of DEVS#

DEVS# is an C# open source of DEVS formalism. Thus, there are two features: one comes from C# language, the other from the formalism. Figure 2.1 shows the hierarchy relation among classes used in DEVS#.

As we reviewed in Chapter 1, two DEVS models called atomic DEVS and coupled DEVS have common features such as input and output event inter- faces as well as time features such as current time, elapsed time, schedule time and so on. In DEVS#, these common features have been captured by a base class, called Devs from which the class Atomic (for atomic DEVS) and the class Coupled (for coupled DEVS) are derived.

In DEVS#, an event is a PortValue that is a pair of (port, value) where port can be an instance of either InputPort class or OutputPort class, while value is an instance of any derived class of the basic class object of C#. SRTEngine is a scalable real-time engine which runs a DEVS instance inside.

In Figure 2.1, a gray box indicates a concrete class which can be created as

Figure 2.1: Classes in DEVS#

12 Structure of DEVS#

an instance, while a white box is an abstract class which can not be created as an instance.

We will first go through PortValue related classes in Section 2.1. Next, Devs class and its derived two classes: Atomic and Coupled will be investi- gated in Section 2.2. Section 2.3 will introduce a simulation engine class, called SRTEngine. And finally, we will see the random number generator classes in Section 2.4.

2.1 Event=PortValue

An event will be modeled by an instance of PortValue class which is a pair of Port and Value. We will first see the top-most base class, called “Named”. Then we will look at Port-related classes, and finally, the PortValue class will be seen in the last part of this section.

2.1.1 Named

Named is defined in Named.cs file as a concrete class. The class provides its constructor whose argument is a string, and has a public Name field as a string. The function ToString() is the function overrided from object::ToString().

public class Named

{

public String Name;

public Named(string name)

{

m_Name = name;

}

public override string ToString()

{

return m_name;

}

}

2.1.2 Port, InputPort, and OutputPort

The Port.cs file defines three classes Port, InputPort and OutputPort as follows.

class Port: public Named

{

2.1 Event=PortValue 13

public Devs Parent;

protected List<Port> m_FromP, // From Ports

m_ToP; // To Ports

public List<Port> FromP { get { return m_FromP; } }

public List<Port> ToP { get { return m_ToP; } }

};

class InputPort: public Port {

...

};

class OutputPort: public Port {

...

};

Port is an abstract class derived from Named. It has Parent field whose type is Devs, and which is automatically assigned when we call the AddIP() and AddOP() functions of Devs (see Section 2.2). Port has “List<Port> ToP” as a set of successors as well as “List<Port> FromP” as a set of predecessors which are changed when we call AddCP() and RemoveCP() of Coupled (see Section 2.2.3).

InputPort and OutputPort are concrete and derived classes from Port.

2.1.3 PortValue

As mentioned before, an event in DEVS# is modeled by PortValue class that have a pair of a deriving class of Port and a deriving class of object. The following codes are parts of PortValue.cs.

class PortValue {

public:

public Port port; //-- either an output or an input port

public object value; // deriving class from the Object class

public PortValue(Port prt){...}

public PortValue(Port prt, object v) {...}

public void Set(Port prt){...}

public void Set(Port prt, object v){...}

public override string ToString(){...}

};

Two constructors and two Set functions are available whose arguments can be Port p which means value v=null, or a pair of (Port p and object v). The

14 Structure of DEVS#

function ToString() returns the string concatenating of port and value (if value is not null) by using a delimiter ‘:’ character.

2.2 DEVS

As introduced in Chapter 1, DEVS has two basic structures: atomic DEVS and coupled DEVS. In DEVS#, these two structures are implemented as the classes Atomic and Coupled, respectively, and are derived from the base class Devs. Thus Devs has the common member data and functions of both Atomic and Coupled.

2.2.1 Base DEVS: Devs

Devs defined in the source file Devs.cs is an abstract class derived from Named. Devs points its parent through its Parent field which is assigned by Coupled::AddModel() (see Section 2.2.3).

public class Devs: Named {

public Coupled Parent; // parent pointer

...

There are adding, getting, removing, and printing functions for the input ports denoted as AddIP, GetIP, RemoveIP, and PrintAllIPs. Similarly, AddOP, GetOP, RemoveOP, and PrintAllOPs are available functions for the output ports.

In addition, IP and OP get the set of input ports as SortedList<string, InputPort> and the set of output ports as SortedList<string, OutputPort>, respectively.

//-- X port Methods --

InputPort AddIP(string ipn);

InputPort GetIP(string ipn) const;

InputPort RemoveIP(string ipn);

void PrintAllIPs() ;

public SortedList<string, InputPort> IP {get ; }

//-- Y port Methods --

OutputPort AddOP(string opn);

OutputPort GetOP(string opn) const;

OutputPort RemoveOP(string opn);

void PrintAllOPs() ;

public SortedList<string, OutputPort> OP {get ; }

Devs has time-related properties such as TimeLast for getting (or setting) the last schedule update time; TimeNext for the next schedule time; TimeElapsed

2.2 DEVS 15

Figure 2.2: Relations of Times

for the elapsed time between the last schedule time and the current time; TimeRemaining for the remaining time from the current time to the next sched- ule time; TimeAdvance for the time difference between TimeNext and TimeLast.

TimeCurrent is a static and public data field for the current time;

public double TimeLast { get; set; }

public double TimeNext { get; set; }

public double TimeElapsed { get; }

public double TimeRemaining { get; }

public double TimeAdvance { get; }

public static double TimeCurrent ; // data field

Figure 2.2 illustrates the relationships among different times. The user doesn’t have to set the values of these time variables because such calculation will be performed by the simulation engine class, called SRTEngine in DEVS#, according to the user-defined τ(s) for each state of each model. For more de- tailed information this algorithm, the user can refer to [Zei87, ZPK00]

2.2.2 Atomic DEVS: Atomic

The atomic DEVS is implemented as Atomic in Atomic.cs file. Atomic is an abstract class that is derived from Devs.

public abstract class Atomic: Devs

{

public TimeUnit TimeUnit { get; }

nema postavljenih komentara
ovo je samo pregled
3 prikazano na 85 str.
preuzmi dokument