Suppose you want to determine how long each entity takes to advance from one block to another, or how much time each entity spends in a particular region of your model. To compute these durations, you can attach a timer to each entity that reaches a particular spot in the model. Then you can
Start the timer. The block that attaches the timer also starts it.
Read the value of the timer whenever the entity reaches a spot in the model that you designate.
Restart the timer, if desired, whenever the entity reaches a spot in the model that you designate.
The next sections describe how to arrange the Start Timer and Read Timer blocks to accomplish several common timing goals.
A typical block diagram for determining how long each entity spends in a region of the model is in the figure below (open modelmodel). The Start Timer and Read Timer blocks jointly perform the timing computation.
The model above measures the time each entity takes between arriving at the queue and departing from the server. The Start Timer block attaches, or associates, a timer to each entity that arrives at the block. Each entity has its own timer. Each entity's timer starts timing when the entity departs from the Start Timer, or equivalently, when the entity arrives at the FIFO Queue block. Upon departing from the Single Server block, each entity arrives at a Read Timer block. The Read Timer block reads data from the arriving entity's timer and produces a signal at the et port whose value is the instantaneous elapsed time for that entity. For example, if the arriving entity spent 12 seconds in the queue-server pair, then the et signal assumes the value 12.
The model above stores data from the timer in a variable called
the base MATLAB® workspace. After running the simulation, you
can manipulate or plot the data, as illustrated below.
% First run the simulation shown above, to create the variable % "delay" in the MATLAB workspace. % Histogram of delay values edges = (0:20); % Edges of bins in histogram figure histogram(delay.signals.values, edges) % Number of points per bin title('Histogram of Delay Values') % Cumulative histogram of delay values figure histogram(delay.signals.values, edges, 'Normalization', 'cumcount') title('Cumulative Histogram of Delay Values')
A typical procedure for setting up timer blocks is as follows:
Locate the spots in the model where you want to begin timing and to access the value of the timer.
Insert a Start Timer block in the model at the spot where you want to begin timing.
In the Start Timer block's dialog box, enter a name for the timer in the Timer tag field. Enter a new timer tag, or restart a previous timer by choosing it in the drop-down list. The timer tag you enter distinguishes the timer from other independent timers that might already be associated with the same entity.
When an entity arrives at the Start Timer block, the block attaches the named timer to the entity and begins timing.
Insert a Read Timer block in the model at the spot where you want to access the value of the timer.
In the Read Timer block's dialog box, enter the same Timer tag value that you used in the corresponding Start Timer block.
When an entity having a timer with the specified timer tag arrives at the block, the block reads the time from that entity's timer. Using the Statistics tab of the Read Timer block's dialog box, you can configure the block to report this instantaneous time or the average of such values among all entities that have arrived at the block.
If you need multiple independent timers per entity (for example, to time an entity's progress through two possibly overlapping regions of the model), then follow the procedure above for each of the independent timers. For more information, see Time Multiple Processes Independently.
If your model includes routing blocks, then different entities might use different entity paths. To have a timer cover multiple entity paths, you can include multiple Start Timer or multiple Read Timer blocks in a model, using the same Timer tag parameter value in all timer blocks.
In the figure below, each entity advances along one of two different entity paths via the Output Switch block. The timer continues timing, regardless of the selected path. Finally, each entity advances to one of the two Read Timer blocks, which reads the value of the timer.
In the figure below, entities wait in two different queues before advancing to a single server. The timer blocks measure the time each entity spends in its respective queue-server pair. Two Start Timer blocks, configured with the same Timer tag parameter value, ensure that all entities possess a timer regardless of the path they take before reaching the server.
You can restart an entity's timer, that is, reset its value
to zero, whenever the entity reaches a spot in the model that you
designate. To do this, insert a Start Timer block in
the model where you want to restart the timer. Then set the block's If
timer has already started parameter to
You can measure multiple independent durations using the Start Timer and Read Timer blocks. To do this, create a unique Timer tag parameter for each independent timer. For clarity in your model, consider adding an annotation or changing the block names to reflect the Timer tag parameter in each timer block.
The time each entity spends in the queue-server pair,
using a timer with tag
The time each entity spends in the server, using a
timer with tag
The annotations beneath the blocks in the figure indicate the
values of the Timer tag parameters. Notice that
T1 timer starts at the time when entities arrive
at the queue, while the
T2 timer starts at the
time when entities depart from the queue (equivalently, at the time
when entities arrive at the server). The two Read Timer blocks
read both timers when entities depart from the server. The sequence
of the Read Timer blocks relative to each other is
not relevant in this example because no time elapses while an entity
is in a Read Timer block.