You can combine entities from different paths using the Entity Combiner block. The entities that you combine, called component entities, might represent different parts within a larger item, such as the header, payload, and trailer that are parts of a data packet. Alternatively, you can model resource allocation by combining an entity that represents a resource with an entity that represents a part or other item.
The Entity Combiner block and its surrounding blocks automatically detect when all necessary component entities are present and when the composite entity that results from the combining operation will be able to advance to the next block.
The Entity Combiner block provides options for managing information (attributes and timers) associated with the component entities. You can also configure the Entity Combiner block to make the combining operation reversible via the Entity Splitter block.
Entity Combiner reference page
Entity Splitter reference page
The combining operation proceeds when all of these conditions are simultaneously true:
The top queue has a pending entity.
The middle queue has a pending entity.
The bottom queue has a pending entity.
The entity input port of the Instantaneous Entity Counting Scope block is available, which is true throughout the simulation.
The bottom entity generator has the largest intergeneration time among the three entity generators, and is the limiting factor that determines when the Entity Combiner block accepts one entity from each queue. The top and middle queues store pending entities while waiting for the bottom entity generator to generate its next entity.
If you change the uniform distribution in the middle entity generator to produce intergeneration times between 0.5 and 3, then the bottom entity generator is not consistently the slowest. Nevertheless, the Entity Combiner block automatically permits the arrival of one entity from each queue as soon as each queue has a pending entity.
While you could alternatively synchronize the departures from the three queues using appropriately configured gates, it is simpler and more intuitive to use the Entity Combiner block as shown.
The model below (open modelmodel) combines an entity representing a product with an entity representing a box, thus creating an entity that represents a boxed product. The Entity Combiner block copies the timer from the product to the boxed product.
The model plots the products' average age, which is the sum of the time that a product might wait for a box and the service time for boxed products in the Infinite Server block. In this simulation, some products wait for boxes, while some boxes wait for products. The generation of products and boxes are random processes with the same exponential distribution.
This section illustrates the connection between access to a component entity's attributes in a composite entity and uniqueness of the attribute names across all component entities.
The model below (open modelmodel) combines
component entities representing a header, payload, and trailer into
a composite entity representing a packet. Each component entity has
Length attribute that the packet stores. When
the Entity Splitter block divides the packet into separate
header, payload, and trailer entities, each has the appropriate attribute.
Length is not accessible in the packet
(that is, after combining and before splitting). If it were, the name
would be ambiguous because all component entities have an attribute
by that name.
The model below (open modelmodel) uniquely names all attributes of the components and makes them accessible in the packet. If your primary focus is on data rather than the entities that carry the data, then you can think of the Entity Combiner block as aggregating data from different sources.
The model uses the Attribute Function block and its underlying function to illustrate these ways of accessing attributes via the composite entity.
|Attribute Operation||Attribute Names||Use of Attribute Function Block|
|Read existing attributes of the component entities.|
|Naming these attributes as input arguments of the function causes the block to read these attributes of the arriving entity.|
|Change the value of an existing attribute of a component. The new value persists when the Entity Splitter block divides the packet into its component entities.||Naming |
|Create a new attribute on the composite entity, not associated with any of the component entities. The new attribute does not persist beyond the Entity Splitter block.||Naming |
Function Underlying the Attribute Function Block.
function [out_PacketLength, out_Status] = packet_length(HeaderLength,... PayloadLength,TrailerLength) %PACKET_LENGTH Sum the component lengths and set Status to 1. out_PacketLength = HeaderLength + PayloadLength + TrailerLength; out_Status = 1;
The code does not distinguish between output arguments that
define new attributes and output arguments that define new values
for existing attributes. Only by examining other blocks in the model
could you determine that