In some applications, it is useful to model situations in which a server fails. For example, a machine might break down and later be repaired, or a network connection might fail and later be restored. This section explores ways to model failure of a server, as well as server states.
The blocks in the Servers library do not have built-in states, so you can design states in any way that is appropriate for your application. Some examples of possible server states are in the table below.
|Server as Communication Channel||Server as Machine||Server as Human Processor|
|Transmitting message||Processing part||Working|
|Connected but idle||Waiting for new part to arrive||Waiting for work|
|Holding message (pending availability of destination)||Holding part (pending availability of next operator)||Waiting for resource|
|Establishing connection||Warming up||Preparing to begin work|
For any state that represents a server's inability or refusal to accept entity arrivals even though the server is not necessarily full, a common implementation involves an Enabled Gate block preceding the server.
The gate prevents entity access to the server whenever the gate's control signal at the en input port is zero or negative. The logic that creates the en signal determines whether or not the server is in a failure state. You can implement such logic using the MATLAB Function block, using a subsystem containing logic blocks, or using Stateflow® charts to transition among a finite number of server states.
For an example in which an Enabled Gate block precedes a server, see Control Joint Availability of Two Servers. The example is not specifically about a failure state, but the idea of controlling access to a server is similar. Also, you can interpret the Signal Latch block with the st output signal enabled as a two-state machine that changes state when read and write events occur.
Note: A gate prevents new entities from arriving at the server but does not prevent the current entity from completing its service. If you want to eject the current entity from the server upon a failure occurrence, then you can use the preemption feature of the server to replace the current entity with a high-priority "placeholder" entity.
Stateflow software is suitable for implementing transitions among a finite number of server states. If you need to support more than just two states, then a Stateflow block might be more natural than a combination of Enabled Gate and logic blocks.
When modeling interactions between the state chart and discrete-event aspects of the model, note that a function call is one way to make Stateflow blocks respond to asynchronous state changes. You can use blocks in the Event Generators and Event Translation libraries to produce a function call upon signal-based events or entity departures; the function call can invoke a Stateflow block. Conversely, a Stateflow block can output a function call that can cause a gate to open, an entity counter to reset, or an entity generator to generate a new entity.
The example below (open modelmodel) uses a Stateflow block to describe a two-state machine. A server is either down (failed) or up (operable). The state of the server is an output signal from the Stateflow block and is used to create the enabling signal for an Enabled Gate block that precedes a server in a queuing system.
The lower portion of the model contains a parallel queuing system. The entities in the lower queuing system represent failures, not customers. Generation of a failure entity represents a failure occurrence in the upper queuing system. Service of a failure entity represents the time during which the server in the upper queuing system is down. Completion of service of a failure entity represents a return to operability of the upper queuing system.
When the lower queuing system generates an entity, changes in its server's #n signal invoke the Stateflow block that determines the state of the upper queuing system. Increases in the #n signal cause the server to go down, while decreases cause the server to become operable again.
While this simulation runs, Stateflow alternately highlights the up and down states. The plot showing entity departures from the upper queuing system shows gaps, during which the server is down.
Although this two-state machine could be modeled more concisely with a Signal Latch block instead of a Stateflow block, the Stateflow chart scales more easily to include additional states or other complexity.
The example below (open modelmodel) modifies the one in Failure and Repair of a Server by adding a warmup phase after the repair is complete. The Enabled Gate block in the upper queuing system does not open until the repair and the warmup phase are complete. In the lower queuing system, an additional Single Server block represents the duration of the warmup phase.
In the Stateflow block, the input function calls controls when the repair operation starts, when it ends, and when the warmup is complete. The result of the function-call event depends on the state of the chart when the event occurs. A rising edge of the Repair Work block's #n signal starts the repair operation, a falling edge of the same signal ends the repair operation, and a falling edge of the Warmup block's #n signal completes the warmup.
While this simulation runs, the Stateflow chart alternates among the three states. The plot showing entity departures from the upper queuing system shows gaps, during which the server is either under repair or warming up. By comparing the plot to the one in Failure and Repair of a Server, you can see that the gaps in the server's operation last slightly longer. This is because of the warmup phase.