Documentation Center

  • Trial Software
  • Product Updates

Combine Entities and Allocate Resources

Overview of the Entity-Combining Operation

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.

For Further Information

Wait to Combine Entities

The model below (open modelmodel) illustrates the synchronization of entities' advancement by the Entity Combiner block and its preceding blocks.

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.

Copy Timers When Combining Entities

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.

Manage Data in Composite Entities

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.

Nonunique and Inaccessible Attribute Names in Composite Entity

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 a 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. However, 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.

Unique and Accessible Attribute Names in Composite Entity

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 OperationAttribute NamesUse of Attribute Function Block
Read existing attributes of the component entities.
HeaderLength
PayloadLength
TrailerLength
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.StatusNaming out_Status as an output argument of the function causes the block to update the Status attribute of the entity.
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.PacketLengthNaming out_PacketLength as an output argument causes the block to create the PacketLength attribute on the entity.

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;

    Note:   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 Status is an existing attribute and PacketLength is not.

Was this topic helpful?