Role of Entity Ports and Paths
Entity Ports and Paths
An entity output port provides a way for an entity to depart from a block. Conversely, an entity input port provides a way for an entity to arrive at a block.
A connection line indicates a path along which an entity can potentially advance. However, the connection line 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. As a result, the entity fails 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.
One or more entities successfully advance along that path. This occurs only at a discrete set of times during a simulation.
The simulation could also have one or more times at which one or more entities successfully advance along a given entity path. Simultaneously, one or more different entities try and fail to advance along that same entity path. For example, an entity departs from a queue and, simultaneously, the next entity in the queue tries and fails to depart.
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 Entity Queue block's output port equivalently arrives at the Entity Server block's input port.
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 can use the entity connection lines to infer the full sequence of blocks at which a given entity arrives, throughout the simulation.
In many discrete-event models, however, the set of entity connection lines does not completely determine the sequence of blocks at which each entity arrives. This example 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 which queue block's IN port an entity arrives at. Instead, you need to know more about how the one-to-two block (Output Switch) behaves and understand the outcome of certain run-time decisions.
Designing Paths Using Input, Output, and Entity Combiner Blocks
You design entity paths by choosing or combining entity paths using the Entity Input Switch, Entity Output Switch, and Entity Combiner blocks of the SimEvents library. 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 Entity Output Switch block to send computing jobs to one of the two computers. You might also use the Entity Input Switch block if computing jobs share a common destination following the pair of computers.
To design nonlinear topologies, such as feedback loops — repeating an operation if quality criteria such as quality of service (QoS) are not met. You can use the Entity Input Switch block with the Active port selection parameter set to
Allto combine the paths of new entities and entities that require a repeated operation.
To incorporate logical decision-making into your simulation — for example, to determine scheduling protocols. You might use the Entity Input Switch block to determine which of several queues receive attention from a server.
To incorporate logic for activation or deactivation of an entity path, use the Entity Gate block. For example, you can activate an entity path for one entity when a condition is fulfilled in your model.
To model routing of copies of an entity to multiple remote locations in the model, consider using the Entity Multicast and Multicast Receive Queue blocks.
Other libraries in the SimEvents library set contain a number of blocks whose secondary features, such as preemption from a server or timeout from a queue or server, give you opportunities to design paths.