Mathworks SIMEVENTS 3 Installation Guide

Download

SimEvents

Getting Started

Guide

How to Contact The MathWorks

www.mathworks. comp.soft-sys.matlab Newsgroup www.mathworks.com/contact_TS.html Technical Support

suggest@mathworks.com Product enhancement suggestions

bugs@mathwo doc@mathworks.com Documentation error reports service@mathworks.com Order status, license renewals, passcodes

info@mathwo

com

rks.com

Web

Bug reports

Sales, prici

ng, and general information

508-647-7000 (Phone)

508-647-7001 (Fax)

The MathWorks, Inc. 3 Apple Hill Drive Natick, MA 01760-2098

For contact information about worldwide offices, see the MathWorks Web site.

SimEvents

The software described in this document is furnished under a license agreement. The software may be used or copied only under the terms of the license agreement. No part of this manual may be photocopied or reproduced in any form without prior written consent from The MathW orks, Inc.

FEDERAL ACQUISITION: This provision applies to all acquisitions of the Program and Documentation by, for, or through the federal government of the United States. By accepting delivery of the Program or Documentation, the government hereby agrees that this software or documentation qualifies as commercial computer software or commercial computer software documentation as such terms are used or defined in FAR 12.212, DFARS Part 227.72, and DFARS 252.227-7014. Accordingly, the terms and conditions of this Agreement and only those rights specified in this Agreement, shall pertain to and govern theuse,modification,reproduction,release,performance,display,anddisclosureoftheProgramand Documentation by the federal government (or other entity acquiring for or through the federal government) and shall supersede any conflicting contractual terms or conditions. If this License fails to meet the government’s needs or is inconsistent in any respect with federal procurement law, the government agrees to return the Program and Docu mentation, unused, to The MathWorks, Inc.

Trademarks

MATLAB and Simulink are registered trademarks of The MathWorks, Inc. See

www.mathworks.com/trademarks for a list of additional trademarks. Other product or brand

names may be trademarks or registered trademarks of their respective holders.

Patents

The MathWorks products are protected by one or more U.S. patents. Please see

www.mathworks.com/patents for more information.

Getting Started Guide

Revision History

November 2005 Online only New for Version 1.0 (Release 14SP3+) March 2006 First printing Revised for Version 1.1 (Release 2006a) September 2006 Online only Revised for Version 1.2 (Release 2006b) March 2007 Online only Revised for Version 2.0 (Release 2007a) September 2007 Online only Revised for Version 2.1 (Release 2007b) March 2008 Second printing Revised for Version 2.2 (Release 2008a) October 2008 Online only Revised for Version 2.3 (Release 2008b) March 2009 Online only Revised for Version 2.4 (Release 2009a) September 2009 Online only Revised for Version 3.0 (Release 2009b) March 2010 Online only Revised for Version 3.1 (Release 2010a)

Introduction

Product Overview ................................. 1-2

What Is Discrete-Event Simulation? Resources for Learning

............................. 1-3

.................. 1-2

Contents

Related Products

1 From the m odel window, select Simulation > Configuration

Parameters.

2 In the resulting Configuration Parameters dialog box, select Solver.

e to

3 Set Typ

Variable-step.

Code Generation

SimEv the Re Simu docu

ents blocks have limited support for the generation of code using al-Time Workshop

lation for Discrete-Event Simulations” in the SimEvents user guide

mentation.

product. For details, see “Limitations of Rapid

Simulation Modes

Events blocks do not support simulation using the Rapid Accelerator,

Sim

cessor-in-the-Loop (PIL), or External mode.

Pro

1-5

1 Introduction

Model Reference

SimEvents blocks cannot be in a model that you reference through the Model block.

Function-Call Split Block

SimEvents blocks cannot connect to the Function-Call Split block. Instead, to split a function-call signal that invokes or originates from a SimEvents block, use the Signal-Based Event to Function-Call Event block as in “Example: Issuing Two Function Calls in Sequence” in the SimEvents user guide documentation.

1-6

Installing SimEvents Software

To use this software, first install all these products:

• MATLAB

• Simulink

• SimEvents

For instructions, see the MATLAB documentation about installing on your platform.

Installing SimEvents®Software

1-7

1 Introduction

What Is an Entity?

Discrete-event simulations typically involve discrete items of interest. By definition, these items are called entities in SimEvents software. Entities can pass through a network of queues, servers, gates, and switches during a simulation. Entities can carry data, known in SimEvents software as attributes.

Note Entities are not the same as events. Events are instantaneous discrete incidents that change a state variable, an output, and/or the occurrence of other events. See “What Is an Event?” on page 1-9 for details.

Examples of entities in some sample applications are in the table.

Context of

Airport w access

Communi

Bank of e

Convey

Compu

A graphical block can represent a component that processes entities, but entities themselves do not have a graphical representation. When you design and analyze your discrete-event simulation, you can choose to focus on:

• The entities themselves. For example, what is the average waiting time for

a series of entities entering a queue?

• The processes that entities undergo. For example, which s tep in a

multiple-step process (that entities undergo) is most susceptible to failure?

Sample Application

ith a queue for runway

cation network

levators

or belt for assembling parts

ter operating system

Entities

Airplane runway

Packets transmi

People traveling in elevators

Parts to assemble

Compu

s waiting for access to

, frames, or messages to t

tational tasks or jobs

1-8

What Is an Event?

In this section...

“Overview of Events” on page 1-9

“Relationships Among Events” on page 1-9

“Viewing Events” on page 1-10

Overview of Events

In a discrete-event simulation, an event is an instantaneous discrete incident that changes a state variable, an output, and/or the occurrence of other events. Examples of events that can occur during simulation of a SimEvents model are:

• The advancement o f an entity from one block to another.

• The completion of service on an entity in a server.

What Is an Event?

• A zero crossing of a signal connected to a block that you configure to react

to zero crossings. These events are also called trigger edges.

• A function call, which is a discrete invocation request carried from block to

block by a special signal called a function-call signal. Function calls are the recommended w ay to make Stateflow libraries respond to asynchronous state changes.

For a full list of supported events and more details on them, see “Working with Events” online.

blocks and blocks in the Simulink

Relationships Among Events

Events in a simulation can depend on each other:

• One event can be the sole cause o f another event. For example, the arrival

of the first entity in a queue causes the queue length to change from 0 to 1.

• One event can enable another event to occur, but only under certain

conditions. For example, the completion of service on an entity makes the entity ready to depart from the server. However, the departure occurs only

1-9

1 Introduction

if the subsequent block is able to accept the arrival of that entity. In this case, one event makes another event possible, but does not solely cause it.

Events that occur at the same value of the simulation clock are called simultaneous events, even if the application processes sequentially. When simultaneous events are not causally related to each other, the processing sequence can significantly affect the simulation behavior. For an example, see the Ev ent Priorities demo or “Example: Choices of Value s for Event Priorities”. For more details, see “Processing Sequence for Simultaneous Events” online.

Viewing Events

Events do not have a graphical representation. You can infer their occurrence by observing their consequences, by using the Instantaneou s Event Counting Scope block, or by using the debugger. For details, see “Observing Events”, “Simulation Log in the Debugger”, or “Viewing the Event Calendar” online.

1-10

Running a Demo Simulation

In this section...

“Overview of the Model” on page 1-11

“Opening the Model” on page 1-11

“Examining Entities and Signals in the Model” on page 1-12

“Key Components of the Model” on page 1-14

“Running the Simulation” on page 1-16

Overview of the Model

One way to become familiar with the basics of SimEvents models and the way they work is to examine and run a previously built model. This section describes a SimEve nts demo model. The model simulates a technique for dynamically adjusting the energy con sumption of a microcontroller based on the workload, without compromising quality of service. Changes in the workload can occur as discrete events.

Running a Demo S imulation

Opening the Model

To open this demo, enter sedemo_DVS_model in the MATLAB Command Window.

1-11

1 Introduction

1-12

Alternatively, you can open the MATLAB Help browser and, in the Demos tab, click the + sign next to Simulink, SimEvents, and Application Demos. In the expanded list of application demos, double-click the listing fo r Dynamic Voltage Scaling Using Online Gradient Estimation.

Examining Entities and Signals in the Model

This section describes the different kinds of ports and lines that appear in the

sedemo_DVS_model model. Compared to signal ports, entity ports look

different and represent a different co n cept.

Running a Demo S imulation

Entity Ports and Connections

Some blocks in this mode l can process en titi es, which the “What Is an Entity?” on page 1-8 section discusses.

The FIFO Queue block and the Start Timer block, which are part of the SimEvents library set, process entities in this model. Each of these blocks has an entity input port and an entity output port. The following figure shows the entity output port of the FIFO Queue block and the entity input port of the Start Timer block.

Entity connection line

Entity output port

Entity input port

Entity connection lines represent relationships among two blocks (or among their entity ports) by indicating a path by which an entity can:

• Depart from one block

• Arrive simultaneously at a subsequent block

The preceding figure shows the connection line:

• From OUT, the entity output port of the FIFO Queue block

• To IN, the entity input port of the Start Timer block

When you run the simulation, entities that depart from the OUT port arrive simultaneously at the IN port.

1-13

1 Introduction

By convention, entity ports use labels with words in uppercase letters, such as IN and OUT.

You cannot branch an entity connection line. If your application requires an entity to arrive at multiple blocks, use the Replicate block to create copies of the entity.

Signals and Signal Ports

Some blocks in this model can process signals. S i gnals represent numer ica l quantities defined at all times during a simulation, not only at a discrete set of times. Signals appear as connection lines between signal ports of two blocks. The following figure shows that the Start Timer block has not only an entity output port but also a signal output port. The signal output port connects to the Random Service Time subsystem.

Signal connection line

Signal input port

1-14

Signal output port

Key Components of the Model

The sedemo_DVS_model model uses event-based blocks to simulate the workload of the microcontroller:

• At random times, the Time-Based Entity Generator block generates an

entity that represents a job for the microcontroller.

• The FIFO Queue block stores jobs that the microcontroller cannot process

immediately.

Running a Demo S imulation

• The Single Server block models the processing of a job by the

microcontroller.

This block can process at most one job at a time and thus limits the availability of the microcontroller to process new jobs . While a job is in this block, other jobs remain in the FIFO Queue block.

• TheStartTimerandReadTimerblocksworktogethertocomputethetime

that each job spends in the server. The result of the computation is the et output signal fro m the Read Timer block.

• The Entity Sink block absorbs jobs that h ave completed their processing.

Important discrete events in this model are the generation of a new job and the completion of processing of a job.

