PMPBench Resource for Process Mining
- PMPBench resource is a benchmarking framework with defined protocols to rigorously evaluate distributed process mining techniques across various architectures in cyber-physical systems.
- It employs centralized, fog, and fully distributed topologies to simulate realistic environments, enabling assessment of communication overhead, processing time, and resource utilization.
- The framework’s experimental workflows, detailed metric logging, and reproducibility features provide actionable insights into algorithm performance and scalability under varied workloads.
PMPBench Resource
PMPBench is a term used for several distinct, high-impact academic benchmarking resources that support reproducible, rigorous evaluation of algorithms in specialized domains. While the name appears in multiple contexts, most notably in distributed process mining for cyber-physical systems, medical image synthesis, and parametric timed model checking, all incarnations of PMPBench share a commitment to rich data curation, defined performance metrics, and transparent protocols. This article provides a detailed review of the core PMPBench frameworks, with an emphasis on the distributed process mining variant as detailed in "DPM-Bench: Benchmark for Distributed Process Mining Algorithms on Cyber-Physical Systems" (Reiter et al., 14 Feb 2025).
1. Benchmark Architectures and Design Principles
PMPBench was introduced to address the lack of a standardized methodology for evaluating distributed process mining (DPM) algorithms in cyber-physical systems (CPS). In such settings, event data is generated across heterogeneous, geographically dispersed nodes—often edge devices with limited compute and network resources. The benchmark supports evaluation in three principal topologies:
- Centralized: All event streams are relayed to a central cloud node for mining.
- Decentralized/fog: Subnet-level aggregation is performed at fog nodes, which then merge their results.
- Fully distributed: Edge nodes communicate peer-to-peer to synthesize a global view, such as a Directly-Follows-Graph (DFG).
The architecture consists of:
- Edge nodes: Emit local event streams, execute mining/reduction via Hardware Interaction Instructions (HIIs), maintain partial logs and local process models.
- Fog/cloud nodes: Aggregate partial models or events, execute heavier analytics, and serve user interaction.
- Networking: Abstracted via HIIs that encapsulate the cost and payload of communication actions, modeling bandwidth and latency.
The primary focus is on DFG-based mining directly from distributed event streams, with an emphasis on scalability, resource constraints, and communication costs.
2. Evaluation Modes, Workloads, and Topologies
PMPBench accommodates a spectrum of distributed mining strategies:
- Fully Centralized (Cloud-only): All events flow to a single cloud node; maximally simple, but expensive in bandwidth.
- Hybrid/Fog: Local subnet aggregation of process models, with infrequent inter-fog communication and merging.
- Fully Decentralized (Edge): Peer nodes exchange queries for predecessor activities to incrementally construct the global DFG.
- EdgeMiner Optimization: Adds frequency-based routing and query minimization to reduce network overhead.
Workloads are synthesized using the Distributed Event Factory, allowing fine control over:
- Event arrival processes (e.g., Poisson, bursty) and rates per node.
- Log size (spanning – events over sites).
- Heterogeneity in event patterns, reflecting the non-uniformity of real CPS deployments. A process model request is typically issued after every 10 events to simulate user queries and to stress model delivery pathways.
3. Performance Metrics and Measurement Protocols
PMPBench provides precise quantitative metrics, defined in LaTeX and implemented via HII tracing:
- End-to-End Processing Time :
where is the execution time for step on event under algorithm .
- Network Communication Overhead 0 (in bytes):
1
2 is the set of all send instructions.
- CPU Utilization 3 and Memory Footprint 4:
5
6
where 7 is the fraction of capacity used.
- Scalability Metrics: Load capacity 8 and resource demand 9 are evaluated against a user-defined SLO, e.g., network utilization 0.
These metrics are collected across all operations using an instrumentation library that hooks into each algorithm's HII calls.
4. Experimental Workflow and Benchmarking Procedure
The standardized protocol for an evaluation cycle in PMPBench includes:
- Topology Deployment: Definition of node (edge/fog/cloud) types, their HIIs, and network parameters in a configuration file.
- Workload Generation: Initiation of event generators per node, with customizable arrival rates and distributions.
- Algorithm Execution: Injection of events into node-local mining processes, periodic user model requests, and distributed merging routines.
- Metric Logging: Stepwise and end-to-end measurement and aggregation of time, bandwidth, CPU, memory.
- Results Export: Output as CSV and pre-rendered plots for post hoc analysis.
A canonical pseudocode for the baseline edge algorithm (DFG-miner):
8
5. Empirical Results and Insights
In a reference configuration with 7 edge nodes and mixed Poisson arrival streams:
- Processing time per event: Cloud DFG-miner 11.8 ms (constant), Fog 22.3 ms, Edge-naïve 33.5 ms, EdgeMiner 44.0 ms initially but converging to 51.6 ms after warm-up.
- Network utilization: Cloud 25%, Fog 15%, Edge-naïve baseline 40% with 80% spikes, EdgeMiner initial 40% decaying to 10%.
- Memory consumption grows linearly due to non-deleting logs; EdgeMiner incurs 620% more for metadata.
- Load capacities: Fog supports roughly 7 that of edge, naive edge-only is limited to half, and EdgeMiner achieves a 20% gain in effective edge capacity.
These results quantify the trade-offs between communication, computation, and storage imposed by the network architecture and distributed algorithm choice. Notably, the EdgeMiner optimization is able to nearly halve the steady-state network load relative to naive implementations.
6. Usage, Reproducibility, and Open Resource Access
PMPBench and its supporting tools are available at:
Typical dependencies include Java (benchmark harness), Python/Java wrappers, and a YAML-based configuration system. The standard workflow includes:
- Template-based editing of
config.yamlto specify topology and parameters. - Execution via
./run_benchmark.sh –config config.yaml –alg <algorithm-class> –out results/. - Results collected as CSV and plotted PNG metrics (
processing_time.csv,resource_utilization.csv,scalability_capacity.csv,plots/*.png).
This workflow ensures full reproducibility and transferability of results across new DPM algorithms, hardware settings, and deployment scales.
7. Related PMPBench Resources and Nomenclature
The PMPBench designation is also used—distinctly—in other communities:
- Medical Image Synthesis: "PMPBench: A Paired Multi-Modal Pan-Cancer Benchmark for Medical Image Synthesis" (Chen et al., 22 Jan 2026) is a resource for benchmarking generative models under fully paired, organ-rich CT/MRI datasets, supporting 1-to-1, N-to-1, and N-to-N image translation evaluations.
- Parametric Timed Model Checking: The PMPBench/IMITATOR library (Étienne, 2018) provides a suite of benchmarks for evaluating symbolic PTMC algorithms, focusing on real-time and hybrid systems with parametric clock constraints.
In all cases, PMPBench denotes a rigorously curated, protocol-driven environment for methodologically fair evaluation within its target problem space.
References
- DPM-Bench (Distributed Process Mining): (Reiter et al., 14 Feb 2025)
- Paired Multi-Modal Pan-Cancer Benchmark: (Chen et al., 22 Jan 2026)
- IMITATOR Benchmark Library for PTMC: (Étienne, 2018)