Produced and consumed resources: a new approach to expanding BPSim capabilities

Over a year has passed since our first blog post on business process simulation in Cardanit. While the feature is still in development, we’ve made significant progress.

We’ve now implemented nearly all BPSim parameters, including time parameters, probabilities and conditions, costs and properties. We’ve also added resource definitions, specifying their available quantities and the amount required for each task. These are essential for creating a digital twin of your process.

Most recently, we introduced new resource types called Produced | Consumed, which aren’t part of the BPSim specification. These resources are fundamental for adding specific details to your simulation, enabling you to expand BPSim capabilities. In this blog post, we’ll explain how they work.

Defining produced and consumed resources in a business process

In Cardanit, you create resources just as you would any other BPMN element. Once created, you can define the resource type in the Simulate tab based on how it’s expected to behave in your business process simulation. Specifically:

• Required resource: Until now, this was the only resource type available. Tasks use this resource to complete their execution.
• Produced | Consumed resource: This new resource type affects availability for other tasks because its quantity can change dynamically. When a task produces this resource, its quantity increases — when a task consumes it, the quantity decreases.

For each resource type, you can specify its total quantity and associated costs, and optionally adjust these values based on different calendars — working days, weekends, holidays, night shifts, and so on. The defined quantity represents the total number of resources available across all tasks and is essential for accurate simulation behavior.

For instance, if you have five pallet trucks in stock, this quantity remains constant throughout the simulation. During task execution, a pallet truck may be temporarily unavailable. If your task “Goods Movement” requires one pallet truck, that truck is used for the duration of the task and released only upon completion. Thus, the total of five pallet trucks is maintained both at the start and end of the task.

Alternatively, resource quantities can be dynamically adjusted based on how many resources each task produces or consumes. Specifically, if a task produces one resource, the quantity increases by one each time a token completes that task. Conversely, if a task consumes one resource, the quantity decreases upon task completion by a token.

For example, following the previous example, if the “Buy a pallet truck”' task produces a pallet truck, the total increases to six. If the “Eliminate a pallet truck” task consumes a pallet truck, the total decreases to four.

When the resource quantity reaches zero, no additional tokens can complete that task until the resource is produced again.

Further details are available in our documentation.

Setting cost types for produced and consumed resources

For required resources, you can define both fixed and unit costs. Fixed costs are incurred every time a token completes a task that requires resources. Unit costs, on the other hand, are time-dependent — the longer a task uses the resource, the higher the cost.

For instance, imagine a task that uses a pallet truck for two hours. If the resource has a fixed cost of €1, that amount is charged once the task is complete. If the resource has a unit cost of €1 per hour, the total cost would be €2, based on the two hours of use.

For produced and consumed resources, unit costs aren’t applicable. When a task uses these resources, only the quantity is updated. Therefore, the only relevant cost is a fixed cost, incurred whenever a token completes a task that produces or consumes the resource.

Why produced and consumed resources matter in BPSim

BPSim is widely accepted as a standard in the business process world. However, produced and consumed resources take its capabilities further.

Dynamically updating resources is a crucial feature in real business processes. For example, a company may hire or fire an employee during a specific activity, or a stock replenishment process may increase or decrease the quantity of materials. These scenarios can all be modeled and simulated using produced and consumed resources.
This feature allows resource quantities to change throughout a simulation. In standard BPSim, while you can modify quantities and rerun simulations to test different scenarios, you can’t modify these parameters during the same simulation.

Moreover, required resources are the only type available in BPSim. These resources allocate resource quantities when a token enters a task and release them upon completion, allowing other tasks to use them. However, BPSim provides no control over which task accesses the resource. In Cardanit, we plan to introduce priority parameters next year. This will allow higher-priority tasks to access resource quantities first.

Even so, priority parameters can become impractical in large processes competing for the same resources. The concept of produced and consumed resources addresses this limitation.

Logistics use case: leveraging produced and consumed resources