The model also includes blocks that simulate a dynamic voltage scaling (DVS) controller that adjusts the input voltage depending on the workload of the microcontroller. T he idea is to minimize the average cost per job, where the cost takes into account both energy consumption and quality of service. For more information about the cost and the optimization technique, see Dynamic Voltage Scaling Using Online Grad i ent Estimation onlin e.

Appearance of Entities

Entities do not appear explicitly in the model window. However, you can gather information about entities using plots, signals, and entity-related features in the debugger. See these sections for more information:

• “Example: Synchronizing Service Start Times with the Clock” online

• “Example: Selecting the First Available Serve r” on page 5-6

• “Plotting the Queue-Length Signal” on page 2-18, which is part of the

larger example “Building a Simple Discrete-Event Model” on page 2-2

• “Inspecting Entities” online

1-15

1 Introduction

Running the Simu

To run the sedemo the model window how the DVS cont the average cos voltage and co

_DVS_model

. A Figure window opens with a dynamic plot showing

roller varies the voltage during the simulation to reduce

t per job. A triangle marker moves to indicate the current

rresponding cost.

lation

simulation, choo se Simulation > Start from

1-16

Building Simple Models with SimEvents Software

• “Building a Simple Discrete-Event Model” on page 2-2

• “Exploring a Simulation Using the Debugger and Plots” on page 2-14

• “Building a Sim ple Hybrid Model” on page 2-26

• “Reviewing Key C oncepts in SimEvents Software” on p ag e 2-43

2 Building Simple Mode ls with SimEvents

Software

Building a Simple Discrete-Event Model

In this section...

“Overview of the Example” on page 2-2

“Opening a Model and Libraries” on page 2-3

“Moving Blocks into the Model Window” on page 2-5

“Configuring Blocks” on page 2-9

“Connecting Blocks” on page 2-12

“Running the Simulation” on page 2-12

Overview of the Example

This section describes how to build a new model representing a discrete-event system. The system is a simple queuing system in which “customers” — entities — arrive at a fixed deterministic rate, wait in a queue, and advance to a server that operates at a fixed deterministic rate. This type of system is known as a D/D/1 que uing system in queuing notation. T h e notation indicates a deterministic arrival rate, a deterministic service rate, and a single server.

2-2

Using the example system, this sectionshowsyouhowtoperformbasic model-building tasks, such as:

• Adding blocks to models

• Configuring blocks using their parameter dialog boxes

The next section, “Exploring a Simulation Using the Debugger and Plots” on page 2-14, uses the same D/D/1 system to illustrate technique s more specific to discrete-event simulations, such as:

• Using the SimEvents debugger to examine the state of a server

• Using plots to understand simulation behavior, including plots that show

multiple values at a fixed time

Building a Simple Discrete-Event Model

To skip the model-building steps and open a completed version of the example model, enter Window. S ave the model in your working folder as

simeventsdocex('doc_dd1') in the MATLAB Command

dd1.mdl.

Opening a Model and Libraries

The first steps in building a model are to set up your environment, open a new model window, and open the libraries containing blocks.

Setting Default Parameters for Discrete-Event Simulation

To change the default Simulink model settings to values that are appropriate for discrete-event simulation modeling, enter this in the MATLAB Command Window:

simeventsstartup('des');

A message indicates that default simulation settings have changed. The changed settings apply to new models that you create later in this MATLAB software session, but not to previously created models.

Note To specify these model settings each time you start MATLAB software, invoke

simeventsstartup from your startup.m file.

Opening a New Model Window

Select File>New>Modelfrom the menu in the MA TLAB desktop w indow. This opens an empty model window.

2-3

2 Building Simple Mode ls with SimEvents

Software

To name the model and save it as a file, select File > Save from the model window’s menu. Save the model in your working folder under the file name

dd1.mdl.

Opening SimEvents Libraries

In the MATLAB Command Window, enter

simeventslib

Alternatively, click the Start button in the lower-left corner of the MATLAB desktop. In the m enu that appears, select Simulink>SimEvents>Block Library.

The main SimEvents library window appears. This window contains an icon for each SimEvents library. To open a library and view the blocks it contains, double-click the icon that represents that library.

2-4

Building a Simple Discrete-Event Model

Opening

In the MATLAB Command Window, enter

simuli

The Simulink Library Browser opens, using a tree structure to display the available libraries and blocks. To view th e blocks in a library listed in the left pane, select the library name, and the list of blocks appears in the right pane. The Library Browser provides access not only to Simulink blocks but also to SimEvents blocks. For details about the Library Browser, see “Simulink Library Browser” in the Simulink documentation.

Simulink Libraries

Moving Blocks into the Model Window

To move blocks from libraries into the model window, follow these steps:

2-5

2 Building Simple Mode ls with SimEvents

1 In the main SimEvents library window, double-click the Generators i con

to open the Generators library. Then double-click the Entity Generators icon to open the Entity Generators sublibrary.

2 Drag the Time-Based Entity Generator block from the library into the

model window.

Software

2-6

This might cause an informational dia log b ox to op en , with a brief description of the difference between entities and events.

Building a Simple Discrete-Event Model

3 In the main SimEvents library window, double-click the Queues icon to

open the Queues library.

4 Drag the FIFO Q ueue block from the library into the model window.

2-7

2 Building Simple Mode ls with SimEvents

5 In the m ain SimEvents library window, double-click the Servers icon to

open the Servers library.

6 Drag the Single Server block from the library into the model wi ndow.

7 In the main SimEvents library window, double-click the SimEvents Sinks

icon to open the SimEvents Sinks library.

Software

2-8

8 Drag the Signal Scope block and the Entity Sink block from the library

into the model window.

Building a Simple Discrete-Event Model

As a result, the model window looks like the following figure. The model window contains blocks that represent the key processes in the simulation: blocks that generate entities, store entities in a queue, serve entities, and create a plot showing relevant data.

Configuring Blocks

Configuring the blocks in dd1 means setting their parameters appropriately to represent the system being modeled. Each block has a dialog box that enables you to specify parameters for the block. Default parameter values might or might not be appropriate, depending on what you are modeling.

Viewing Parameter Values

Two i mportant parameters in this D/D/1 queuing system are the arrival rate and service rate. The reciprocals of these rates are the duration between successive entities and the duration of service for each entity. To examine these durations, do the following:

1 Double-click the Time-Based Entity Generator block to open its dialog box.

Observe that the Distribution parameter is set to Period parameter is set to

1. This m eans that the block generates a new

entity every second.

2 Double-click the Single Server block to open its dialog box. Observe that

the Service time parameter is set to

1. This means that the server spends

one second processing each entity that arrives at the block.

Constant and that the

2-9

2 Building Simple Mode ls with SimEvents

3 Click Cancel in both dialog boxes to dismiss them w ithou t changing any

parameters.

The Period and Service time parameters have the same value, which means that the server completes an entity’s service at exactly the same time that a new entity is being created. The Event Priorities demo discusses this simultaneity in more detail.

Changing Parameter Values

Configure blocks to create a plot that shows w hen each e ntity departs from the server, and to make the queue have an infinite capacity. Do this as follows:

1 Double-click the Si n gl e Server block to open its dialog box.

2 Click the Statistics tab to view parameters related to the statistical

reporting of the block.

3 Set the Number of entities departed parameter to On.

Software

2-10

Building a Simple Discrete-Event Model

Then click OK. The Single Server block acquires a signal output port labeled #d. During the simulation, the block will produce an output signal at this #d port; the signal’s value is the running count of entities that have completed their service and departed from the server.

4 Double-click the FIFO Queue block to open its dialog box.

5 Set th

e Capacity parameter to

Inf and click OK.

2-11

2 Building Simple Mode ls with SimEvents

Software

Connecting Bloc

Now that the mode processes, co nn To connect bloc the input port o

ect the blocks to indicate relationships among them as shown.

ks with the mouse, drag from the output port of one block to

f another block.

lwindowfor

dd1 contains blocks that represent the key

Running the Simulation

Save the dd1 model you have created. Then start the simulation by choosing Simulation > Start from the model window’s menu.

Suppressing Solver Warnings

If y o u skipped “Setting De fault Parameters for Discrete-Event Simulation” on page 2-3, then you might see warning me ssa ge s in the MATLAB Command Window about continuous states and the maximum step size. These messages appear because certain default pa r ameters for a Simulink model are inappropriate for this particular example model. The application overrides the inappropriate parameters and alerts you to that fact.

2-12

One way to suppress the warning messages when you run this simulation in the future is to enter this command in the MATLAB Command Window:

simeventsconfig(bdroot,'des');

A message indicates that the simulation settings for this particular model have changed.

Building a Simple Discrete-Event Model

Results of the Simulation

When the simulation runs, the Signal Scope block opens a window containing a plo t. The horizontal axis represents the times at which entities depart from the server, while the vertical axis represents the total number of entities that have departed fro m the server.

After an en output si and highl observat

• Until T=

second f

• Starti

becaus atime. one sec

gnal at the #d port. The updated values are reflected in the plot

ighted with plotting markers. From the plot, you can make these

ions:

ng at T=1, the plot is a stairstep plot. The stairs have height 1

e the server proce sses one entity at a time, so entities depart one at

tity departs from the Single Server block, the block updates its

1, no entities depart from the server. This is because it takes one

or the server to process the first entity.

Thestairshavewidthequaltotheconstant service time, which is

ond.

2-13

2 Building Simple Mode ls with SimEvents

Software

Exploring a Simulation Using the Debugger and Plots

In this section...

“Exploring the D/D/1 System Using the SimEvents Debug ge r” on page 2-14

“Exploring the D/D/1 System Using Plots” on page 2-17

“Information About Race Conditions and Random Times” on page 2-25

Exploring the D/D/1 System Using the SimEvents Debugger

The plot in “Running the Simulation” on page 2-12 indicates how many entities have departed from the server, but does not address the following question: Is any entity still in the server at the conclusion of the simulation? To answer the question, you can use the SimEvents debugger, as described in this section. Using the debugger involves running the simulation in a special debugging mode that lets y ou suspend a simulation at each step or breakpoint and query simulation behavior. U sing the debugger does not require you to change the model. The topics in this section are as follows:

2-14

• “Starting the Debugger” on page 2-14

• “Running the Simulation” on page 2-15

• “Querying the Server Block” on page 2-15

• “Ending the Simulation” on page 2-16

• “For Further Information” on page 2-16

Starting the Debugger

To open a completed version of the example model for this tutorial, enter

