Anda di halaman 1dari 4

Using SimEvents to create a simplest queuing model

Today we will briefly review the Matlab SimEvents framework for discrete-event simulation. We will use it to build a simplest queuing model (our previous example with the post office). In SimEvents, the model is created from the elementary blocks that include job generators (job are called entities in SimEvents), queues, servers, job sinks, visualization elements etc. Blocks communicate with each other in following ways: by routing jobs. One block can send jobs to other block according to the models logic; by signals. Signals are generated in response to external event and have numerical values. E.g. the queue generates signal when the job is added; the value of the signal is the number of jobs in the queue; function calls. These are instantaneous events that does not contain any additional information. Signal can be transformed to the function calls, but not vice versa. To create the new model: Open MATLAB; Select File->New->Model You will see a model window. To open a library of SimEvent blocks, open the Simulink->SimEvents->Block Library from the Start menu. First item we are interested in is the Entity generator, which generates jobs (entities according to the SimEvents terminology). To do this, open the Generators group in the block library window by double clicking on it. Then open Entity generators. There are two types of job generators: Time-based generators: generate entities from the given distribution; Event-Based entity generator: generate entities in a response to the external event. To add the block to the model, drag it from the block library window to the model window. You can rename the block on the model by clicking on its name and entering the new one. Now lets specify the distribution for events interarrival times. Open the generators properties by double clicking on the block. Now select Intergeneration time from dialog for the Generate entities with option. Set Distribution to a desired type of the distribution (Exponential refers to the Poisson process) and set the mean accordingly (in our example - 0.1). Note: Initial seed option refers to the initial seed for the PRNG. You can set the fixed number there. As a result, every time youll run the simulation, you will get the same sequence of random numbers (very convenient for debugging). To get a truly random sequence you can pot

in there a mod(ceil(cputime*99999),2^32) text. In this case the PRNG will use the current CPU time to produce unique sequences, but the results will not be repeatable. Our jobs are sent to the queue before being passed to the server. To add the queue to the model, open the Queues group and add the queue with the appropriate policy (in our case FIFO) to the model. You can adjust the maximum queue length by changing a corresponding option of the block. Connect the OUT port of the generator with the IN port of the queue using the mouse, Note: ports with double arrows (>>) are used to send/receive jobs, while ports with single arrow (>) are used to route signals. To add the server, open the Servers group and select the appropriate server. You can add a single server (Single server block) or multiple servers that process jobs in parallel (using the N-server or Infinite server blocks). Connect Out port of the queue with the In port of the server. Please note that by default, the server has a fixed service time. Below we will discuss how we can generate servicing times from a distribution. Finally, we need to add a sink block that receives jobs departing from the system. Go to the Sinks group and put the Entity Sink to the model. Connect the server and the sink in the same way you connected other blocks. Now weve created the basic structure of the model. Earlier we noted that the server has a service time of the fixed length. This is not representative of the real-world server, so lets set up an appropriate servicing distribution. Unfortunately, unlike the entity generator, the server does not allow us to choose distribution explicitly. Instead, it relies on external signals to set up service times. Open options of the server and set Service time from option to the Signal port t. Note that corresponding port has appeared on the server block. Now open the Generators group again and then open Signal Generators subgroup. Add the Event-based random number block to the model and connect its output with the t port of the server. Now every time when the server needs to get the amount of service time, it will request that time from the event-based random generator. And the random number generator will provide that number as a signal. You can use the same approach in the Time-based entity generator block to generate entities with different distributions of interarrival times. Now you can open the properties of the Event-based random number block and set the appropriate distribution and its parameters. For our model of the post office, use the exponential distribution and set the mean to 0.0625. In principle, our model is almost ready to launch. The only configuration parameter left is the simulation time (when the model must be stopped). To set it, open the configuration parameters of the model by selecting the Simulation->Configuration Parameters menu item. The dialog box will appear. In the list on the left select Solver to open parameters of the simulation engine. Now enter the desired value of the simulation time into the Stop time edit box (in our case it is 500). Also, since we have purely discrete event model, choose the discrete solver by choosing discrete (no continuous states) in the Solver drop-down list.

