MATLAB: SimEvents: Which entity type should event actions be assigned to? Invoker type or target type

matlab discrete-event systemSimEventstestentry

Event actions of MATLAB discrete-event system should be named according to this rule: entityType + eventAction. The rule is rather easy to understand for events that target entities. But I got confused for events that target storages, especially testEntry and iterate.

For example, assume that we have 2 storages. Storage1 accepts entities of type Task, while Storage2 accepts entities of type Failure. We want the DES system to open or close the gate of Storage1 via testEntry, when a Failure entity arrives in Storage2. In this situation, should FailureEntry invoke TaskTestEntry (type of the storage that is affected) or FailureTestEntry (type of the storage that invokes the event action)?

Best Answer

Hi Kar,

The testEntry method is invoked before an entity enters a storage. This method allows to either accept or refuse an entity from entering that particular storage. In the case of the storage for Task entities, the callback method name would be TaskTestEntry and for the Failure storage it would be FailureTestEntry.

For this example, when a Failure entity arrives into storage 2, an internal flag can be set in the block that would block Task entities from entering the block. When we are done processing the Failure entity, we can reset the flag so that we can start accepting entities into Storage 1. To check if any entities are waiting to enter storage 1, we can schedule a testEntry event for storage 1.

Regards,

Krishna

Related Solutions

MATLAB: Simevents: change the server capacity during simulation

Hi Kar,

You are correct, Entity Server does not allow for changing the capacity at run-time. Resource Pool block allows changing the resource amount at run-time through a signal port, but it only allows incrementing the available resources in the pool. And not the other way around.

For the variable capacity server, you can try using a MATLAB discrete-event system block and try including a queue of infinite capacity. You can then control whether to allow or disallow an entity from entering the queue by implementing the testEntry method. That way you can control the capacity at run-time. For example you can do something like the following:

function isAllowed = testEntry(obj, storage, ~, ~)
    % Specifies whether entities are allowed into the storage
    isAllowed = obj.mCurrentOccupancy <= obj.mCurrentCapacity;
end
function events = entry(obj, storage, ~, ~)
    % Increment the current occupancy

    obj.mCurrentOccupancy = obj.mCurrentOccupancy + 1;
    
    % Post a forward event after service-time

    events = obj.eventForward('output', 1, obj.mServiceTime);
end
function events = exit(obj, ~, ~, ~)
    % Decrement the current occupancy
    obj.mCurrentOccupancy = obj.mCurrentOccupancy - 1;
    
    if(obj.mCurrentOccupancy < obj.mCurrentCapacity)
        % Since there is room for entities, check if any entity
        % wishes to enter the block.
        events = [events obj.eventTestEntry(1)];
    end
end

In the above example, you can define mCurrentCapacity as a tunable parameter (not recommended). If the capacity decreases, then the new capacity would kick in only after the delta amount of entities would have left the block. You can have a more complex policy based on your particular use-case.

One caveat with the above piece of code is that, when the capacity of the server changes (increases), we need to test for entry (by posting a testEntry event), as there might be entities that were previously blocked out. But there is no way to do that since, we cannot associate an event when a tunable parameter changes. The best way would be to increment the server capacity by using another entity port. This other port would accept an entity that specifies the new capacity. This would enable us to return a testEntry event from the entry method.

function events = entry(obj, storage, ~, ~)
    % Increment the current occupancy
    if storage == 1
        % Book-keeping
        obj.mCurrentOccupancy = obj.mCurrentOccupancy + 1;
        
        % Post a forward event after service-time
        events = obj.eventForward('output', 1, obj.mServiceTime);
    elseif storage == 2
        obj.mCurrentCapacity = entity.data; % Assuming anonymous entity
        % Omitting checks for brevity
        events = [events obj.eventTestEntry(1)];
    end
end

An alternative to using DES block would be to use an infinite capacity server and use an entity gate to control the number of entities entering the server. The gate could be operated by adding some logic which would be driven by the statistics ports of the Entity Server.

Hope this helps!

- Krishna

MATLAB: SimEvents: Is it possible to generate an event-based entity with specific attribute values defined in the caller block’s event action

Hi Kar,

Unfortunately, the entity generator's 'Generate' event action cannot use the values from the generation triggering entity. I have however been able to use Simulink Functions to create getter and setter functions to write and read values from the event actions:

I have called setVal(1, 2, 3) from the terminator's entry action and then called [v1, v2, v3] = getVal() from the entity generators 'generate' event action to read the values. However, this has some pit falls. If another entity arrives at the terminator with a higher priority than the generate event, then the values in the simulink function get overwritten. I haven't been able to figure out a better way. Hope this helps!

Regards,

Krishna

Best Answer

Related Solutions

MATLAB: Simevents: change the server capacity during simulation

MATLAB: SimEvents: Is it possible to generate an event-based entity with specific attribute values defined in the caller block’s event action

Related Question