simeventsdocex('doc_dd1') intheMATLABCommandWindow. Savethe

model in your working folder as

To start simulating the current system in debugging mode, enter this command at the MATLAB command prompt:

sedebug(bdroot)

dd1.mdl.

ExploringaSimulationUsingtheDebuggerandPlots

The output in the MATLAB Command W indow indicates that the debugger is active. The output also includes hyperlinks to information sources.

*** SimEvents Debugger ***

Functions | Help | Watch Video Tutorial

%==============================================================================%

Initializing Model dd1

sedebug>>

The sedebug>> notation is the debugger prom pt, where you enter commands.

Running the Simulation

The simulation has initialized but does not proceed. In debugging mode, you indicate to the debugger when to proceed through the simulation and how far to proceed before returning control to you. The purpose of this example is to find out whether an entity is in the server when the simulation ends. To continue the simulation until it ends, enter this command at the prompt:

sedebug>>

cont

The Command Window displays a long series of messages that indicate what is happening during the simulation. The end of the output indicates that the debugger has suspended the simulation just before the end:

Hit built-in breakpoint for the end of simulation.

Use 'cont' to end the simulation or any other function to inspect final states of the system.

%==============================================================================%

Terminating Model dd1

To understand the long series of messages, see “The Debugger Environment” online or the debugger resources listed in “For Further Information” on page 2-16.

Querying the Server Block

The debugger has suspended the simulation just before the end and the

sedebug>> prompt indicates that you ca n still enter debugging commands.

2-15

2 Building Simple Mode ls with SimEvents

(p y )

In this wa y, you have an oppo rtunity to inspect the final states of b locks or other aspects of the simulation. To get information about the Single Server block, enter this command:

blkinfo('dd1/Single Server')

The output shows the s tate of the Single Server block at the current time, T=10. The last two rows of the output represent a table that lists entities in theblock. Thetablehasonerowbecause the server is currently storing one entity. The entity has a unique identifier, This output affirmatively answers the question of whether an entity is in the server when the simulation ends.

Single Server Current State T = 10.000000000000000 Block (blk4): Single Server

Entities (Capacity = 1):

Pos ID Status Event EventTime

One entity is in service

Pos ID Status Event EventTime

1 en11 In Service ev33 11

Table of entities in the block

Software

en11, and is currently in service.

2-16

Ending the Simulation

The simulation is still suspended just before the end. To proceed, e nter this command:

cont

The simulation ends, the debugging session ends, and the MATLAB command prompt returns.

For Further Information

For additional information about the SimEvents debugger, see these resources.

ExploringaSimulationUsingtheDebuggerandPlots

Topic Descriptio n

“Building a Simple Hybrid Model” on page 2-26, specifically the section, “Confirming Event-Based Behavior Using the SimEvents Debugger” on page 2-31

A video tutorial on the Web, in two parts:

• Basic Single Stepping and Querying

• Breakpoints and Advanced Querying

Debugger function list online List of functions related to debugging

“Overview of the SimEvents Debugger” online Overview of debugging and links to other

An example that illustrates single-stepping, which is another important debugger feature

Introductions to a variety of debugger features

debugging topics

Exploring the D/D/1 System Using Plots

The dd1 model t hat you created in “Building a Sim ple Discrete-Event Model” on page 2-2 plots the number of entities that depart from the server. This section modifies the model to plot other quantities that can reveal aspects of the simulation. The topics are as follows:

• “Enabling the Queue-Length Signal” on page 2-17

• “Plotting the Queue-Length Signal” on page 2-18

• “Simulatin g with Different Interg eneration Times” on page 2-18

• “Viewing Waiting Times and Utilizati on ” on page 2- 21

• “Observations from Plots” on page 2-23

To open a completed version of the example model for this tutorial, enter

simeventsdocex('doc_dd1') in the MATLAB Command Window. Before

modifying the model, save it with a different file name.

Enabling the Queue-Length Signal

The FIFO Queue block can report the queue length, that is, the number of entities it stores at a given time during the simulation. To configure the FIFO Queue block to report its queue length, do the following:

2-17

2 Building Simple Mode ls with SimEvents

1 Double-click the FIFO Queue block to open its dialog box. Click the

Statistics tab to view parameters related to the statistical reporting of the block.

2 Set the Number of entities in queue parameter to On and click OK.This

causes the block to have a signal output port for the queue-length signal. The port label is #n.

Plotting the Queue-Length Signal

The model already contains a Signal Scope block for plotting the entity count signal. To add another Signal Scope block for plotting the queue-length signal (enabled above), follow these steps:

1 In the main SimEvents library window, double-click the SimEvents Sinks

icon to open the SimEvents Sinks library.

2 Drag the Signal Scope block from the library into the model window. The

block automatically assumes a unique block name, Signal Scope1, to avoid a conflict with the existing Signal Scope block in the m odel.

Software

2-18

3 Connect the #n signal output port of the FIFO Queue block to the in signal

input port of the Signal Scope1 block by dragging the mouse pointer from one port to the other. The model now looks like the following figure.

Simulating with Different Intergeneration Times

By changing the intergeneration time (that is, the reciprocal of the entity arrival rate) in the Time-Based Entity Generator block, you can see when entities accumulate in the queue. Try this procedure:

Note If you skipped the earlier model-building steps, you can open a completed version of the model for this section by entering

simeventsdocex('doc_dd1_blockage') in the MATLAB Command Window.

1 Double-click the Time-Based Entity Generator block to open its dialog box,

set the Period parameter to arrive somewhat faster than the Single Server block can process them. As a result, the queue is not always empty.

2 Save and run the simulation. The plot whose title ba r is labeled Signal

Scope1 represents the queue length. The figure below explains some of the points on the plot. The vertical range on the plot has been modified to fit the data better.

Entity arrives and stays in queue

ExploringaSimulationUsingtheDebuggerandPlots

0.85,andclickOK.Thiscausesentitiesto

First entity departs from queue immediately upon arriving

Entity departs from queue, which becomes empty

One entity departs from queue.

One entity remains in queue.

3 Reopen the Time-Based Entity Gene rator block’s dialog bo x and set Period

0.3.

2-19

2 Building Simple Mode ls with SimEvents

4 Run the simulation again. Now the en tities arrive much faster than the

server can process them. You can make these observations from the plot:

• Every 0.3 s, the queue length increases because a new entity arrives.

• Every 1 s, the queue length decreases because the server becomes empty

and accepts an entity from the queue.

• Every 3 s, the queue length increases and then decreases in the same

time instant. The plot shows two markers at T =3,6,and9.

Software

2-20

5 Reopen the Time-Based Entity Generator block’s dialog box and set Period

1.1.

6 Run the s

server’ depart zero fo

imulation again. Now the entities arrive more slowly than the

s service rate, so every entity thatarrivesatthequeueisableto

inthesametimeinstant. Thequeuelengthisnevergreaterthan

r a positive amount of time.

ExploringaSimulationUsingtheDebuggerandPlots

ViewingWaitingTimesandUtilization

The queue length is an example of a statistic that quantifies a state at a particular instant. Other statistics, such as a ve r ag e waiting time and server utilization, summarize behavior between T=0 and the current time. To modify the model so that you can view the average waiting time of entities in the queue and server, as well as the proportion of time that the server spends storing a n entity, use the following procedure:

Note To skip the model-building steps and open a completed version of the model for this section, enter MATLAB Command Window. Then skip to step 8 on page 2-22 to run the simulation.

1 Double-click the FIFO Queue block to open its dialog box. Click the

Statistics tab, set the Average wait parameter to causes the block to have a signal output p ort for the signal representing the average duration that entities wait in the queue. The port label is w.

simeventsdocex('doc_dd1_wait_util') in the

On,andclickOK.This

2 Double-click the Single Server block to open its dialog box. Click the

Statistics tab, set both the Average wait and Utilization parameters to

On,andclickOK. This causes the block to have a signal output port labeled

w for the signal representing the average duration that entities wait in the

server, and a signal output port labeled util for the signal representing the proportion of time that the server spends storing an entity.

3 Copy the Signal Scope1 block and paste it into the model window.

Note If you modified the plot corresponding to the Signal Scope1 block,

then one or more parameters in its dialog bo x might be different from the default values. Copying a block also copies p arameter values.

4 Double-click the new copy to open its dialog box.

5 Set Plot type to Continuous and click OK. For summary statistics like

average waiting time and utilization, a continuous-style plot is more appropriate than a stairstep plot. Note that the

Continuous option refers

2-21

2 Building Simple Mode ls with SimEvents

to the appearance of the plot and does not change the signal itself to make it continuous-time.

6 Copy the Signal Scope2 block that you just modified and paste it into the

modelwindowtwice. Younowhavefivescopeblocks.

Each copy assumes a unique name. If you want to make the model and plots easier to read, you can click the names underneath each scope block andrenametheblocktouseadescriptivenamelikeQueueWaitingTime, for example.

7 Connect the util signal output port and the two w signal output ports to

the in signal input ports of the unconnected scope blocks by dragging the mouse pointer from port to port. The model now looks like the following figure. Save the model.

Software

2-22

8 Run the simulation with different values of the Period parameter in the

Time-Based Entity Generator block, as described in “Simulating with Different Intergeneration Times” on page 2-18. Look at the plots to see how they change if you set the intergeneration time to

0.3 or 1.1, for example.

ExploringaSimulationUsingtheDebuggerandPlots

Observations from Plots

• The average waiting time in the server does not change after the first

departure from the server because the service time is fixed for all departed entities. The average waiting time statistic does not include partial waiting times for entities that are in the server but have not yet departed.

• The utilization of the server is nondecreasing if the intergeneration time is

small (such as the first entity.

0.3) because the server is constantly busy once it receives

The utilization m ight decrease if the intergeneration time is larger than the service time (such as

1.5) b ecause the serv er has idle periods between

entities.

2-23

2 Building Simple Mode ls with SimEvents

Software

• The average wa

if the interg longer and lo

iting time in the queue increases throughout the simulation

eneration time is small (such as

0.3) because the queue gets

nger.

The average waiting time in the queue is zero if the intergeneration time is larger than the service time (such as

1.1) because every entity that arrives

at the queue is able to depart immediately.

2-24

ExploringaSimulationUsingtheDebuggerandPlots

Information About Race Conditions and Random Times

Other examples m odify this one by varying the processing sequence for simultaneous events or by making the intergeneration times and/or service times random. The modified examples are:

• “Example: Using Random Intergeneration Times in a Queuing System”

on page 3-5

• “Example: Using Random Service Times in a Queuing System” on page 4-7

