The Simulation Feature simulates the multiple, or may be even mass execution of processes of a selected process model. Hence, a couple of assumptions about the
have to be made. The complete set of data describing the assumptions above is called a simulation configuration. The assumptions mentioned will be described in detail below.
You may specify multiple simulation configurations per process model version. This way you may simulate different scenarios, e.g. conservative and aggressive assumptions on the evolution of your business on the same model.
Parts of the assumptions described in a simulation configuration are time-dependent (e.g. arrival rates or availabilities). Their time-dependence is described over the simulation configuration interval. The interval boundaries are real world calendar timestamps, e.g. you may describe the behavior of all involved systems and resources from June 1, 2008 to June 30, 2011.
All simulations run with a specific simulation configuration have to run in this interval.
has a specific duration for each execution of a process instance. For simulating a possibly large number of process instances, the variation of this duration may be best described by statistical means: a probability distribution of the duration is described.
During simulation, a probability experiment is performed to obtain a duration value based on such a probability each time an activity is invoked or an application is executed.
The execution of processes requires access to resources, e.g.
In real world scenarios, these resources will be limited. For a proper simulation, assumptions about these limitations have to be described via the resource availability.
The availability of resources is time-dependent:
The variation of availabilities over the different time scales (day, year, long term) can be specified for a simulation configuration interval.
Based on the business cases occurring, a different number of process instances are created at different points in time in a real world scenario. To reflect this behavior arrival rates for process instances are specified in a simulation configuration. Depending on the arrival rate, the simulation engine will create process instances in a simulation run.
Similar to availabilities, the variation of arrival rates over time can be specified on a daily, yearly and long-term scale.
In real execution of processes, the traversal of transitions is controlled by expressions on process data (e.g. Credit.getAmount() > 20,000, Risk = "HIGH"). Simulation does not invoke application business logic and does not create process data. Hence, it has to be determined transition traversal probabilities.
It has to emphasized, that correlation between transition traversal conditions based on the same business data is lost. However, meaningful assumptions on traversal probabilities may reflect this correlation implicitly.
As mentioned above, simulation does not invoke application business logic and neither creates nor modifies process data. However, simulation results may stored in a - possibly dedicated - Audit Trail database to evaluate simulation results.
Hence, the ability to create process data during simulation has been added to the Simulation Feature. Its main purpose is to generate process data for report testing purposes.
For the creation of literal, numeric data a probability distribution might be provided. For strings or more complex data data providers may be added via Eclipse Extension Points of the Simulation Feature.
Simulation runtime configurations specify how a concrete simulation run is performed on a specific simulation configuration of a specific process model. They describe
Runtime configurations are separated from simulation configurations, because you may want to use the same simulation configuration for different runtime scenarios, e.g. to use different intervals of the same productive audit trail database to feed the same simulation configuration parameters.
Each simulation runtime configuration uses exactly one simulation configuration of a process model for its execution.
Instead of specifying the properties of your simulation configuration explicitly, you may retrieve these from audit trail data of already executed process instances. This way you may obtain a "real world behavior" of your simulation.