Here’s a logistics simulation scenario: trains moving between stations. In this model, tokens represent trains, entering the system at different intervals. For inter-station transfers, trains require a locomotive, which acts as a shared resource. Both the transfer between stations and the time spent at each station are accounted for, including travel time, station dwell time and train stops.
The BPMN model illustrates this scenario, showing trains starting from an origin station and reaching a final station via Station 1 and Station 2, all while using a single locomotive.

We want to simulate a 24-hour period, with an overall train travel duration of five hours broken divided across each task. During this simulation, a new train enters the system every hour and only one locomotive is available.

Defining all parameters is crucial. This includes inter trigger timer, processing times and duration. But what about resources?

We need to create the locomotive resource. Once it’s created, it's essential to define its type and set its parameters to ensure the simulation behaves accurately.

Required resource setup and simulation results analysis

A problem arises in this setup: the locomotive is set as a required resource with a quantity of one, yet each task also requires one locomotive. This creates a conflict, as the single locomotive cannot be used simultaneously by multiple tasks.

When we run this simulation and examine the bar charts for both tokens entering each element and the mean wait time for each task, we observe that:

• Many tokens enter the process, but only one reaches the final destination, with few tokens completing each task. Specifically, the initial tasks show a higher number of completed tokens, while progressively fewer tokens successfully complete the subsequent, final tasks.
• Each task experiences a wait time, reflecting the bottleneck created by the single locomotive.

These results are unrealistic in a real-world scenario. The simulation incorrectly allows a locomotive to become available for a task but not for the following one. Instead, it reverts to serving a train from a previous task, specifically the first task. This explains why the initial task shows a high number of completed tokens, while progressively fewer tokens complete the subsequent tasks — with only one token completed at the end. In effect, the simulation halts a train at the end of a task, only to restart it from the beginning. The problem arises from using the wrong resource type in this context.

Furthermore, the heatmap illustrating the number of waiting tokens shows that tokens are waiting before each task in places where they realistically can’t remain.

Produced and consumed resource setup and updated simulation results analysis

By switching to the new produced and consumed resource type, the system ensures that once a train begins its journey, it completes the entire route before another train can start.

We can achieve this by configuring the resource setting as follows: the "Transfer from starting station to station 1” task consumes one locomotive quantity and the "Transfer from station 2 to final station” produces one locomotive.

With this setup, the locomotive quantity drops to zero after the first task and remains at zero until the final task is completed. Consequently, no other trains can begin their journeys while the locomotive is in use.

The heatmap of mean wait times confirms that only the first task has a non-zero wait time. Values in the table below show that tokens accumulate primarily at the origin station, which serves as the designated waiting area.

Although 25 tokens were initiated, only four completed the simulation — meaning only five trains reached the final station. This outcome is due to the 24-hour simulation window, with a new train entering each hour and each train journey taking five hours.

This simple test case highlights the importance of produced and consumed resources in process simulations, demonstrating their value in modeling realistic logistics scenarios.

BPMN is a powerful tool for logistics companies to visualize and manage their processes. When combined with business process simulation, it can boost productivity, reduce costs, and support data-driven decisions by improving processes. This use case demonstrates the critical role of produced and consumed resources in creating realistic digital twins for logistic operations.

Making a digital twin in logistics a reality

A few years ago, in our blog post BPMN in transportation: Cardanit pivotal role in port logistics analysis, we demonstrated how BPMN could be applied to transportation, and specifically in port logistics. In that case, we achieved three key objectives by building a digital twin of the Trieste Port rail system, estimating rail capacity and optimizing the functional planning and design of the port developments.

A crucial factor in reaching these goals was the ability to model the process within Cardanit and simulate it, even though full simulation capabilities were not yet integrated into the software. Produced and consumed resources, along with the use of properties to characterize trains in the port, were already instrumental.

With the introduction of simulation and these parameters in Cardanit, we’re now ready to re-test similar cases directly within the software. Optimization is still in development, but we’re confident this feature will soon become a reality.

Further reading

Properties and conditions: your parameters to build the digital twin of your business process

Process validation: how Process Simulation helps verify BPMN models

Simulation in Cardanit documentation