SynBPS

SynBPS (Synthetic Business Process Simulation) generates event logs from business processes that exist only as a set of parameters. Instead of calibrating a simulation model to an existing log, you specify the data-generating process directly: how cases arrive, which activity follows which (with or without memory, and with how much randomness), how long activities take, and when work waits for a resource or for business hours. Every component is a well-known parametric distribution, and every parameter can be varied as a factor in an experimental design.

This makes SynBPS a tool for controlled experiments in predictive process monitoring. Rather than evaluating a method on a handful of public logs alone, you can extend the evaluation across hundreds of processes whose characteristics you chose, replicate each setting with new seeds, and attribute differences in performance to the process instead of the log. Because the process is fully known, the transition tables and duration parameters behind every log can be inspected, which also makes it possible to compute the best achievable performance on that log and measure a model against it.

What SynBPS is not. It does not learn a simulation model from an existing event log (see Simod or Prosimos for this). The method is described in Riess (2024), SIMULATION, https://doi.org/10.1177/00375497241233326 [pdf]

Getting Started

You can install SynBPS using pip:

pip install SynBPS

Installing a specific version from GitHub

A release can also be installed directly from GitHub, for example when a new release is not yet available on PyPI:

pip install git+https://github.com/Mikeriess/SynBPS.git@v1.2.1

Replace v1.2.1 with the tag of the release you need (see the releases page). This requires git to be installed on your machine. Each release also carries the built wheel file (.whl) as an asset, which can be installed with pip install <path or URL of the wheel file> without git.

Once installed, you can:

• Run a simulation experiment with your own models using the End-to-end example notebook for a short demo of SynBPS.
• Or simply generate a single event-log using the example code in the Event-log example notebook. This code example also lets you integrate the power of SynBPS into your own custom code pipeline (for advanced users).
• For the memoryless process, you can also specify the parameters of the distributions manually as shown in the Custom distribution Event-log example notebook.

Documentation

See the official documentation here. The dataprep page describes prefix_data, which turns an event-log into a prefix-log with features and targets for a model, and split_cases, which assigns the cases to the train and test set by time.

Settings

All settings of generate_eventlog and of a design table, with the name used in the paper, the unit and an example value. Time is measured in days. The last column says which process type or entropy level uses the setting.

Some properties of the simulation which are useful to know when building on SynBPS:

• Traces are independent of each other: the resource offset is drawn per event (alg. 8), and there is no shared queue.
• The mean duration Lambda(d, t) depends on the activity and on its position in the trace, so the same activity has a different mean duration at position 2 and position 5.
• All parameters of exponential distributions are means, in days: inter_arrival_time, process_stability_scale and the mean activity durations Lambda(d, t) drawn up to activity_duration_lambda_range. This is the scale parameter of numpy. The paper writes the exponential distribution with a rate λ in eq. 7, eq. 18 and alg. 1, and the rate is 1 divided by the setting. The expected throughput time of a trace (eq. 25) is therefore the sum of the mean durations and offsets of its events.
• The process behind a log (initial probabilities, transition tables and mean activity durations) can be recovered from the settings with recover_dgp (SynBPS.simulation.simulate_eventlog), independent of number_of_traces, or returned together with the log with generate_eventlog(settings, return_dgp=True). A prefix shorter than process_memory uses the table of its own length.
• number_of_traces is not the number of events: the trace length depends on the entropy level, statespace_size, med_ent_n_transitions, p_abs_min and process_memory.
• The entropy levels form a ladder: min_entropy (one deterministic trace), then med_entropy with med_ent_n_transitions from 2 up to every transition (statespace_size + 1 for the process with memory, statespace_size for the memoryless process), then max_entropy. max_entropy is the uniform extreme: the next activity does not depend on the previous ones, so process_memory has no effect there, and check_settings warns when it is above 1. The highest level where every transition is possible and the memory order matters is med_entropy with med_ent_n_transitions = statespace_size + 1.
• run_experiments passes the settings of the run to every user function which declares a settings keyword argument, as the row of the design table. A training function which needs the data-generating process recovers it from them with recover_dgp. See the documentation of the example.

Citation

If you use SynBPS, please cite the corresponding paper. The paper can be cited as:

@article{riess2024synbps,
	title={SynBPS: a parametric simulation framework for the generation of event-log data},
	author={Riess, Mike},
	journal={SIMULATION},
	pages={00375497241233326},
	year={2024},
	publisher={SAGE Publications Sage UK: London, England}
}

Contributing

If you would like to contribute to SynBPS, you are welcome to submit your suggestions, bug reports, or pull requests. Follow the guidelines to ensure smooth collaboration.

Thanks

Jacob Schreiber and Pomegranate team. Joachim Scholderer and Kristoffer Lien.