How the Simulation Engine Works

Understanding the Simulation Engine

ProcessMind uses a discrete event simulation (DES) engine to model your processes. Understanding how this engine works will help you configure simulations more effectively and interpret results accurately.

What is Discrete Event Simulation?

In discrete event simulation, the system state changes only at specific events—the clock jumps from event to event, and between events, nothing happens. This approach is ideal for business processes because:

• Activities have distinct start and end times
• Resources are allocated and released at specific moments
• Cases arrive and complete at defined points

Why Discrete Events?

Unlike continuous simulation (used for physics or fluid dynamics), business processes don’t need moment-by-moment modeling. A loan application doesn’t gradually transition from “submitted” to “approved”—it changes state at specific events.

The Core Event Loop

The simulation engine follows a simple but powerful loop:

1. Initialize: Set up starting conditions
2. Get Next Event: Find the earliest scheduled event from the priority queue
3. Advance Time: Move simulation clock to that event's time
4. Process Event: Handle the event (start activity, complete activity, etc.)
5. Schedule New Events: Based on what happened, add new events
6. Repeat: Continue until end time or max events reached (2,000,000)
7. Output: Generate the complete event log

Types of Events

The simulation generates and processes several event types:

Case Generation and Arrival

Cases enter the simulation through Start Events in your BPMN model. The arrival pattern is controlled by the case generation distribution.

Default Arrival Pattern

By default, cases arrive following a Poisson distribution with a rate of 1 case per hour. This creates realistic, random inter-arrival times typical of many business processes.

Customizing Arrivals

You can configure different arrival patterns using the distributions described in the Distributions  documentation.

Case Flow Through the Process

Sequence Flows

When a case completes an element, it immediately follows the outgoing sequence flow. If there’s only one outgoing path, the case takes it automatically.

Gateway Behavior

Gateways control how cases branch and merge:

Setting Probabilities

For XOR gateways, you assign probabilities to each outgoing flow. These are relative weights:

• If you set flows to 70, 20, and 10, they normalize to 70%, 20%, 10%
• If you set flows to 7, 2, and 1, you get the same result
• All flows must have a probability; unassigned flows use the remaining percentage

Activity Execution

When a case reaches a task (activity), the engine follows this sequence:

1. Check Resource Availability

Does the required resource have capacity available?

2. Queue if Needed

If resources aren’t available, the case enters the waiting queue. ProcessMind uses FIFO (First In, First Out) ordering—cases are processed in the order they arrived.

3. Allocate Resources

Once available, the required resource units are reserved for this case.

4. Sample Processing Time

The engine draws a value from the configured processing time distribution. This determines how long the activity will take.

5. Schedule Completion Event

A completion event is added to the event queue at current_time + processing_time.

6. Release Resources

When the completion event fires, resources are returned to the pool for other cases.

Minimum Processing Time

To ensure unique timestamps and realistic behavior, all activities have a minimum duration of 1 second. Even with a zero-duration distribution, activities take at least this long.

Skip Chance

Activities can be configured with a skip chance (0-100%). When an activity is skipped:

• The case proceeds immediately to the next element
• No resources are consumed
• No time passes (except the minimum 1 second)
• The activity appears in the log with minimal duration

This models real-world scenarios where steps are occasionally bypassed.

Time Handling

The Simulation Clock

The simulation maintains a virtual clock that advances discretely from event to event. If the next event is at 10:35 AM and the current time is 10:30 AM, the clock jumps directly to 10:35 AM.

Time Units

All times are converted to consistent units internally. You can specify durations in:

• Seconds
• Minutes
• Hours
• Days
• Weeks
• Months

Periodicity and Time Slots

Parameters can vary based on the simulation time. For example:

• Different arrival rates for weekdays vs. weekends
• Different processing times for morning vs. afternoon shifts
• Different resource capacity during peak hours

See the Periodicity  documentation for configuration details.

Resource Management

Resource Pools

Each resource has a defined capacity—the number of cases it can handle simultaneously.

Queue Management

When demand exceeds capacity, cases wait in a queue. ProcessMind uses FIFO (First In, First Out) ordering, ensuring cases are processed in arrival order.

Event Log Generation

As the simulation runs, every activity execution is recorded in the output event log:

This log follows standard event log formats and can be analyzed with all ProcessMind tools.

Simulation Limits

Next Steps