The increasing integration of IoT technologies into business processes has led to the emergence of
IoT-enriched event logs, as interconnected devices generate granular, time-stamped events. These logs
extend traditional process execution data with contextual information from IoT devices such as sensors
and actuators, allowing more sophisticated analysis and real-time process insights [
To address this challenge, we propose a common metamodel for IoT-enriched event logs named the
CORE metamodel [
CEUR
ceur-ws.org manipulating and parsing of IoT-enhanced process data. (3) Semantic mapping of IoT-data to processaware events.
Given the considerable number of IoT-enriched event logs and software tools currently available for diferent IoT-enriched event log formats, a toolbox for IoT-enhanced process mining appears to be promising; e.g., to convert existing logs into the common metamodel format. To this end, we have developed BROOM, a Python-based toolbox for IoT-enhanced process mining, which enables the bidirectional exchange of event logs between XES-based formats and the proposed OCEL-based CORE metamodel. A central challenge of a common metamodel format lies in the mapping of attributes across semantically and structurally divergent metamodels.
To make BROOM more accessible, we implemented a web-based user interface that guides users through the available functions, such as the transformation procedure. The interface provides a nodebased editor that allows the user to construct a transformation pipeline by connecting predefined nodes.
The CORE metamodel [
The CORE metamodel distinguishes between two central constructs: events and objects, adhering to the object-centric modeling paradigm established by OCEL 2.0. Events are further categorized into IoT-Events, representing physical observations from sensors, and process events, denoting transitions in the execution lifecycle of activities. Objects are likewise classified into data source objects (e.g., sensors, information systems), business objects (e.g., batches, tanks, customer orders), and general objects (e.g., subprocesses, resources). Key structural features include: • Support for diferent levels of data granularity , enabling representation of low-level sensor observations and high-level business events. • A flexible case notion , allowing events to be associated with multiple entities rather than a single process instance. • Explicit representation of semantic annotations and metadata, improving the interpretability and reuse of logs. • Full traceability across abstraction layers, including derivation links between raw sensor data, aggregated IoT-Events, and process events. • Compatibility with the OCEL 2.0 standard to take advantage of existing tools and ensure widespread adoption.
Compared to previously proposed models, such as DataStream [
In summary, the CORE metamodel provides a modular and extensible foundation for integrated representation, analysis, and exchange of IoT-enhanced event data, aligning with current standards and emerging requirements in process mining research.
BROOM has been developed as a web application using Angular1 for the frontend and Flask2 as REST functionality. The implementation of the CORE metamodel is developed in Python@3.12. The source code of BROOM can be found at https://github.com/chimenkamp/IOT-PM-Suite for the frontend and https://github.com/chimenkamp/IOT-PM-Suite-Backend for the backend, and a deployed version can be accessed using the following link https://broom-iot-toolbox.onrender.com/.
The goal of the implementation is to smoothly parse an arbitrary log into the CORE metamodel format. For this, BROOM relies upon a node-based user interface to intuitively create a parsing pipeline (see Figure 1). In general, the pipeline depends on the use case and dataset, but will subsequently perform the following steps: • Reading the data: The source dataset can be of type CSV, XML, YAML, or JSON. Internally, all diferent data types are mapped into a data frame structure. This functionality is provided by the Read File node. • Data Processing: BROOM ofers multiple nodes to process the data (e.g., Data Filter, Data Mapper, Column Selector, Attribute Selector ). For example, the Column Selector takes the Raw Data output of the Read File Node as an input and covert it into a Series. The Data Filter and Data Mapper (Input = Series, Output = Series) can apply filters to the series. The Attribute Selector can be used to select attributes from these series. • CORE Model Conversion: Selected attributes are used to construct classes provided by the CORE metamodel. BROOM ofers corresponding nodes: the IoT-Event node, which accepts ID, Type, Timestamp, and Metadata as inputs, all connectable to the Attribute Selector node; and the Process Event, which additionally requires an Activity Label. Objects are similarly created with ID, Type, Class, and Metadata, supported by utility nodes to generate unique IDs or select object classes. • Construction of the CORE Model: Finally, outputs from Process Event, IoT-Event, and Relationships nodes are combined into a dataset in CORE format. The data can be displayed or exported in OCEL format via Output and Export nodes. Leveraging the object-centric process mining (OCPM) ecosystem also enables discovering object-centric process models by integrating IoT-Events, Process Events, and Event-To-Event Relationships directly in the browser.
BROOM’s architecture is web-based and is therefore structured into two layers (i.e., Frontend and Backend), as shown in Figure 2. Users interact mainly with the site through the Frontend. The page layout is structured into two components (i.e., Sidebar and Editor). (1) The Sidebar incorporates the main functionalities and the collection of usable nodes. The user can drag and drop nodes from the sidebar into the editor component. Additionally, the sidebar also has the functions to Save/Load a 1https://angular.dev/ 2https://flask.palletsprojects.com/en/stable/ pipeline, upload a dataset to the server, or clear the editor. Mappings can be saved to a JSON file and later uploaded to restore the pipeline. Lastly, the sidebar contains a small legend containing the available port types (i.e., the connection between nodes). (2) A node will be displayed in the editor when a user drags and drops it to a certain position. The node consists of the outer and inner layer. The outer layer contains the input (left) and output (right) ports. Two ports can be connected by dragging from one output port to the input port of another node. Only ports of the same color can be connected, and one output port can be connected to multiple input ports. The inner layer of the node contains diferent UI elements to manipulate the behavior (e.g., the column identifier of the Column Selector node). In addition to the general element of the UI, the frontend also performs rudimentary validation tasks before the pipeline is forwarded to the backend for processing (i.e., starting with data and ending with the CORE metamodel, no dangling nodes, all nodes have the required inputs and outputs).
After validation, the pipeline is propagated to the backend via a REST service. The first component of the Backend is the REST-API, providing routes for posting datasets, pipelines, or pipeline results. Posting a pipeline definition triggers the Pipeline Executor, which first flattens the pipeline typologically into sequences of executable steps. Due to potentially unbounded node connections, pipelines may lfatten into multiple, possibly overlapping sequences. During sequence processing, the Pipeline Executor loads the corresponding Node Implementations—classes describing node behavior—from the store. For example, the Column Selector node receives a DataFrame and a column identifier, returning the specific column as a series. The results are stored associated with node IDs. A node is triggered only when all its predecessors’ results are available. Finally, once all predecessors of the CORE metamodel node are executed successfully, the required data is passed to the implementation layer, translating the CORE standard directly into OCEL.
BROOM is a stable and production-ready tool, designed for use by researchers, practitioners, and
educators. Its functionality has been validated against the DataStream extension for XES [
The tool is fully open source under the MIT license, making it suitable for both academic and commercial applications. It is available on GitHub at https://github.com/chimenkamp/IOT-PM-Suite for the frontend and https://github.com/chimenkamp/IOT-PM-Suite-Backend for the backend, with a live instance accessible at https://broom-iot-toolbox.onrender.com/. A “Getting Started” guide and example projects are provided to ensure smooth onboarding. Additionally, a video showcasing a simple pipeline can be found here https://github.com/chimenkamp/IOT-PM-Suite/tree/main/docs/
BROOM’s mature state is reflected in its stable performance, complete feature set, and modular, extensible design. It supports a wide range of data formats and streaming inputs, and produces outputs compatible with object-centric process mining frameworks. Additionally, for use cases that cannot be modeled through the frontend, users can directly use BROOM’s Python implementation to select the desired functionality.
This work received funding by the Deutsche Forschungsgemeinschaft (DFG), grant 496119880 and was supported by the Internet of Processes and Things (IoPT) community: https://zenodo.org/communities/ iopt/about.
During the preparation of this work, the author(s) used ChatGPT, Writefull, and LanguageTool in order to: Paraphrase and reword, improve writing style, and Grammar and spelling check. After using this tool/service, the author(s) reviewed and edited the content as needed and take(s) full responsibility for the publication’s content.