• Event Priorities demo

2-25

2 Building Simple Mode ls with SimEvents

Software

Building a Simple Hybrid Model

In this section...

“Overview of the Example” on page 2-26

“Opening a Time-Based Simulink Demo” on page 2-27

“Adding Event-Based Behavior” on page 2-27

“Running the Hybrid F-14 Simulation” on page 2-31

“Confirming Event-Based Behavior Using the SimEvents Debugger” on page 2-31

“Visualizing the Sampling and Latency” on page 2-37

“Event-Based and Time-Based Dynamics in the Simulation” on page 2-39

“Modifying the Model to Drop Some Messages” on page 2-39

Overview of the Example

This section describes how to modify a time-based model by ad d ing some discrete-event behavior. The original demo is a model of a flight controller in an aircraft. The modifications are a first step toward simulating a remote flight controller for the same aircraft. The aircraft dynamics are unchanged, but the controller and the aircraft (plant) are separated. A simple way to model a separation is a time delay, which is what this example does. A variation on the example also complicates the interaction between controller and aircraft by modeling occasional transmission failures.

2-26

Using the example model, this section shows you how to:

• Attach data from time-based dynamics to entities whose timing is

independent of the time-based dynamics

• Useanentity’sdepartureeventtocausetheupdateofasignalthat

influences time-based dynamics

• Create a simple model of a hybrid system and then vary it to explore other

behaviors

BuildingaSimpleHybridModel

Note More realistic ways to model a remote-control system might involve communication over a shared network, where the time delays and transmission failures might depend on other network traffic. The

f14_control_over_network demo shows a more complicated model of a

remote flight controller.

Opening a Time-Based Simulink Demo

To open the time-based F-14 demo, enter

sldemo_f14

in the MATLAB Command Window. The model simulates the pilot’s stick input with a square wave. The system outputs are the aircraft angle of a ttack and the G forces experienced by the pilot. A model scope displays the input and output signals. The Controller block connects to other components in the model, namely, the stick input, the q and σ signals from the aircraft dynamics model, and the actuator model.

Run the simulation by choo sing Simulation > Start from the model window’s menu. You can view the results graphically in the model scope.

Adding Event-Based Behavior

This section describes modifying the sldemo_f14 model by inserting several SimEvents blocks between the Controller and Actuator Model blocks. The result looks like the following figures, where the SimEvents blocks are contained in a subsystem for visual neatness.

2-27

2 Building Simple Mode ls with SimEvents

Part of Top Level of Modified Model

Software

Subsystem

Contents

The follo for build

• “Behavi

• “How to B

To skip model, Comman

wing topics describe the subsystem and then provide instructions

ing it yourself:

or of the Subsystem” on page 2-28

uild the Subsystem” on page 2-29

the model-building steps and open a completed version of the example

enter

simeventsdocex('doc_sldemo_f14_des') in the MATLAB

dWindow.

Behavior of the Subsystem

The Si comm and c

• Data

• Per

mEvents blocks are an abstract representation of a simple

unication link that samples the information from the remote controller

onveys that information to the aircraft:

from the controller is related to the subsystem via the subsystem’s

block.

In1

iodically, the Event-Based Entity Generator block creates an entity,

ch serves as a vehicle for the data in this communication system

whi

ween the controller and the aircraft.

bet

2-28

BuildingaSimpleHybridModel

• The Set Attribute block attaches the data to the entity.

• TheInfiniteServerblockmodelsthelatencyinthecommunicationsystem

by delaying each data -containing entity.

• The Get Attribute block models the reconstruction of data at the receiver.

This block connects to the subsystem’s Out1 block so that the actuator block at the top level of the model can access the data.

• The Entity Sin k block absorbs entities after they are no longer n ee ded.

Note This subsystem models comm unication from the controller to the

actuator, but does not address the feedback path from the aircraft back to the controller. This model is only a first step toward modeling a remote controller. Next steps might involve modeling the communication in the feedback path and replacing the Infinite Server block with a more realistic representation of the communication link.

How to Build the Subsystem

To modify the sldemo_f14 model to create this example, follow these steps:

1 Open the S imulink and Si mEvents libraries, referring to instructions in

“Opening a Model and Libraries” on page 2-3 if you are new. Also, open the

sldemo_f14 model by entering its name in the MATLAB Command

Window if you have not already done so.

2 Use File > Save As in the model window to save the model to your working

folder as

3 Enter simeventsconfig('sldemo_f14_des','hybrid') in the MATLAB

Command Window to make some model settings more appropriate for a simulation that includes discrete-event behavior.

4 From the Simulink Ports & Subsystems library, drag the Subsystem block

into the model window and insert it between the Controller and Actuato r Model blocks. The model window should look like Part of Top Level of Modified Model on page 2-28.

sldemo_f14_des.mdl.

2-29

2 Building Simple Mode ls with SimEvents

5 Double-click the newly inserted Subsystem block to open a subsystem

window. The rest of this procedure builds the subsystem in this window.

6 From the Sources library in the Simulink library set, drag the Digital Clock

block into the subsystem window.

7 Double-click the Digital Clock block to open its dialog b ox, set Sample

time to

8 From the E ntity Generators sublibrary of the Generators library of the

SimEvents library set, drag the Event-Based Entity Generator block into the subsystem window.

9 Double-click the Event-Based Entity Generator block to open its dialog

box, set Generate entities upon to and click OK.

10 From the Signal Generators sublibrary of the Generators library, drag the

Event-Based Random Number block into the subsystem window.

Software

0.1,andclickOK.

Sample time hit from port ts,

2-30

11 Double-click the Event-Based Random Number block to open its dialog box.

Set Distribution to

0.06,andclickOK.

12 From the Attributes library, drag the Set Attribute and Get Attribute

Uniform,setMinimum to 0.01,setMaximum to

blocks into the subsystem window.

13 Double-click the Set Attribute block to open its dialog box. The Set

Attribute tab contains a grid. On the first row, set Name to Value From to

Signal port,andclickOK. The block acquires a signal

Data,set

input port labeled A1.

14 Double-click the Get Attribute block to open its dialog box. The Get

Attribute tab contains a grid. On the first row, set Name to

Data and click

OK. The block has a signal output port labeled A1.

15 From the Servers library, drag the Infinite Server block in to the sub system

window.

16 Double-click the Infinite Server block to open its dialog box. Set Service

time from to

Signal port t and click OK. The block acquires a signal

inputportlabeledt.

BuildingaSimpleHybridModel

17 From the SimEvents Sinks library, drag the Entity Sink block into the

subsystem window.

18 ConnecttheblocksasshowninSubsystemContentsonpage2-28.

19 Save the model to preserve your modifications.

Running the Hybrid F-14 Simulation

Run the sldemo_f14_des simulation by choosing Simulation > Start from the model window’s menu. By comparing the plots in the model scope with the plots in the original time-ba s ed discrete-event behavior affects the simulation. The latency in the control loop (that is, the delay be tw een the controller and the actuator) degrades the behavior somewhat.

Changing the Latency

One way to experiment with the simulation is to change the latency in the control loop (that is, the delay between the controller and the actuator) and run the simulation again. Here are some suggestions:

sldemo_f14 model, you can see how the

• In the Event-Based Random Number block, set Maximum to

• In the Event-Based Random Number block, set Distribution to

Minimum to

• Replace the Event-Based Random Number block with a Step block from the

Simulink Sources library. In the latter block’s dia log box , set Step time to

30, Initial value to 0.03, Final value to 0.07,andSample time to 1.

0.01,andsetMaximum to 0.06.

0.1.

Beta,set

Confirming Event-Based Behavior Using the SimEvents Debugger

You can use the SimEvents debugger to confirm the behavior in the subsystem of the introduction in “Exploring the D/D/1 System Using the SimEvents Debugger” on page 2-14. The topics a re as follows:

• “Starting the Debugger” on page 2-32

• “Stepping Through the Simulation” on page 2-32

sldemo_f14_des model. This section expands upon the debugger

2-31

2 Building Simple Mode ls with SimEvents

• “Exiting the Debugging Session” on page 2-36

• “For Further Information” on page 2-36

To open a completed version of the example model for this tutorial, enter

simeventsdocex('doc_sldemo_f14_des') in the MATLAB Command

Window. Save the model in your working folder as

Starting the Debugger

To start running the sldemo_f14_des simulation in debugging mode, enter this command at the MATLAB command prompt:

sedebug('sldemo_f14_des')

Stepping Through the Simulation

The simulation has initialized but does not proceed. The purpose of this example is to confirm that the event-based behavior matches what “Behavior of the Subsystem” on page 2-28 describes. Specifically, the example demonstrates how to confirm this by proceeding step by step u sing the function repeatedly and studying what happens.

Software

sldemo_f14_des.mdl.

step

2-32

In the Sim Events debugger, proceeding step by step means suspending the simulation before or after each o ccurrence that is part of the event-based behavior of the simulation. A step might or might not be later in time than the previous step because many occurrences relevant to debugging might occur simultaneously in the simulation. A step does not reflect time-based behavior, except where time-based behavior directly affects event-based behavior. Steps might not be in the same sequence that you see in the topology of the block diagram, even if the topology of the block diagram is linear, because the topology does not solely determine the event-based behavior of the simulation. For more information on the granularity of steps in the SimEvents debugger, see “The Debugger Environment” online.

To proceed with this simulation, enter the following command several times in succession at the

step

sedebug>> prompt:

Several step commands illustrate the occurrences that make up the event-based behavior of the simulation.

BuildingaSimpleHybridModel

Step

Description and Command Window Output

An event-based block, the Event-Based Entity Generator block in the subsystem, has sensed a relevant update in the signal that connects to the block’s input port.

%==============================================================================%

Detected Sample-Time Hit Time = 0.000000000000000

: Block = Subsystem/ Event-Based Entity Generator

The Event-Based Entity Generator block is about to react to the u pdate it has detected. The indentation of the output with respect to the first output indicates that this operation is dependent on the first one. This particular response is to schedule an event that generates an entity.

%..........................................................................%

Scheduling EntityGeneration Event (ev1)

: EventTime = 0.00000000 0000000 (Now)

: Priority = SYS1

: Block = Subsystem/Event-Based Entity Generator

The event calendar is about to start executing the entity generation event.

%==============================================================================%

Executing EntityGeneration Event (ev1) Time = 0.000000000000000

: Entity = <none> Priority = SYS1

: Block = Subsystem/Event-Based Entity Generator

The Event-Based Entity Generator block is about to generate an entity.

%..........................................................................%

