Jump to content

Released entities in a vehicle's visit request queue


cstein
 Share

Recommended Posts

Hi, I would like to confirm whether behaviour regarding vehicle visit request queues is incorrect (i.e. a bug) or whether I am misunderstanding how they are supposed to work.


I have two types of vehicles in an Emergency Medical Services model. One type transports patient entities (i.e. an ambulance) and one doe not do transport but only responds to some incidents (i.e. a primary response vehicle or PRV). In some cases, both vehicles are sent to an incident node, the ambulance by accepting a visit request from a patient entity at the node, and the PRV by being seized directly by the patient entity at the node.


In some cases the PRV is far away and does not reach the node by the time the ambulance has completed loading the patient entity. In such cases I have modelled cancelling of the PRV (that would happen in a real system) by the patient entity releasing the PRV. When this happens, I have noticed that the patient entity that had seized the PRV stays in the PRV's visit request queue, even after the release. It is only removed from the visit request queue when the patient entity is destroyed, which may be some time later after a transport and hospital offload delay.


From observing the behaviour of other vehicles, it seems as though a vehicle must enter a node having the owner entity in it before the entity is removed from the visit request queue (or, as mentioned above, it is removed when the entity is destroyed). In my case, I would like to remove the patient entity from the PRV's visit request queue when the PRV is released, however I know that this is not possible as Simio does not allow entities to be removed from this queue with the remove step.


At the moment I am spending a lot of time trying to work around this problem, which creates a lot of undesirable behaviour - for example when there are three or four patient entities in the PRV's visit request queue. The vehicle object also has limited options in its task selection strategy which makes filtering out of the released entities in the visit request queue difficult to accomplish reliably.


Is there any other way of removing unwanted entities from the visit request queue, without visiting that entity's node or destroying it?

Link to comment
Share on other sites

I believe the 'arrive' step is used to notify entities in the visit request queue that the transporter has arrived, thereby finishing the visit request. I'm not sure, I haven't tried this... you could give it a go.


Alternatively, you could give entities a state of whether they actually want the PRV or not, and use the PRV use a condition or match rule on the PRV to ignore entities in the visit request queue with that state set to false. Of course as I'm sure you're dealing with now, this means your visit request queue will keep building up.

Link to comment
Share on other sites

Thanks, yes at the moment I'm setting the priority to -1 for the items in the visit request queue that I want to ignore, then using the "select largest priority" setting in the task selection strategy to choose the next visit destination (if the queue length is greater than 1). Items that I don't want to ignore have a value larger than that (luckily in this particular case the only alternative priority is 1). The queue does get longer, but as patient entities are destroyed later on they are taken out of the queue.


This seems to work, although subsequent changes to the model seem to always uncover a new state that somehow generates the same error under different circumstances. Feels as though I'm just plugging leaks!

Link to comment
Share on other sites

Hi there. In the past we also had difficulty controlling vehicle's visit request queues. What we have found much more success in subsequent models by creating a controlling entity that seizes the vehicle, searches tables or variables (find) and is moved to the required location. This way you have total control over the vehicle's next destination and can suspend's it's movement at any time. Note that it will have to complete it's move to the destination node when it resumes again, the destination cannot be changed once the move is initiated. What you will lose though is a lot of the standard statistics e.g. patient waiting time on node but these could be recorded quite easily by using steps like tallies. Utilization can be recorded using state variables. Hope this helps.

Link to comment
Share on other sites

  • 2 weeks later...
×
×
  • Create New...