To run the model, select the Simulation->Start menu item or just press Ctrl+T. What our model lacks? Right, it lacks means to analyze and visualize the results. SimEvents allows getting a wide range of information on the model. Some statistics can be obtained from the blocks themselves. Some require more elaborate work. As an example, lets retrieve the length of the queue. Open the properties of the queue and go to the statistics tab. Find the Number of entities in queue, #n drop-down list and set it to On. Now the block will output the number of entities as a signal #n. To visualize the value of the signal, open the Sinks group and add the Signal Scope block to the model. Run the model. You will see the plot that shows how the number of entries in the queue varies with time. Do the same for the Average queue length, len parameter of the queue. Did you notice the difference? Here you can see when the transition state ends. Try running simulation with different values of the simulation time. Note that when the time is sufficiently large, the queue size approaches one that was predicted theoretically (1.042). You can use the similar approach to get different parameters, e.g. wait time of the queue. Visualization is good, but sometimes we need to get actual values of statistic. This can be done with the Discrete Event Signal to Workspace block (it belongs to the Sinks group). Add it to the model and connect to the same len port (to connect the block to the existing connection, hold a Ctrl). This block will create a corresponding variable in the MATLAB workspace and store values of statistic there. Open the properties of the block to set up the variable name and data format. Run the simulation. Note that the corresponding variable has appeared in the MATLAB workspace. However, some statistics are not related to some certain block, but are rather properties of the whole model. For example, consider response time. To get the response times, we need to use timers. Timers measure the amount of time it took for the job to perform certain actions. Roughly speaking, when the timer is started for the job, it records the current simulation time as a property of that job. When the timer is read, it subtracts the value of that property from the current simulation time and outputs result as a signal. To start the timer, insert the Start Timer block from the Timers group between the job generator and the queue and connect its ports correspondingly. As a results, jobs will pass through the timer on their way and the timer will record the current simulation time as a property (variable) of the model. Open the timer properties and set the name for the timer tag, which is the name of that job property. You might be happy with the default name T1 or choose your own name. Now insert the Read Timer block into the model between the server and the sink. Make sure that its tag name is the same as for the Start Timer block. Now go to the properties of the timer, open the Statistics tab and set the Average elapsed time, w statistic to On. This statistic will be output as the signal; you can visualize or export its values. Run the model; observe that the response time is close to values calculated analytically (0.167).

Experiment with the N servers. N=4, servtime = 0.3. Still rho < 1, but T is about 0.4 (increase from 0.1667). Increase mean service time to 0.5. Observe the queue growing steadily (rho > 1). Increase N to 6. rho<1 again; resptime = 0.834, qsize = 0.334

More complex example: attributes + routing. Set entity generator parameters: Intergeneration time mean: 0.8 Create a second copy of FIFO queue (and associated visualization/export blocks) and N-server with random number generator for generating the service times; Set top server parameters: N (number of servers): 1 Service time: mean = 0.5 Set bottom server parameters: N: 1 Service time: mean = 0.8 Now redistribute workload among the servers: Add Set Attribute block. Open properties, set name to A1, value to From signal port; Add Event-based random number block; rename to AttrValueGen. Set properties: Distribution: Arbitrary discrete Value vector: [1 2] Probability vector: [0.7 0.3] Add the Output switch after the timer; Connect ports with server inputs; Number of output ports: 2 Switching criterion: from attribute Attribute name: A1 Add the Path Combiner block after servers. Connect inputs with server ports Number of entity input ports: 2 Result: the system works fine, overall rho < 1. No queue is growing indefinitely, the response time is stable. Now reroute the traffic, so more jobs will go to the slower server. Set probability vector for the AttrValueGen to [0.3 0.7]. As a result, more traffic will go to the slower server. Results: faster server is fine. Its queue length is stable and well below 1. the slower server is clearly overloaded. Its queue is growing. the response time is steadily growing. The system as a whole is overloaded. Interesting results: part of the system is overloaded, part is underloaded. But the system as a whole is overloaded.

Anda mungkin juga menyukai