Generating Entity (en1)

: Block = Subsystem/Even t-Based Entity Generator

To this point, the steps illustrate the part of “Behavior of the Subsystem” on page 2-28 stating that the Event-Based Entity Generator block periodically creates an entity. While the periodicity is not evident from the behavior at T=0, you can infer periodicity from the discrete sample time of the Digital Clock block that connects to the Event-Based Entity Generator block.

2-33

2 Building Simple Mode ls with SimEvents

Software

Step

Description and Command Window Output

The generated entity is about to advance from the entity generator to the next block, a Set Attribute block.

%..........................................................................%

Entity Advancing (en1)

: From = Subsystem/Event -Based Entity Generator

: To = Subsystem/Set Attribute

The Set Attribute block is about to attach data to the entity, as “Behavior of the Subsystem” on page 2-28 describes. The value of

Data,whichis0, comes from the

controller.

%..........................................................................%

Setting Attribute on Ent ity (en1)

: Data = 0

: Block = Subsystem/Set Attribute

The entity, with attached data, is about to advance to the next block, an Infinite Server block.

%..........................................................................%

Entity Advancing (en1)

: From = Subsystem/Set Attribute

: To = Subsystem/Infinite Server

The Infinite Server block is about to schedule an event representing the completion of service on the arriving entity. The scheduled time of the event is random.

2-34

%..........................................................................%

Scheduling ServiceCompletion Event (ev2)

: EventTime = 0.05538394 8677907

: Priority = 500

: Entity = en1

: Block = Subsystem/Infinite Server

BuildingaSimpleHybridModel

Step

Description and Command Window Output

The event calendar is about to start executing the service completion event.

%==============================================================================%

Executing ServiceCompletion Event (ev2) Time = 0.055383948677907

: Entity = en1 Priority = 500

: Block = Subsystem/Infinite Server

Together, the previous step and this step illustrate the part of “Behavior of the Subsystem” on page 2-28 stating that the Infinite Server block models the latency in the communication system by delaying each data-containing entity. To see the delay, notice that the

Time = part of the C ommand Window output indicates T=0 in step 3

and T>0.055 in this step.

The entity is about to advance from the server to the next block, a Get Attribute block.

%..........................................................................%

Entity Advancing (en1)

: From = Subsystem/Infin ite Server

: To = Subsystem/Get Attribute

Although it is not apparent from the message, the Get Attribute block models the reconstruction of data at the receiver.

The entity is about to advance to the Entity Sink block.

%..........................................................................%

Entity Advancing (en1)

: From = Subsystem/Get Attribute

: To = Subsystem/Entity Sink

2-35

2 Building Simple Mode ls with SimEvents

Software

Step

Description and Command Window Output

The Entity Sink block is about to destroy the entity because it is no longer needed.

%..........................................................................%

Destroying Entity (en1)

: Block = Subsystem/Enti ty Sink

The behavior cycle repeats, upon the next update of the time-based signal from the Digital Clock block to the Event-Based Entity Generator block. The next update occurs at T=0.1.

%==============================================================================%

Detected Sample-Time Hit Time = 0.100000000000000

: Block = Subsystem/ Event-Based Entity Generator

Exiting the Debugging Session

Exit the debugging session by entering this command at the sedebug>> prompt:

sedb.quit

The simulation ends prematurely, the debugging session ends, and the MATLAB command prompt returns.

For Further Information

For a dditional information about the SimEvents debugger, see these online resources.

Topic Descriptio n

A video tutorial on the Web, in two parts:

Introductions to a variety of debugger features

• Basic Single Stepping and Querying

• Breakpoints and Advanced Querying

Debugger function list List of functions related to debugging

“Overview of the SimEvents Debugger” Overview of debugging and links to other

debugging topics

2-36

BuildingaSimpleHybridModel

Visualizing the

By sending relev and examining it updates signal data sent from t

To send the con compare the si

Note If you sk open a compl

simeventsd

s during the simulation. In particular, you can confirm that the

he controller to the actuator is, in fact, delayed.

troller’s output and actuator’s input to the workspace and

gnals after the simulation, follow these steps:

ipped the earlier model-building steps, you can

eted version of the model for this section by entering

ocex('doc_sldemo_f14_des')

Sampling and Latency

ant data from

after the simulation, you can determine when the a pplication

sldemo_f14_des to the MATLAB workspace

in the MATLAB Command

Window.

1 From the Si

block int

2 Double-click one To Workspace block to open its dialog box, set Variable

name to

Structure With Time,andclickOK.

3 Double-click the other To Workspace block to open its dialog box, set

Variable name to format to

mulink Sinks library, drag two copies of the To W orkspace

o the top-level model window.

tx,setLimit data points to last to Inf,setSave format to

rx,setLimit data points to last to Inf,setSave

Structure With Time,andclickOK.

4 Connec

discr

5 Run the simulation.

t the To Workspace blocks to the input and output signals to the

ete e ve nt subsystem using branch lines, as shown.

2-37

2 Building Simple Mode ls with SimEvents

6 Enter the following in the MATLAB Command Window:

n = 100; % Plot first 100 values plot(tx.time(1:n), tx.signals.values(1:n),'b.-',...

legend('Transmitted','Received')

The resulting plot exhibits the data sampling and the delay in the discrete event subsystem. The data transmitted by the controller appears with blue dots, while the data received at the actuator appears with red x’s. Notice that the data transmitted at T=0.1 is received slightly later and then held constant until the data transmitted at T=0.2 is received. The time points 0, 0.1, 0.2, 0.3, and so on, are significant because the subsystem generates an entity at these times and it is the entities that carry data from the controller to the actuator.

Software

rx.time(1:n), rx.signals.values(1:n),'rx-');

2-38

Transmitted and Received Data

BuildingaSimpleHybridModel

Event-Based and Simulation

In the sldemo_f1 with the eventthis simulati ODE solver sim event-based d service compl representin unrelated to differentia

In this mode and output o block upda Attribute arrival at and expla and Recei of the tim transmi

When an e block, w the sub upon th

l equations of the aircraft.

block, which is event-based, uses the value upon the next entity

the block. Such entity arrivals occur at times 0, 0.1, 0.2, and so on, in why the value of each received data point in the plot, Transmitted ved Data on page 2-38, is the value of the transmitted signal at one es 0, 0.1, 0.2, and so on. The received data does not reflect values

tted at other times.

ntity c o mpletes its service, the entity arrives at the Get Attribute

hich is event-based. This block updates the value at the output port of

system. The Actuator Model block, which is time-based, uses the value

e next time step determined by the ODE solver.

4_des

based dynamics of the communication link. When you run

on, the ODE solver and an event calendar both play a role. The

ulates the time-based dynamics of the aircraft. Solving the

ynamics entails scheduling and processing events, such as

etion and entity generation, on the event calendar. The events

g service completion and entity generation are asynchronous and

the time-based simulation steps used in solving the ordinary

l, time-based blocks interact with event-based blocks at the input ftheSubsystemblock. Ateachofits sample times, the Controller

tes the value at the input port of the Subsystem block. The Set

Time-Based Dynamics in the

model, the time-based dynamics of the aircraft coexist

rn more about the event calendar and the ODE solver, see “Working

To lea with E docum

Modi

You c rem com is d nex

vents” online, and “Simulating Dynamic Systems” in the Simulink

entation.

fying the Model to Drop Som e Messages

an vary the implementation of the ote communication from the controller to the actuator by having the munication link drop messages with small probability. When a message

ropped, the actuator continues to use the last received message, until the ttimeitgetsanupdatedmessage.

sldemo_f14_des model’s

2-39

2 Building Simple Mode ls with SimEvents

Software

The modified portion of the subsystem looks like the following f ig ure.

Subsystem Modified to Drop Some Messages

The following topics describe the subsystem mo difications and then provide instructions for building them yourself:

2-40

• “Behavior of the Modifie d Subsystem” on page 2-40

• “How to Modify the Subsystem” on page 2-41

To skip the model-building steps andopenacompletedversionofthe example model, enter

simeventsdocex('doc_sldemo_f14_des_drop') in the

MATLAB Command Window.

Behavior of the Modified Subsystem

In the original subsystem, every entity (with data attached to it) reaches the Get Attribute block, which sends the data out of the subsystem and to the actuator. In the modified subsystem,

• TheSetAttributeblockassignsnotonlythe

DropMessage attribute. The value of the DropMessage attribute is 1 with

probability 0.95 and 2 with probability 0.05. The values 1 and 2 refer to the entity output ports on the Output Switch block.

• Entities advance to either the Get Attribute block or a new Entity Sink

block. The Output Switch block uses the

Data attribute but also a new

DropMessage attribute of each

BuildingaSimpleHybridModel

entity to determine which path that entity takes. Because of the probability distribution, 95% of entities advance to the Get Attribute block and the remaining 5% of entities are absorbed by the Entity Sink block.

• When an entity reaches the Get Attribute block, the attached data

successfully reaches the actuator. When an entity uses the other path, the attached data is discarded and the actuator continues to see the data that it received from the last entity that reached the Get Attribute block.

The actuator continues to see previous data because the signal holds a value until a block updates it. When an entity is absorbed without reaching the Get Attribute block, the block does not update the signal that goes to the subsystem’s Out1 block. Therefore, the value of that signal is whatever value was attached to the last entity that reached the Get Attribute block during the simulation.

This is also why the actuator sees a constant signal between successive entities, that is, between successive samples by the communication link. Although the controller issues a continuous-time signal, the com munication link between the controller and actuator creates a new data-carrying entity according to a discrete-time schedule. In other words, the subsystem samples the data from the controller before transmitting it to the actuator.

How to Modify the Subsystem

To modify the subsystem in the sldemo_f14_des model to create this variation, follow these steps:

Note If you skipped the earlier model-building steps, you can open a completed version of the model for this section by entering

simeventsdocex('doc_sldemo_f14_des') in the MATLAB Command

Window.

1 From the Routing library, drag the Output Switch block into the subsystem

window.

2 Double-click the Output Switch block to open its dialog box. Set Number

of entity output ports to

2,setSwitching criterion to From attribute,

2-41

2 Building Simple Mode ls with SimEvents

set Attribute name to DropMessage,andclickOK . The block retains two entity output ports, labeled OUT1 and OUT2.

3 Create copies of the Event-Based Random Number and Entity Sink blocks,

which are already in the subsystem. You can create a copy by dragging the b lock with the right mouse button, or by using Edit > Copy followed by Edit > Paste.

4 Double-click the newly copied Event-Based Random Number block (labeled

Event-Based Random Number1) to open its dialog box. Set Distribution to

