A Simple Discrete-Event Simulation: Part 63

Today I finally implemented the first part of the reporting capability. So far the system keeps track of the total time spent trying to get through the major process areas and through the entire system as well. The entities are time stamped when they enter the system and also when they enter a new process area. The results are collected in time buckets (which have been set to 30 units in this example) whenever an entity leaves a process area or exits the entire system.

Determining when the entities enter and leave the entire system is straightforward but determining when they enter and leave each process area is more complex. What I did was create a componentGroup property for each component in the model. The various Process components, either singly or in groups, determine the process areas. The Queue components that feed each Process components or set of Process components are also given the same componentGroup label. Path components are not given labels and do not figure into this calculation (for now). Process components 1, 2, and 3, along with Queue components 0, 1, 2, and 3 were labeled as being part of the “Primary” group. Process components 10 and 11 and Queue component 10 were labeled as the “Secondary” group. A default group is created for the entire “System.” For the current iteration of the code I labeled all of the components by hand using a setComponentGroup method. It should be possible to only label the Process components and then have the system automatically identify the Queues that feed them but there are some complications that may arise with that. (I’ll add a note to the To Do list.)

When a Queue component or Process component receives an entity it checks to see if the entity’s componentGroup label is different than that of the component itself. If it is, then the entity’s componentGroup is given the value of the component and the entity is time stamped. Here’s where the fun begins: at this point the system updates a counter in the current interval bucket of the global stats data structure. In our current system this happens in Queue components 0 and 10. When the entity is forwarded from a Process component the remainder of the data is written to the global stats data structure. This involves incrementing a count, adding the elapsed residence time for the process area to an accumulator, checking to see if the residence time is a new highest or lowest value for the current interval, recording the new number of entities in the process area, and checking to see whether that value is a new high or low for the current interval.

A new stats timing component updates the bucket index at defined intervals (again, 30 time units for our example), and ensures that the global stats data structure is expanded to hold the next interval’s data. When the model run is complete the data is processed to output nice tables of results in the scrolling text area. It generates a table for each process area and each table includes a line for each time interval and a line for the totalized results for the run. Go ahead and run the model and see what results it generates. I’ve included an example output here.

A good bit of thought can go into what each of these results actually mean. For now, the residence time in the system and each process area is simply the total time the entity spent there. If we want to know how long an entity waited to be processed, however, that would be a different story. In that case we’d have to subtract the amount of time it takes to traverse the queues and links within a process area. If an entity passed straight through without delay then we’d say that the waiting time was zero, would we not? There are also counters for the number of entities in each area, but we may or may not want to count the ones that are actively being processed in a Process component. We’ll explore this going forward, and I’ll add still another To Do item.

This capability can be made a lot more complex. Statistics can be captured for different meta time periods (e.g. by day as well as by interval and for the run as a whole) or counts can be added for each component or group of like components (e.g., the number of entities using each entry or exit, the number processed in each “Primary” Process component or each “Secondary” process component). Resource use and availability can also be added when those features are added to the model. Graph and formatted print outputs can also be generated. The possibilities are almost endless, but this was a pretty fair start.