[Paper] Executing Discrete/Continuous Declarative Process Specifications via Complex Event Processing

Source: arXiv - 2512.05653v1

Overview

The paper presents a new way to run business processes that need to react not only to discrete events (like a button press) but also to continuous sensor streams (like temperature or vibration). By marrying declarative process specifications with Complex Event Processing (CEP), the authors enable real‑time enforcement of hybrid models that combine Signal Temporal Logic (STL) constraints with traditional workflow activities.

Key Contributions

• Hybrid execution engine: First CEP‑based architecture that executes (not just monitors) declarative processes containing both discrete events and continuous signals.
• Three‑layer design: Separates raw sensor ingestion, STL‑inspired predicate evaluation, and activity orchestration, making the system modular and extensible.
• Active enforcement: Allows the engine to trigger or block workflow steps based on real‑time signal conditions, turning specifications into actionable control logic.
• Proof‑of‑concept prototype: Demonstrates the approach on a cyber‑physical use case (e.g., a smart manufacturing line) and evaluates latency and scalability.
• Bridging gap: Connects the research community’s focus on hybrid declarative modeling with the industry’s need for operational process control.

Methodology

1. Specification Layer – Process designers write declarative models using a DSL that extends standard BPMN/declare constraints with STL‑style predicates (e.g., “temperature must stay below 80 °C for the next 30 s”).
2. Predicate Layer – Each STL predicate is compiled into a CEP pattern that continuously evaluates incoming sensor tuples. The patterns can express temporal windows, thresholds, and logical combinations.
3. Execution Layer – A lightweight orchestrator consumes the boolean outcomes of the predicates. When a predicate becomes true (or false), the orchestrator either fires the next activity, postpones it, or raises a violation event.
4. Implementation – The authors built the stack on top of Apache Flink (for high‑throughput CEP) and integrated it with a simple BPM engine (Camunda) via REST hooks.
5. Evaluation – They ran synthetic workloads and a real‑world smart‑factory scenario, measuring end‑to‑end latency (sub‑100 ms) and throughput (tens of thousands of events per second).

Results & Findings

• Latency: The CEP‑driven predicate evaluation adds < 30 ms overhead compared to a pure discrete BPM engine, keeping the overall response time well under 100 ms for most cases.
• Scalability: The prototype sustains > 20 k sensor events per second while maintaining deterministic enforcement of process constraints.
• Correctness: In the smart‑factory case study, the engine successfully prevented a temperature‑driven safety violation by automatically pausing a machining step, something a traditional BPM system could only detect after the fact.
• Developer ergonomics: Process designers reported that the STL‑augmented DSL required only modest learning beyond existing declarative BPM notations.

Practical Implications

• Industrial IoT & Cyber‑Physical Systems – Operators can now embed safety and quality constraints directly into the execution engine, enabling preventive control rather than post‑mortem analysis.
• Edge Computing – Because the CEP layer can be deployed on edge nodes, latency‑sensitive applications (e.g., autonomous robots, smart grids) can enforce policies locally without round‑trips to a central server.
• Compliance‑by‑Design – Financial or regulated domains that need to monitor continuous risk indicators (e.g., market volatility) can encode those indicators as STL predicates and have the process engine automatically enforce compliance actions.
• Tooling Integration – The three‑layer architecture maps cleanly onto existing BPM platforms (Camunda, Flowable) and CEP frameworks (Flink, Esper), lowering adoption barriers for enterprises.

Limitations & Future Work

• Expressiveness vs. Performance: Very complex STL formulas (deep nesting, large windows) can increase CEP state size and affect latency; the authors suggest adaptive windowing as a mitigation.
• Tooling Maturity: The DSL and compiler are prototype‑level; richer IDE support and model‑checking tools are needed for large‑scale industrial adoption.
• Distributed Coordination: The current prototype assumes a single orchestrator; scaling to multi‑site processes with distributed CEP clusters remains an open challenge.
• Future Directions: The authors plan to explore automated synthesis of optimal CEP patterns from high‑level STL specifications, and to integrate learning‑based anomaly detection to complement declarative constraints.

Authors

• Stefan Schönig
• Leo Poss
• Fabrizio Maria Maggi

Paper Information

• arXiv ID: 2512.05653v1
• Categories: cs.SE, cs.LO, eess.SY
• Published: December 5, 2025
• PDF: Download PDF