Arbitrary discrete,setValue vector to [1 2],setProbability vector

[0.95 0.05],setInitial seed to an odd five-digit number different from

the one used in the other instance of this block, and click OK.

5 Double-click the Set Attribute blo ck to open its dialog box. On the Set

Attribute tab, click the Add button to create a new row in the table. In the

new row, set Name to click OK. The block acquires a signal input port labeled A2.

6 Delete the connection between the Infinite Server and Get Attribute blocks.

Software

DropMessage,setValue From to Signal port,and

2-42

7 Connect the blocks as shown in Subsystem Modified to Drop Some

Messages on page 2-40.

8 Use File > Save As in the model window to save the model to your working

folder as

sldemo_f14_des_drop.mdl.

Reviewing Key Concepts in SimEvents®Software

Reviewing Key Concepts in SimEvents Software

In this section...

“Meaning of Entities in Different Applications” on page 2-43

“Entity Ports and Paths” on page 2-43

“Data and Signals” on page 2-44

Meaning of Entities in Different Applications

An entity represents an item of interes t in a discrete-even t simulation. The meaning of an entity depends on what you are modeling. In this chapter, examples use entities to represent abstract customers in a queuing system and instructions from a remote controller to an actuator on the system being controlled.

Entities do not have a graphical depiction in the model window the way blocks, ports, and connection lines do.

Entity Ports and Paths

An entity output port provides a way for an entity to depart from a block . An entityinputportprovidesawayfor an entity to arrive at a block.

A connection line indicates a path along which an entity can potentially advance. However, the connection l ine does not imply that any entities actually advance along that path during a simulation. For a given entity path and a given time instant during the simulation, any of the following could be true:

• No entity is trying to advance along that path.

• An entity has tried and failed to advance along that path. For some

blocks, it is normal for an entity input port to be unavailable under certain conditions. This unavailability causes an entity to fail in its attempt to advance along that path, even though the path is intact (that is, even though the ports are connected). An entity that tries and fails to advance is called a pending entity.

2-43

2 Building Simple Mode ls with SimEvents

• An entity successfully advances along that path. This occurs only at a

discrete set of times during a simulation.

Note The simulation could also have one or more times at which one or more entities successfully advance along a given entity path and, simultaneously, one or more different entities try and fail to advance along that same entity path. F or example, an entity departs from a queue and, simultaneously, the next entity in the queue tries and fails to depart.

Data and Signals

In time-based dynamics, signals express the outputs of dynamic systems represented by blocks. Event-based blocks can also read and produce signals. One way to learn about signals is to plot them; the discussion in “Exploring the D/D/1 System Using Plots” on page 2 -17 i s about visualizing s ignals that reflect behavior of event-based blocks.

Time-based and event-based dynamics can interact via the data shared by both types of blocks. Attributes of entities provide a way for entities to carry data w ith them. The subsystem in “Adding Event-Based Behavior” on page 2-27 illustrates the use of attributes in the interaction between time-based and event-based dynamics.

Software

2-44

Although signals are common to both time-based and event-based dynamics, event-based dynamics can produce signals that have slightly different characteristics. For more information, see “Working with Signals” online.

Creating Entities Using Intergeneration Times

• “Role of Entities in SimEvents Models” on page 3-2

• “Introduction to the Time-Based Entity Generator” on page 3-3

• “Specifying the Distribution of Intergeneration Times” on page 3-4

• “Using Intergeneration Times from a Signal” on page 3-6

3 Creating Entities Using Intergeneration Times

Role of Entities in SimEvents Models

In this section...

“Creating Entities in a Model” on page 3-2

“Varying the Interpretation of Entities” on page 3-2

“Data and Entities” on page 3-2

Creating Entities in a Model

As described in “What Is an Entity?” on page 1-8, entities are discrete items of interest in a discrete-event simulation. You determine what an entity signifies, based on what you are modeling.

SimEvents models typically contain at least one source block that generates entities. Other SimEvents blocks in the model process the entities that the source block generates. One source block that generates entities is the Time-Based Entity Generator block, described in “Introduction to the Time-Based Entity Generator” on page 3-3.

3-2

Varying the Interpretation of Entities

A single model can use entities to represent different kinds of items. For example, if you are modeling a factory that processes two different kinds of parts, then you can

• Use two Time-Based Entity Generator blocks to create the two kinds of

parts.

• Use one Time-Based Entity Generator block and subsequently assign an

attribute to indicate what kind of part each entity represents.

Data and Entities

You can optionally attach data to entities. Such data is stored in one or more attributes of an entity . You define names and numeric values for attributes. For example, if your entities represent a message that you are transmitting across a communication network, you might assign data called indicates the length of each particular message. You can read or change the values of attributes during the simulation.

length that

Introduction to the Time-Based Entity Generator

The Time-Based Entity Generator block creates entities. You configure the Time-Based En tity Generator block to customize aspects such as

• The intergeneration times between successive entities. The sections below

discusswaysofdoingthis.

• How the block reacts when it is temporarily unable to output entities. To

learn more, see the block’s online reference page.

• The relative priority of entity generation events compared to other kinds of

events that might occur simultaneously. To learn more, see “Processing Sequence for Simultaneous Events” online.

The Time-Based Entity Generator block resides in the Entity Generators sublibrary of the Generators library of the SimEvents library set.

3-3

3 Creating Entities Using Intergeneration Times

Specifying the Distribution of Inter generation Times

In this section...

“Procedure” on page 3-4

“Example: Using Random Interg ener ation Times in a Queuing System” on page 3-5

Procedure

Theintergenerationtimeisthetimeinterval between successive entities that a Time-Based Entity Generator block generates. You can use the block’s dialog box to describe a statistical distribution that governs the intergeneration times. Use this procedure:

1 Set Generate entities with to Intergeneration time from dialog.

2 Choose a statistical distribution by setting the Distribution parameter to

one of these values:

3-4

•

Constant.ThensetthePeriod parameter to the constant

intergeneration time.

•

Uniform.ThensettheMinimum and Maximum parameters to define

the interval over which the distribution is uniform. The uniform distribution has probability density function

⎧ ⎪

fxx()=

• Exponential.ThensettheMean parameter to the mean of the

exponential d istribution. The exponential distribution with mean 1/λ has probability density function

Maximum Minimum

⎨ ⎪

0Otherwise

⎩

λλ

exp=−

⎧

()

⎨ ⎩

−

≥

()

Minimum Maximum

Specifying the Distribution of Intergeneration Times

The random distributions also provide an Initial seed parameter that specifies the seed on wh ich the stream of random numbers is based. Typica ll y, you would use a la rge (for example, five-digit) odd number. For a fixed seed, the random beh av io r is repeatable the next time you run the simulation. Changing the seed changes the stream of random numbers.

Example: Using Random Intergeneration Times in a Queuing System

Open the model that you created in “Building a Simple Discrete-Event Model” on page 2-2 or enter Window to open a prebuilt version of the same model.

By examining the Time-Based Entity Generator block’s Distribution and Period parameters, you can see that the block is configured to use a constant intergeneration time of 1 second. To use a random intergeneration time instead, try these variations and see how they affect the plot that the simulation creates:

simeventsdocex('doc_dd1') in the MATLAB Command

• Set Distribution to

3. The first entity, generated at T=0, appears in the plot at T=1 after its

service is co m plete. The second entity, generated at a random time betwee n T=1 and T=3, appears in the plot between T=2 and T=4.

• Set Distribution to

1.5. The plot probably shows more entities compared to the scenario above

because the range of intergeneration times has the same minimum but a smaller maximum.

• Set Distribution to

called an M/D/1 queuing system, w he re the M stands for Markovian and indicates a Poisson arrival rate. Note that the exponential distribution has n o upper bound, so the time between successive entities could be any positive number.

Uniform,setMinimum to 1,andsetMaximum to

Exponential and set Mean to 0.5.Thissystemis

3-5

3 Creating Entities Using Intergeneration Times

Using Intergeneration Times from a Signal

In this section...

“Procedure” on page 3-6

“Example: Using a Step Function as Intergeneration Time” on page 3-7

“Example: Using an Arbitrary Discrete Distribution as Intergeneration Time” on page 3-9

Procedure

To indicate intergeneratio n times explicitly as values from a signal, use this procedure:

1 Set the Time-Based Entity Generator block’s Generate entities with

parameter to labeled t appears on the block.

Intergeneration time from port t.Asignalinputport

3-6

2 Create a signal whose value at each generation time is the time until the

next entity generation.

For examples of how to create such signals, see

• “Example: Using a Step Function as Intergeneration Time” on page 3-7

• “Example: Using an Arbitrary Discrete Distribution as Intergeneration

Time” on page 3-9.

3 Connect the signal to the signal input port labeled t.

Upon generating each entity, the Time-Based Entity Generator block reads the value of the input signal and uses that value as the time interval until the next entity generation.

Using intergeneration times from a signal might be appropriate if you

• Want to use a statistical distribution that is not directly accessible using

the

Intergeneration time from dialog option, described in “Specifying

the Distribution of Intergeneration Times” on page 3-4.

Using Intergeneration Times from a Sign al

• Want the intergeneration time to depend on the dynamics of other blocks in

your model.

• Have a set of intergeneration times in a MATLAB workspace variable or in

aMAT-file.

Note The block reads the input signal u pon ea c h entity generation, not upon each simulation sample time, so signal values that occur between successive entity generation events have no effect on the entity generation process. For example, if the input signal is

10 from T=9 until the simulation ends, then the value of 1 never becomes an

10 when the simulation starts, 1 at T=1, and

intergeneration time.

Example: Using a Step Function as Intergeneration Time

Open the model that you created in “Building a Simple Discrete-Event Model” on page 2-2, or enter Command Window to open a prebuilt version of the same model. T o specify intergeneration times using a signal, use this procedure:

simeventsdocex('doc_dd1') in th e MATLAB

1 Set the Time-Based Entity Generator block’s Generate entities with

parameter to

Intergeneration time from port t.Asignalinputport

labeled t appears on the block.

2 From the Simulink Sources library, drag a Step block into the model and

connectittothet input port of the Time-Based Entity G enerator block. The model looks like the figure below.

3-7

3 Creating Entities Using Intergeneration Times

3 Set the Step block’s Step time parameter to 2.8, Initial value parameter

1,andFinal value parameter to 2. With these parameters, the block

generates a signal whose value is 1 from T=0 to T=2.8, and whose value is 2 thereafter.

4 Run the simulation. You can see from theplotthattheentitiesdeparting

