In some applications, it is useful to model situations in which a server fails. For example, a machine breaks down and later is repaired, or a network connection fails and later is restored. This section explores ways to model failure of a server, and server states.
Server blocks 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 this table.
|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 inability or refusal to accept entity arrivals even though the server is not necessarily full, a common implementation involves an Entity Gate block preceding the server.
The gate prevents entity access to the server whenever the gate control message at the inport port at the top of the block carries zero or negative values. The logic that creates the control message determines whether the server is in a failure state. You can implement such logic using the Simulink Function block, using a Message Send block, or using Stateflow® charts to transition among a finite number of server states.
This example shows an instance in which an Entity Gate block precedes a server. The example is not specifically about a failure state, but the idea of controlling access to a server is similar. It models a stochastically occurring failure that lasts for some amount of time.
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.