from the server are initially spaced 1 second apart and later spaced 2 seconds apart.

3-8

The Time-Based Entity Generator block reads intergeneration times from the Step block each time it generates an entity. The table below shows when the Time-Based Entity Generator block generates entitie s and which intergeneration time values it reads in each instance. The table also shows when each entity departs from the server, which you can see from the plot. Although the Step block starts producing the value of 2 at T=2.8, the Time-Based Entity Generator block does not read the new value until the next time it generates an entity, at T=3.

Entity Generation Time

526

Intergeneration Time Until Next Entity Generation

DepartureTimeof Entity from Server

Using Intergeneration Times from a Sign al

Entity Generation Time

Intergeneration Time Until Next Entity

DepartureTimeof Entity from Server

Generation

728

9210

Example: Using an Arbitrary Discrete Distribution as Intergeneration Time

1 Set the Time-Based Entity Generator block’s Generate entities with

parameter to

Intergeneration time from port t.Asignalinputport

labeled t appears on the block.

2 From the Signal Generators sublibrary of the Generators library, drag the

Event-Based Random Number block into the model and connect it to the t input port of the Time-Based Entity Ge ne rato r block. The model looks likethefigurebelow.

simeventsdocex('doc_dd1') in th e MATLAB

3 Set the Event-Based Random Number block’s Distribution parameter

Arbitrary discrete, Value vector parameter to [1 1.5 2],and

Probability vector parameter to

[0.25 0.5 0.25].Withthese

parameters, the block generates intergeneration times Δt such that

3-9

3 Creating Entities Using Intergeneration Times

().

1025

(.).

15 05

().

2025

4 Run the simulation. You can see from theplotthattheentitiesdeparting

from the server are spaced 1, 1.5, or 2 seconds apart. The simulation time in this example is much too short to verify that the random number generator is applying the specified probabilities, however.

3-10

Basic Queues and Servers

• “Role of Queues in SimEvents Models” on page 4-2

• “Role of Servers in SimEvents Models” on page 4-4

• “Using FIFO Queue and Single Server Blocks” on page 4-6

4 Basic Queues and Servers

Role of Queues in SimEvents Models

In this section...

“Behavior and Features of Queues” on page 4-2

“Physical Queues and Logical Queues” on page 4-2

“Accessing Queue Blocks” on page 4-3

Behavior and Features of Queues

In a discrete-event simulation, a queue stores entities for some length of time that cannot be determined in advance. The queue attempts to output entities as soon as it can, but its success depends on whether the next block accepts new entities. An everyday example of a queue is a situation where you stand in a line with other people to wait for someone (a bank teller, a retail cashier, etc.) to address your needs and you cannot determine in advance how long you must wait.

4-2

Distinguishing features of different queues include

• The queue capacity, which is the number of e ntities the queue can store

simultaneously

• The queue discipline, which determines which entity departs first if the

queue stores m ultiple entities

Physical Queues and Logical Queues

In some cases, a queue in a model is similar to an analogous aspect of the real-world system being modeled. This kind of queue is sometimes called a physical queue. For example, you might use a queue to represent a sequence of

• People standing in line

• Airplanes waiting to access a runway

• Messages waiting to be sent

• Parts waiting to be assembled in a factory

• Computer programs waiting to be executed

Role of Queues in SimEvents®Models

In o ther cases, a queue in a model does not arise in an obvious way from the real-world system but instead is included for modeling purposes. This kind of queue is sometimes called a logical queue. For example, you m ight use a queue to provide a temporary storage area for entities that might otherwise ha ve nowhere to go. Such use of a logical queue can prevent deadlocks or simplify the simulation. For example, see “Example of a Logical Queue” on page 4-11.

Accessing Queue Blocks

Queue blocks reside in the Queues library of the SimEvents library set. This chapter focuses on the FIFO Queue block; for more information about other blocks in the library, see “Modeling Queues and Servers” online.

Although queuing theory typically treats a queue-server pair as one component, SimEvents software contains queue blocks and server blocks as distinct components. You ofte n attach a queue block directly to a server block, but you might also want to use the blocks in other ways.

4-3

4 Basic Queues and Servers

Role of Servers in SimEvents Models

In this section...

“Behavior and Features of Servers” on page 4-4

“What Servers Represent” on page 4-5

“Accessing Server Blocks” on page 4-5

Behavior and Features of Servers

In a discrete-event simulation, a server stores entities for some length of time, called the service time, and then attempts to output the entity. During the service period, the block is said to be serving the entity that it stores. An everyday example of a server is a person (a bank teller, a retail cashier, etc.) with w h om you perform a transaction with a projected duration.

The service time for each entity is computed when it arrives, which contrasts with the inherent unknowability of the storage time for entities in queues. If the next block does not accept the arrival of an entity that has completed its service, however, then the server is forced to hold the entity longer.

4-4

Distinguishing features of different servers include

• The number of entities it can serve simultaneously, which could be finite or

infinite

• Characteristics of, or the method of computing, the service times of arriving

entities

• Whether the server permits certain arriving entities to preempt entities

that are already stored in the server

Tip In the absence of preemption, a finite-capacity server does not accept new arrivals when it is already full. You can place a queue before each finite-capacity server, establishing a place for entities to stay while they are waiting for the server to accept them. Otherwise, the waiting entities might be stored in various different locations in the model and the situation might be more difficult for you to predict or analyze.

Role of Servers in Sim Events®Models

What Servers Rep

In some cases, a s real-world syst represent

• A person (such

arriving cust

• Atransmitter

• Amachinetha

• Acomputert

You might us An example o on page 2-26.

erver in a model is similar to an analogous aspect of the

em being modeled. For example, you might use a server to

as a bank teller) who performs a transaction with each

omer

that processes and sends m ess ages

t assembles parts in a factory

hat executes programs

e an infinite-capacity server to represent a delaying mechanism.

fthisisinthesubsystemin“BuildingaSimpleHybridModel”

resent

Servers Inserted for Modeling Purposes

In some ca real-wor modelin whose se aplacef signals “Loops

ses, a server in a model does not arise in an obvious way from the

ld system but instead is included for modeling purposes. A common

g technique involves a delay of duration zero, that is, an infinite server

rvice time is zero, either to break an algebraic loop or to provide

or an entity to reside while a preceding block updates its output

. For details and examples, see “Interleaving of Block Operations” and

in Entity Paths Without Sufficient Storage Capacity” online.

Acces

Serve chapt bloc

sing Server Blocks

r blocks reside in the Servers library of the SimEvents library set. This er focuses on the Single Server block; for m ore information about other

ks in the library, see “Modeling Queues and Servers” online.

4-5

4 Basic Queues and Servers

Using FIFO Queue and Single Server Blocks

In this section...

“Varying the Service Time” on page 4-6

“Constructs Involving Queues and Servers” on page 4-8

“Example of a Logical Queue” on page 4-11

See also the example in “Building a Simple Discrete-Event Model” on page 2-2, which illustrates how to create a queue-server pair and view statistics such as server utilization.

Varying the Ser vice Time

The subsystem described in “Adding Event-Based Behavior” on page 2-27 includes an Infinite Server block that serves each entity for a random amount of time. The random duration is the value of a signal that serves as an input to the Infinite Server block. Similarly, the Single Server block can read the service time from a signal, which enables you to vary the service time for each entity that arrives at the server.

4-6

Some scenarios in which you might use a varying service time are as follows:

• You want the service time to come from a random number generator. In this

case, set the Single Server block’s Servicetimefromparameter to

port t

input signal for the Single Server block. Be aware that some distributions can produce negative numbers, which are not valid service times.

• Youwanttheservicetimetocomefromdataattachedtoeachentity. In

this case, set the Single Server block’s Service time from parameter to

and use the Event-Based Random Number block to generate the

Signal

Using FIFO Queue and Single Server Blocks

Attribute and set Attribute name to the name of the attribute containing

the service time. An example is in the figure below.

To learn more about attaching data to entities, see “Setting Attributes of Entities” online.

• Youwanttheservicetimetoarisefromdynamicsofthesimulation. Inthis

case, set the Single Server block’s Servicetimefromparameter to

port t

andcreateasignalwhosevalueatthetimeanentityarrivesatthe

Signal

server is equal to the desired service time for that entity.

If the signal representing the servicetimeisanevent-basedsignalsuch as the output of a Get Attribute block, ensure that the signal’s updates occur before the entity arrives at the server. For common problems and troubleshooting tips, see “Unexpected Use of Old Value of Signal” online.

Example: Using R andom Service Times in a Queuing System

Open the model that you created in “Building a Simple Discrete-Event Model” on page 2-2, or enter Window to o pen a prebuilt version of thesamemodel. Byexaminingthe Single Server block’s Service time from and Service time parameters, you can see that the block is configured to useaconstantservicetimeof1second. To use a random service time instead, follow these steps:

1 Set Servicetimefromto Signal port t. This causes the block to have a

signal input port labeled t.

2 From the Signal Generators sublibrary of the Generators library, drag the

Event-Based Random Numbe r block into the model window and connect it to the Single Server block’s signal input port labeled t.

simeventsdocex('doc_dd1') in the M ATLAB Command

4-7

4 Basic Queues and Servers

3 Run the simulation and note how the plot differs from the one corresponding

to constant service times (shown in “Results of the Simulation” on page 2-13).

Constructs Involving Queues and Servers

HerearesomeexamplesofwaystocombineFIFOQueueandSingleServer blocks to model different situations:

• “Serial Queue-Server Pairs” on page 4-8

4-8

• “Parallel Queue-Server Pairs as Alternatives” on page 4-9

• “Parallel Queue-Server Pairs in Multicasting” on page 4-10

• “Serial Connection of Queues” on page 4-10

• “Parallel Connection of Queues” on page 4-11

Serial Queue-Server Pairs

Two queue-server pairs connected in series represent successive operations that an entity undergoes. For example, parts on an assembly line are processed sequentially by two machines.

While you might alternatively model the situation as a pair of servers without a queue between them, the absence of the queue means that if the first server

Using FIFO Queue and Single Server Blocks

completes service on an entity before the second serve r is available, the entity muststayinthefirstserverpasttheendofserviceandthefirstservercannot accept a new entity for service until the second server becomes available.

Parallel Qu

Two q ueue-server pairs connected in parallel, in which each entity arrives at one or the other, represent alternative operations. For example, vehicles wait in line for one of several tollbooths at a toll plaza.

eue-Server Pairs as Alternatives

4-9

4 Basic Queues and Servers

Parallel Queue-Ser ver Pairs in Multicasting

Two q ueue-server pairs connected in parallel, in which a copy of each entity arrives at both, represent a multicasting situation such as sending a message to multiple recipients. Note that copying entities might not make sense in some applications.

4-10

Serial Connection of Queues

Two queues connected in series might be useful if you are using entities to model items that physically experience two distinct sets of conditions while in storage. For example, additional inventory items that overflow one storage area have to stay in another storage area in which a less well-regulated temperature affects the items’ long-term quality. Modeling the two storage areas a s distinct queue blocks facilitates viewing the average length of time that entities stay in the overflow storage area.

Using FIFO Queue and Single Server Blocks

A similar example is in “Example of a Logical Queue” on page 4-11, except that the example there does not suggest any physical distinction between the two queues.

Parallel Connection of Queues

Two queues connected in parallel, in which each entity arrives at one or the other, represent alternative paths for waiting. The paths might lead to different operations, such as a line of vehicles waiting for a tollbooth modeled andalineofvehicleswaitingonajammedexitrampofthefreeway. You might model the tollbooth as a server and the traffic jam as a gate.

Example of a Logical Queue

Suppose you are modeling a queue that can physically hold 100 entities and you w ant to determine what proportion of the time the queue length exceeds

10. You can model the long queue as a pair of shorter queues connected in series. The shorter queues have length 90 and 10.

4-11

4 Basic Queues and Servers

Although the division of the long queue into two shorter queues has no basis in physical reality, it enables you to gather statistics specifically related to one of the shorter queues. In particular, you can view the queue length signal (#n) of the queue having length 90. If the signal is positive over a nonzero time interval, then the length-90 queue contains an entity that cannot advance to the length-10 queue. This means that the length-10 queue is full. As a result, the physical length-100 queue contains more than 10 items. Determining the proportion of time the physical queue length exce eds 10 is equivalent to determining the proportion of time the queue length signal of the logical length-90 queue exceeds 0.

4-12

Designing Paths for Entities

• “Role of Paths in SimEvents Models” on page 5-2

• “Using the Output Switch” on page 5-5

• “Using the Input Switch” on page 5-9

• “Combining Entity Paths” on page 5-12

• “Example: A Packet Switch” on page 5-16

5 Designing Paths for Entities

Role of Paths in SimEvents M odels

In this section...

“Definition of Entity Paths” on page 5-2

“Implications of Entity Paths” on page 5-2

“Overview of Routing Library for Designing Paths” on page 5-3

Definition of Entity Paths

An entity path is a connection from an entity output port to an entity input port, depicted as a line connecting the entity ports of two SimEvents blocks. An entity path represents the equivalence between an entity’s departure from the first block and arrival at the second block. For example, in the model shown below, any entity that departs from the FIFO Queue block’s OUT port equivalently arrives at the Single Server block’s IN port.

5-2

The existence of the entity path does not guarantee that any entity actually uses the path; for example, the simulation could be so short that no entities are ever generated. Even when an entity path is used, it is used only at a discrete set of times during the simulation.

Implications of Entity Paths

In some models, you ca n use the entity connection lines to infer the full sequence of blocks that a given entity arrives at, throughout the simulation.

Role of Paths in SimEvents®Models

In many discrete-event models, h owever, the set of entity connection lines does not completely determine the sequence of blocks that each entity arrives at. For example, the model below shows two queues in a parallel arrangement, preceded by a block that has one entity input port and two entity output ports.

By looking at the entity connection lines alone, you cannot tell w hich queue block’s IN port an entity will arrive at. Instead, you need to know more about how the one-to-two block (Output Switch) behaves and you might even need to know the outcome of certain run-time decisions.

Overview of Routing Library for Designing Paths

You design entity paths by choosing or combining entity paths using some of the b locks in the Routing library of the SimEvents library set. These blocks have extra entity ports that let you vary the model’s topology (that is, the set of blocks and connection lines).

Typical reasons for manipulating entity paths are

• To describe an inherently parallel behavior in the situation you are

modeling — for example, a computer cluster with two computers that share the computing load. You can use the Output Switch block to send computing jobs to one of the two computers. You might also use the Path Combiner or Input Switch block if computing jobs share a common destination following the pair of computers.

• To design nonlinear topologies, such as feedback loops — for example,

repeating an operation if quality criteria such as quality of service (QoS)

5-3

5 Designing Paths for Entities

• To incorporate logical decision making into your simulation — for example,

Other libraries in the S im Events library set contain s ome blocks whose secondary features, such as preemption from a server or timeout from a queue or server, give you opportunities to design paths.

are not met. You can use the Path Combiner block to combine the paths of new entities and entities that require a repeated operation.

determining scheduling protocols. You might use the Input Switch block to determine which of several queues r eceive s attention from a server.

5-4

Using the Output Switch

In this section...

“Role of the Output Switch” on page 5-5

“Sample Use Cases” on page 5-5

“Example: Selecting the First Available Server” on page 5-6

“Example: Using an Attribute to Select an Output Port” on page 5-8

Role of the Output Switch

The Output Switch block in the Routing library selects one among a number of entity output ports. The selected port can change during the simulation. You have several options for criteria that the block uses to select an entity output port.

When the sele cted port is not blocked, an arriving entity departs through this port.

Using the Output Switch

Sample Use Cases

Here are some scenarios in which you might use an output switch:

• Entities advance to one of several queues based on efficiency or fairness

concerns. For example, airplanes advance to one of several runways depending on queue length, or customersadvancetothefirstavailable cashier out of several cashiers.

Comparing different approaches to efficiency or fairness, by testing different rules to determine the selected output port of the output switch, might be part of your goal in simulating the system.

• Entities advance to a specific destination based on their characteristics.

For example, parcels advance to one of several delivery vehicles based on the locations of the specified recipients.

• Entities use an alternate route in case the preferred route is blocked. For

example, a communications network drops a packet if the route to the transmitter is blocked and the simulation gathers statistics about dropped packets.

5-5

5 Designing Paths for Entities

The topics listed below illustrate the use of the Output Switch block.

Topic

“Example: Selecting the First Available Server” on page 5-6

“Example: Using an Attribute to Select an Output Port” on page 5-8

“Example: A Packet Switch” on page 5-16

“Example: Choosing the Shortest Queue” online

“Example: U sing Servers in Shifts” online

To learn about design considerations when you switch according to an input signal, see “Output Switching Based on a Signal” in the SimEvents user guide documentation. To learn about all supported switching criteria, see the online referencepagefortheOutputSwitchblock.

Features of Example

First port that is not blocked

switching criterion

Attribute-based switching, where the a ttribute value is random

Attribute-based switching in conjunction with a Path Combiner block

Switching according to a computation that occurs upon entity arrivals

Switching according to a computation related only to the simulation clock

Example: Selecting the First Available Server

In this example, entities arriving at the Output Switch block depart through the f irst entity output port that is not blocked, as long as at least one entity output port is not blocked. An everyday example of this approach is a single queue of people waiting for service by one of several bank tellers, cashiers, call center representatives, etc. Each person in the queue wants to advance as soon as possible to the first available service provider without preferring one over another.

5-6

You can implement this approach by setting the Switching criterion parameter in the Output Switch block to

First port that is not blocked.

Using the Output Switch

This deterministic model creates one entity every second and attempts to advancetheentitytooneoftwoservers. Thetwoservershavedifferent service times, b oth greater than 1 second. The server with the longer service time becomes available less frequently and has a smaller throughput. The FIFO Queue block stores entities while both servers are busy. After any server becomes available, an entity in the queue advances to the Output Switch, which outputs that entity to that server.

The Output Switch block also outputs a signal containing the index of the entity output port through which the most recent entity departure occurred. The Signal Scope block plots the values of this signal. You can see from the plot that, compared to the first server, the second server processes more entities because its service time is shorter.

5-7

5 Designing Paths for Entities

Example: Using a

Consider the sit vehicles based o entity, then yo recipient. To i in the Output S

The example be itself), par generator re being marked block, the p block model parcel thro From there zone, but y outputs fr

uation in which parcels are sorted among several delivery n the locations of the specified recipients. If each parcel is an

u can attach data to each entity to indicate the location of its

mplement the sorting, set the Switching criterion parameter

witch block to

low illustrates the sorting process (but not the delivery process

titioning the delivery area into three geographic zones. An entity

presents sources of parcels addressed to one of the zones. After

witharandomlychosenzone1,2,or3viatheSetAttribute

arcels advance to the queue to wait for sorting. The Single Server

s the small delay incurred in the sorting process and sends each

ugh the Output Switch block to one of three entity output ports.

, the example merely counts the sorted entities destined for each

our own simulation might do something interesting with the

om the switch.

nAttributetoSelectanOutputPort

From attribute.

5-8

Using the Input Switch

In this section...

“Role of the Input Switch” on page 5-9

“Example: Round-Robin Approach to Choosing Inputs” on page 5-9

Role of the Input Switch

The Input Switch block in the Routing library chooses among a number of entity input ports. This block selects exactly one entity input port for potential arrivals and makes all other entity input ports unavailable. The selected entity input port can change during the simulation. You have several options for criteria that the block uses for selecting an entity input port.

A typical scenario in which you might use an input switch is when multiple sources of entities feed into a single queue, where the sequencing follows specific rules. For example, users of terminals in a time-shared computer submit jobs to a queue that feeds into the central processing unit, where an algorithm regulates access to the queue so as to prevent unfair domination by any one user.

Using the Input Switch

Example: Round-Robin Approach to Choosing Inputs

In a round-robin approach, an input switch cycles through the entity input ports in sequence. After the last entity input port, the next selection is the first entity input port. The switch selects the next entity input port after each entity departure. When the switch selects an entity input port, it makes the other entity input ports unavailable, regardless of how long it takes for an entity to arrive at the selected port.

You can implement a round-robin approach by setting the Switching criterion parameter in the Input Switch block to

Round robin.

5-9

5 Designing Paths for Entities

Consider the following example, in which three sets of entities attempt to arrive at an Input Switch block with the round-robin switching criterion.

5-10

The three Set Attribute blocks assign a Type attributetoeachentity,where the attribute value depends on which entity generator created the entity. FIFO Queue blocks store entities that cannot enter the Input Switch block yet because either

• The Input S witch is waiting to receive an entity at a different entity input

port, according to the round-robin switching criterion.

• The Single Server block is busy serving an entity, so its entity input port is

unavailable.

Mathworks SIMEVENTS 3 Installation Guide

Specifications and Main Features

Frequently Asked Questions

User Manual