Collaborative Modeling of BPMN and HCPN: Formal Mapping and Iterative Evolution of Process Models for Scenario Changes

Abstract

Dynamic and changeable business scenarios pose significant challenges to the adaptability and verifiability of process models. Despite its widespread adoption as an ISO-standard modeling language, Business Process Model and Notation (BPMN) faces inherent limitations in formal semantics and verification capabilities, hindering the mathematical validation of process evolution behaviors under scenario changes. To address these challenges, this paper proposes a collaborative modeling framework integrating BPMN with hierarchical colored Petri nets (HCPNs), enabling the efficient iterative evolution and correctness verification of process change through formal mapping and localized evolution mechanism. First, hierarchical mapping rules are established with subnet-based modular decomposition, transforming BPMN elements into an HCPN executable model and effectively resolving semantic ambiguities; second, atomic evolution operations (addition, deletion, and replacement) are defined to achieve partial HCPN updates, eliminating the computational overhead of global remapping. Furthermore, an automated verification pipeline is constructed by analyzing state spaces, validating critical properties such as deadlock freeness and behavioral reachability. Evaluated through an intelligent AI-driven service scenario involving multi-gateway processes, the framework demonstrates behavioral effectiveness. This work provides a pragmatic solution for scenario-driven process evolution in domains requiring agile iteration, such as fintech and smart manufacturing.

1. Introduction

Under the wave of digital transformation driven by AI technology, business processes are undergoing a structural leap from a closed architecture to an ecological collaboration paradigm [1]. Traditional internal processes rely on localized applications to form closed systems with clear boundaries and fixed interaction patterns. However, modern business processes have evolved into Internet-based, cross-organizational collaborative networks that deeply integrate mobile devices, distributed web services, and edge computing nodes to form a decentralized, highly dynamic operating system [2]. In this context, business requirements exhibit multi-dimensional evolutionary characteristics: in the scene dimension, user interaction scenarios migrate from centralized services to fragmented micro-services; in the time dimension, the real-time data flow-driven decision mechanism evolves from predefined rules to autonomous intelligent response [3]; in the system dimension, the business process lifecycle undergoes fundamental reconstruction -from static ‘design-deployment’ to dynamic ‘perception-adaptation-optimization’. In the system dimension, the business process lifecycle undergoes a fundamental reconstruction—from the static linear mode of “design-deployment” to the dynamic closed-loop mode of “perception-adaptation-optimization”. In the context of scene fragmentation, real-time interaction, and decision-making autonomy, business process evolution faces multiple challenges: on the one hand, it is necessary to improve the agile modeling capability of the model to quickly respond to changes in demand; on the other hand, it is necessary to establish a formal validation mechanism of the evolution process to ensure the validity of the evolution and the consistency of behavior.

As an early standard language for process modeling, Business Process Modeling Notation (BPMN) has become a mainstream tool for full lifecycle modeling, from requirements analysis to system implementation, due to its intuitive graphical representation [4]. However, with the promotion of digital transformation and generative artificial intelligence technologies, the traditional BPMN model shows significant limitations in supporting the dynamic evolution of processes [5,6,7,8]:

• Lack of common semantic specification.

The semi-structured metamodel of BPMN lacks formal mathematical definitions, and there is tool dependency in the semantic interpretation of key elements (e.g., events and gateways) [7]. This semantic ambiguity leads to the possibility of behavioral discrepancies between BPMN engines executing the same model under different platforms. Especially in the dynamic process evolution, the validation of critical properties like liveness and safety lacks a unified benchmark, which makes it difficult to ensure the correctness of the evolved system.

2.

Absence of effective dynamic verification.

BPMN mainly supports static modeling and lacks the capability to formally validate process execution. When the business scenario changes, the model cannot detect potential deadlocks, livelocks, or other issues, leaving dynamic adjustments to complex business processes unverified [8]. In addition, converting BPMN models to executable formats introduces challenges such as information loss and state-space explosion, which make traditional methods unsuitable for validating evolutionary behaviors in complex process models.

To address the above challenges, this paper proposes a collaborative modeling framework that integrates Business Process Management Notation (BPMN) with hierarchical colored Petri nets (HCPNs), the core of which is embodied in three aspects:

• Formal mapping rules.

The established BPMN-HCPN formal mapping rules can map business objects (e.g., user roles, cargo status, etc.) through color sets, which resolve semantic ambiguities and, at the same time, become an executable model to achieve formal validation of process evolution behaviors.

2.

Modular and hierarchical evolution mechanism.

By leveraging gateways and subprocesses, we divide the complex BPMN model into BPMN modules, and we achieve incremental evolution by locally updating the evolution behavioral modules, which reduces the validation complexity while improving the model evolution efficiency.

3.

Evolution-iterative architecture.

Based on the model update detection method, the CPN Tools simulation engine realizes the automated iteration of “scenario change → model adjustment → attribute verification”, which avoids repetitive mapping and reduces the modeling cost.

The rest of the paper is organized as follows: Section 2 reviews the research progress and shortcomings in BPMN evolution modeling; Section 3 introduces the relevant definitions; Section 4 outlines the BPMN-HCPN collaborative modeling framework and the specific evolutionary behavior; Section 5 verifies the approach with an AI problem service scenario as a case; and Section 6 summarizes contributions and discusses future directions.

2. Relevant Works

A process is a combination of activities based on the repetition of regular fixed tasks in human production activities, and in engineering and business fields, a business process is a set of atomized activity entities with clear input and output definitions, and it defines the temporal logical relationship between activities through state transfer rules [8]. Evolution is a universal characteristic of complex systems in continuous development and change; on this basis, the process of process evolution actually refers to the process of process optimization of the system using the uncertainty of the external environment and internal variability, and its core mechanism lies in screening or eliminating the changes that fail to achieve the expected results and, at the same time, continue to optimize the changes that have already been successful in maintaining its own vitality [9,10].

In recent years, the research on process evolution methods has shown a multi-dimensional exploration. Through a systematic literature review, Song et al. [11] classified process changes into two types: static and dynamic; static process changes focus on modifying the process model, while dynamic process changes focus on adjusting process instances at runtime. Lehnert et al. [12] proposed a generic graph-based change-type description method that distinguishes between atomic and combinatorial change types and constructs a change taxonomy to support activities such as refactoring, impact analysis, and regression testing in software development. These classifications provide a multidimensional perspective and framework for the in-depth study of model evolution.

In addition, Ortiz et al. [13] proposed a protocol for managing microservice change propagation from different granularities, aiming to ensure that these changes can be seamlessly integrated into the remaining microservice BPMN fragment and the global BPMN model of the service portfolio to analyze the service-layer evolution. Vrinda et al. [14] proposed a tool for tracking and reasoning about the evolution of process architectures, which uses graph-based analysis techniques to assist in reasoning about evolving process architectures. However, all of them maintain a static modeling of process architectures and do not include executable models to support verification of dynamic behavior.

In the realm of formal modeling, research methodologies are predominantly classified into three distinct categories. The first category encompasses the utilization of mathematical methods, such as CSP [15] and the Pi algorithm [16], to elucidate behavioral semantics. The second category involves the employment of logic formalization methods, including First-Order Logic [17] and Rewrite Logic [18], to systematically analyze BPMN models. The majority of researchers employ Petri nets to construct formal models (e.g., YAWL [19], CPN [20], TPN [21], etc.). Petri nets, as a flow-oriented graphical tool, verify the model’s correctness, deadlocks, reachability, and other attributes, and they provide a formal description method for process model evolution [8]. Medina-Garcia et al. [22] proposed a business process modeling algorithm based on Petri nets, which converts natural language descriptions of processes into formal models by defining infrastructures such as sequential, selective, and parallel. Combined with discrete-event simulation techniques, probability distributions (e.g., normal and uniform) are used to quantify the execution time of activities, and processivity is analyzed through matrix equations and trigger vectors.

With respect to a formal analysis of the process evolution, as illustrated in Table 1, Qiang Hu et al. [23] developed a series of service process structure evolution operations (e.g., projection, linking, synthesis, substitution, etc.) and constructed a formal process model for various demand scenarios, utilizing logical Petri nets as a modeling tool. Krishna et al. [24] explored a formal model from BPMN to LNT process algebra and LTS formal model transformation methods using process algebra to define different types of evolution such as conservative, inclusive and exclusive, selective, context-aware, etc., and proposed a set of methods for detecting business process evolution at the model level, which provides strong support for process optimization and improvement. Zonghua Li et al. [25] designed a checking algorithm to identify the differences between the original BPMN model and the updated BPMN model, and they defined the evolution rules of the Extended Petri Net (EPN) model to represent the changes in the BPMN model to avoid model confusion and token loss. Hsieh et al. [26] addressed the problem of process planning for sustainable infophysical production systems by proposing a Cyber World model based on discrete-time Petri nets (DTPNs), generating process configurations by combining DTPN sub-models with different operations and combining them with the Adaptive Neighborhood Search Differential Evolutionary Algorithm (SaNSDE) to achieve a dynamic optimization of the process.

Table 1. Different methods in the literature related to process model evolution.

Authors (Year)	Methods	Evolution	Applied Scenarios	Limitation
Flavio et al. (2018) [16]	π-calculus	Static	Business process collaborations	Lack of evolutionary operations
Hu et al. (2018) [23]	Logical Petri net (LPN)	Dynamic	Service network structure changes	Overall structural changes do not support local updates
Luca et al. (2019) [27]	Petri net	Dynamic	Dynamic workflows	Lack of evolutionary operations
Li et al. (2021) [25]	Extended Petri net (EPN)	From static to dynamic	BPMN structure evolution	The formal validation of state migration was not considered
Ortiz et al. (2022) [13]	Bottom-up evolution protocol	Static	BPMN microservice compositions	Lack of formal validation
Duran et al. (2022) [28]	Business process refection (BPR)	Static	Process structure redundancy elimination and performance optimization	Refactoring rules need to be defined manually
Hsieh et al. (2024) [26]	Discrete timed Petri nets (DTPNs)	Dynamic	Cyber–physical systems (CPSs)	The validation is more applicable to sequential processes and do not have specific evolutionary operations
This article	Hierarchical colored Petri net (HCPN)	From static to dynamic	The BPMN collaboration process	Suitable for complex process evolution analysis

In this paper, we propose a dynamic BPMN-HCPN cooperative evolution model, grounded in the definition of evolution behaviors and evolution rules. This model enables the validation of evolution behaviors, a reduction in evolution complexity, and the enhancement of evolution efficiency through formal modeling.

3. Relevant Definitions

3.1. BPMN

Business Process Model and Notation (BPMN) is a standardized graphical modeling language designed to systematically describe the logic, execution order, and participating roles of business processes through unified symbols. The core elements of BPMN include flow objects (events, activities, and gateways), connecting objects (sequence flows and message flows), data objects, and swimlanes (pools and lanes). As shown in Figure 1, these elements can be combined to construct business process diagrams that adapt to diverse business requirements. BPMN supports three primary modeling paradigms: orchestration, choreography, and collaboration [8]. Among these, the collaboration process integrates orchestration and choreography, utilizing swimlanes to partition participants. This approach supports hybrid business process modeling and is capable of describing diverse transactional and interactive relationships within processes [29].

Figure 1. Basic BPMN modeling elements.

Definition 1.

(BPMN Collaboration Model)

A BPMN collaboration model is defined as a multiset

$$BC=\left\{B{P}_i,M,S_L\right\}(i\in I)$$

where the following applies:

1.

Business Process  $B{P}_i$: represents the internal business flow of the i-th pool, structured as

$$B{P}_i=(V_i,E_i,L_i)$$

which includes the following:

• (1)

  Node set  $V_i=V_{Ai}\cup V_{Ei}\cup V_{Gi}$, composed of three types of nodes:

  (a)

  $V_{Ai}$: activity nodes, representing tasks or Sub-process within the process;

  (b)

  $V_{Ei}$: event node;

  (c)

  $V_{Gi}$: gateway nodes.

  (2)

  Intra-pool sequence flows  $E_i\subseteq V_i\times V_i$  describe the execution order of nodes within the pool.

  (3)

  Line  $L_i$: Metadata including data objects and lane assignments within pool i.

2.

Message flow collection M: inter-pool interactions via message exchanges:

$$M\subseteq \underset{i\ne j}{\cup }{V}_i\times V_j$$

where  $V_{Ei}$  and  $V_{Ej}$  denote event nodes in distinct pools i and j.

3.

Swimlane  $S_L$: a set of swimlanes partitioning participants into organizational roles or responsibilities:

$$S_L=\{s_1,s_2\dots ,s_k\}$$

Each  $s_p\in S_L$  maps to a pool, enforcing role-based access control and responsibility boundaries.

3.2. Petri Net

An ordinary Petri net consists of places, transitions, and arcs.

Definition 2.

Petri net

Set a quad group,  $PN=(P,T,A,M_0)$, where the following applies:

• P (place) is the set of finite non-empty libraries, and $P=\{p_1,p_2,\dots ,p_n\},P\ne Ø$  denotes the state or condition;
• T (transition) is a finite non-empty variation set, and $T=\{t_1,t_2,\dots ,t_n\},T\ne Ø$  denotes events or activities;
• $A_r$ (arc) is a directed set of arcs and can only be pointed at via a depot to a variation or a variation to a depot, and $A_r\subseteq (P\times T)\cup (T\times P)$, $P\cap T=P\cap A_r=A_r\cap T=Ø$;
• ${\mathrm{M}}_0$ denotes the initial identity, $M_0:P\to \left\{0\right\}\cup Z+$; for the case of all place’s tokens at the initial moment, the token represents the object.

Definition 3.

Pre-set and post-set.

Taking node n as the marking point, the set of the previous nodes of the current node n is called the pre-set of sequences, denoted as ${}^{\ast }n$, ${}^{\ast }n=\{y\in P\cup T|(y,x)\in N\}$; the set of the latter nodes of the current node n is called the post-set of sequences, denoted as $n^{\ast }$, $n^{\ast }=\{y\in P\cup T|(x,y)\in N\}$.

Definition 4.

Basic properties of the Petri net (liveness, fairness, deadlock, and reachability).

Liveness: the possibility that a transition in a system will be triggered in a certain state.

Fairness: the opportunity that every transition in the system can be triggered.

Deadlock: No transition in the system can be triggered, and the process is completely stalled. That is, there is a mark, $M_k$, so that no $t\in T$ can be triggered, and $M_k$ is terminated.

Reachability: the ability to reach a specific state from an initial state, triggered by a series of transition.

Definition 5.

The transition trigger condition of PN:

$\forall t\in T$, t can be triggered if and only if

$$\forall p\in •t:M(p)\ge W(p,t)$$

In which $•t=\{p\in P|(p,t)\in F\}$ is the input place of t; $W:F\to {{\rm N}}^{+}$ is the arc-weight function.

3.3. Hierarchical Colored Petri Net

An HCPN (hierarchical colored Petri net) is an extension of a Petri network. It can determine different types of nodes through a color set and express sub-processes and nesting relationships through hierarchy so as to improve the expression ability of the model, reduce the complexity of model analysis, and avoid problems such as state-space explosion [6,30]. The CPN and HCPN models are defined as follows.

Definition 6.

CPN model:

Set a hexadecimal set,

$$CPN=(\Sigma ,P,T,A_{\mathrm{r}},\mathrm{f},M_0)$$

where the following applies:

• P, T, $A_r$, and $M_0$ are the same with the PN set;
• Σ (color) denotes the set of colors and is non-empty finite;
• f (function) denotes a function, $f=\{f_C,f_G,f_E\}$, $f_C$ denotes a color function, $f_G$ denotes a guard function, and $f_E$ denotes an arc expression function.

Definition 7.

HCPN model:

define the HCPN model as a six-tuple,

$$HCPN=\{CP{N}_{N0},HCPN(CP{N}_{N0}),\Sigma ,f,H,Port\}$$

where the following applies:

• The top-level Petri net $CP{N}_{N0}=(P{N}_0,\Sigma {,\mathrm{f}}_0)$ is also known as the root process;
• The sub-network collection $HCPN(CP{N}_{N0})=\{(t_i,CP{N}_{Ni},HCPN(CP{N}_{Ni}))|t_i\in T_{n0}\}$, in which $T_{n0}\subseteq T_0$ is the substitution transitions;
• Σ (Color) represents the global color collection, and all subnetworks share a unified color set;
• f (function) represents the global set of functions to ensure the behavior consistency between subnetworks;
• $H\subseteq T\times HCP{N}_{Sub}$ is the hierarchical mapping function, which can map the parent network change to the subnetwork and inherit its behavior logic;
• The port is a set of port libraries used to connect the interfaces of the parent network to the child network to ensure consistency in the transfer of tokens. It consists of an in-port, an out-port, and an I/O port. The port library of the subnet must be the same color as the neighboring libraries of the parent net, that is: $\forall p_{parent}\in Port(t_i),\exists p_{sub}\in P_i,\Sigma (p_{sub})=\Sigma (p_{parent})$.

4. BPMN-HCPN Collaborative Modeling

4.1. BPMN-HCPN Model Evolution Framework

The process of mapping the updates from the BPMN model to the HCPN model is pivotal in order to construct the HCPN evolution model. As demonstrated in Figure 2, the framework of the BPMN-HCPN collaborative modeling process is as follows: through the mapping mechanism, the BPMN model is transformed into the HCPN model, thereby enabling synchronous BPMN-HCPN update to facilitate formal analysis of business process evolution. The following steps are involved in the evolution process:

Figure 2. Basic framework of BPMN-HCPN model evolution process.

• Business process modeling phase.

  (1)

  Establishment of BPMN initial model: according to business requirements and business scenarios, establish the top-level BPMN collaboration model and output sub-modules after hierarchical and modular processing.

  (2)

  Evolutionary behavior analysis: identify scenario change requirements, define the set of evolutionary operations, $Op=\left\{Insert,Delete,Replace\right\}$, and output the updated BPMN model.

• Formal mapping stage.

  (1)

  Modular hierarchical mapping: define modular decomposition rules that map BPMN elements to the corresponding HCPN modules.

  (2)

  HCPN modeling: synthesize the mapped HCPN subfragments into HCPN nets, where the top network $CP{N}_{N0}$ represents the BPMN backbone process, and the subnet set $HCPN(CP{N}_{N0})$ encapsulates all sub-processes.

• Dynamic evolution phase.

  (1)

  Model evolution identification: compare the BPMN model before and after evolution to determine the evolution existence region and operation execution set.

  (2)

  Evolutionary operation execution: perform related evolution operations based on the identified evolution data to build the HCPN evolution model.

• Validation and feedback phase.

  (1)

  State-space analysis: generate an accessible map based on the evolved HCPN model, and analyze key attributes:

  (2)

  If inaccessibility or activity conflict is detected, adjust back to the evolutionary phase, and iterate until verification.

4.2. Modular Decomposition of the BPMN Model

For complex BPMN models in cross-organizational collaboration scenarios, their modular decomposition needs to take into account structural decoupling and semantic consistency [31]. In this paper, a modular hierarchical decomposition method is constructed based on pool boundaries, sub-processes, and gateway pairs through a three-level progressive strategy (as shown in Figure 3), and the steps for partitioning the model are as follows:

Figure 3. BPMN module division.

Step 1 Region splitting: (pool-based structural partitioning).

Using the pool as a boundary, the BPMN model is divided into independent regions, each corresponding to a business role or organization unit.

Set $S=(Pl,V_i,F)$ ($i=1,2,\dots ,k$), where $Pl=\{p{l}_1,p{l}_2,\dots ,p{l}_k\}$ is the set of lanes; region splitting is defined as $R_i=\{(n\in V_i)\wedge (n\in p{l}_i)\},\forall p{l}_i\in Pl$, $i=1,2,\dots ,k$.

Step 2 Model layering (recursive layering based on sub-processes).

For each region, $R_i$, recursively processing nested sub-processes to construct a tree hierarchy.

Top-level process layer ($L_0$): main process and no parent process.

Sub-process layer ($L_m$): if the sub-process $Psub$ is nested in layers $L_{m-1}$, then $Psub$ belongs to the layer $L_m$.

Sibling sub-processes: sub-processes under the same parent process (such as $Psub(t1)$ and $Psub(t2)$) have a shared hierarchy.

Step 3 Module segmentation (atomic cutting of drivers via gateways).

In each layer, a sequence of gateway pair (GP) nodes is used to generate atomization modules.

$\exists g_{i1},g_{i2}\in M_i$, $M_i=(g_{i1},n_1,n_2,\dots n_k,g_{i2})$, where $g_{i1}$ is an input gateway, and $g_{i2}$ is an output gateway matching the type of $g_{i1}$. $N_i=(n_1,n_2,\dots ,n_k)$ is the set of nodes (events and activities) between the two gateway nodes.

4.3. BPMN-HCPN Formal Mapping

HCPN is widely used in various discrete-event systems to support the modeling and analysis of hierarchical processes, and there have been many related studies on how to systematically convert BPMN models to Petri nets [6,25]. Here, we use HCPN as a formal model and give formal definitions of BPMN elements to support the formal analysis of process evolution, as Table 2 shows the basic element mapping rules from BPMN to HCPN. Figure 4 shows the BPMN-HCPN graphical mapping relationship, where the solid line is the actual mapped element, and the dashed line indicates the virtual link element.

Table 2. BPMN-HCPN mapping rules and evolutionary behavior.

BPMN Element	Evolution Behavior	Formal Definition
Start event $e(\mathrm{S})$	None	$e(\mathrm{S})=\{P(p_0,M_0)+A_r(p_0,t_0)+T(t_0,f(guard)=ture)\}$
Intermediate event $e(\mathrm{I})$	Insert, delete	$e(\mathrm{I})=\{A_r(p_{i-1},t_i)+T(t_i,f(guard)=ture)+A_r(t_i,p_i)\}$
End event $e(E)$	Insert, delete	$e(E)=\{T(t_{\mathrm{silent}},f(guard)=ture)+P(p_{end},M_{end})+A_r(t_{end},p_{end})\}$
Parallel gateway $g(Pa)$	Insert, delete	$g(Pa)=\{A_r(p_{i-1},t_i)+T(t_i)+A_r(t_i,p_{i+1})\cup A_r(t_i,p_{i+2})\}$ $f(guard)=AND(cond1,cond2))$
Exclusive gateway $g(\mathrm{Ex})$	Insert, delete	$g(\mathrm{Ex})=\{P(p_i)+A_r(p_i,t_{\mathrm{sil}1})\cup A_r(p_i,t_{\mathrm{sil}2})+T(t_{\mathrm{sil}1})\cup T(t_{\mathrm{sil}2})\}$ $f(guard)=OR(cond1,cond2))$
Task $Task$	Insert, delete	$Task=\{P(p_{i-1},M_{i-1})+A_r(p_{i-1},t_i)+T(t_i,f(guard)=ture)\}$
Sub-process $T(Sub)$	Insert, delete	$T(Sub)=\{P_{ports}(p_{in})+A_r(p_{in},t_{sub})+T(t_{sub})+A_r(t_{sub},p_{out})+P_{ports}(p_{out})\}$
Sequence flow $F(Seq)$	Insert, delete	$F(Seq)=A_r(p_{in},t_{gate})\vee A_r(t_{gate},p_{out})$
Message flow $F(Mes)$	Insert, delete	$F(Mes)=A_r(p_{msg(queue)},t_{msg(received)})\vee A_r(t_{msg(received)},p_{msg(queue)})$

Figure 4. BPMN and HCPN model element mapping relationships.

It is worth noting that, in order to maintain structural integrity, there exists a class of silent transitions [32] (e.g., blank transitions added during the mapping process of mutex gateways or end events) in the Petri net model, which are special transitions that do not directly affect tokens but are generally used to supplement the structure and whose modification does not result in a loss of tokens.

During the formal mapping of BPMN elements to HCPN, the hierarchical characteristic of HCPN offers pivotal support for the modular decomposition and formal analysis of intricate processes. As illustrated in Figure 5, the hierarchical structure of HCPN (L0–L2) reflects the modeling logic from abstraction to concreteness via an intuitive hierarchical design. Specifically, the L0 layer establishes a high-level framework using modules M1, M2, and M3. Subsequently, the L1 and L2 layers progressively elaborate on substitution transitions, enabling top-down refined modeling. Through this hierarchical decomposition, complex BPMN processes are broken down into smaller, more manageable sub-structures. This approach not only effectively reduces the complexity of formal modeling but also enhances the comprehension of intricate processes, thereby laying a solid foundation for the formal analysis of process evolution.

Figure 5. Top-down hierarchical HCPN model.

After completing the mapping, in order to avoid potential problems such as information loss or structure defects, we try the BPMN-HCPN mapping correctness detection algorithm to systematically verify the accuracy of the mapping process.

In Algorithm 1, let k be set as the number of mappings, let m denote the number of BPMN elements, let n denote the number of HCPN elements, and let l denote the number of connections. The total time complexity of Algorithm 1 is $O(m+n+l)$ ($k<m+n$).

Algorithm 1 BPMN-HCPN mapping correctness.

Input: BPMN_model, HCPN_model, mapping list

Output: mapping validity

Start: Initialize # Check element correspondence def check_element_mapping (bpmn, hcpn, mapping):         for bpmn_element, hcpn_element in mapping.items():                 if bpmn_element not in bpmn or hcpn_element not in hcpn:                         print(f“Mapping error: {bpmn_element} in BPMN or {hcpn_element} in HCPN not found.”)                 else:                         print(f“Mapping {bpmn_element} to {hcpn_element} is valid.”) # Check connectivity def check_connection_mapping(bpmn_connections, hcpn_connections, mapping):         for source, target in bpmn_connections:                 hcpn_source = mapping.get(source)                 hcpn_target = mapping.get(target)                 if hcpn_source and hcpn_target:                         if (hcpn_source, hcpn_target) not in hcpn_connections:                                 print(f“Connection mapping error: {source} -> {target} in BPMN not mapped correctly.”)                         else:                                 print(f“Connection mapping {source} -> {target} is valid.”)                 else:                         print(f“Connection mapping error: {source} or {target} not mapped.”) # Detecting mainstream process mapping print(“Checking main process mapping:”) check_element_mapping(bpmn_model, hcpn_model, mapping) check_connection_mapping(bpmn_connections, hcpn_connections, mapping) # Detection sub-process mapping print(“\nChecking sub-process mapping:”) check_element_mapping(sub_process, hcpn_sub, sub_process_mapping)

4.4. BPMN-HCPN Evolution Operations

Processes that are executed in response to a series of state changes or activities of a particular business object are called process fragments; the process fragment is a reusable building block with independent functionality containing explicit inputs, outputs, activities, flow relationships, etc. [33,34].

Definition 8.

(process fragments, PFs).

Let process fragment be a ternary $x=\{I,O,N\prime \}$, where the following applies: I denotes the set of input nodes, O denotes the set of output nodes, $N\prime =(P\prime \cup T\prime )$ denotes the set of nodes inside the fragment, $P\prime$ is the set of fragment libraries, and $T\prime$ is the set of fragment variations.

During the evolution of the BPMN collaboration model, it can be adapted to different business scenarios or needs by updating the process fragments and their adjustments to connectivity relationships. As shown in Figure 6, the three basic evolution operations include the following: insertion, deletion, and replacement.

Figure 6. Schematic diagram of insertion, deletion, and substitution evolution. (a) Original BPMN model (upper left). (b) Inset operation (upper middle). (c) Delete operation (upper right). (d) Parallel insert operation (lower left). (e) Replace operations (lower right).

• Insertion evolution.

Definition: The insertion operation implants a new fragment between two neighboring nodes in a process and synchronously updates the corresponding connectivity relationships (e.g., sequential, parallel, or mutually exclusive) to form a new process (as shown in Figure 6b,d).

Step:

• (1)

  Locate the insertion node: set up the original process $BP\_old=(V_{old},E_{old})$, and $\exists v_i,v_j\in V_{old},e_{ij}\in E_{\mathrm{old}}$;

  (2)

  Insert new fragment: inset $P{F}_{new}=(I_{new},O_{new},V_{new},E_{new})$;

  (3)

  Adjust the connection elements: remove the existing arcs, $e_{ij}$, and add arcs $e_{i,new}$ with $e_{new,j}$.

Formal representation: $\Delta ins=\left\{v\right|v\in V_{new},v\notin V_{old}\}$.

2.

Deletion evolution.

Definition: deletion evolution is the removal of old functional fragments and their connecting arcs within the process (as shown in Figure 6c).

Step:

• (1)

  Locate deleted fragment: $BP\_old=(V_{old},E_{old})$, $\exists P{F}_{del}\in BP\_old$, $V_{del}=\left\{v_d\right|v_d\in P{F}_{del}\}$; select the $P{F}_{del}$ to be deleted and the nodes $v_{pre},v_{post}$;

  (2)

  Delete old fragment: delete $P{F}_{del}=(I_{in},V_{del},E_{del},O_{out})$;

  (3)

  Adjust the connection elements: remove the input/output arcs $e_{pre,in},e_{out,post}$, and add a connecting arc $e_{pre,post}$ (if semantics allow).

Formal representation: $\Delta del=\left\{v\right|v\in V_{old},v\notin V_{new}\}$.

3.

Substitution evolution.

Definition: substitution evolution is the replacement of the established functional fragment with a new active fragment, and this process can be regarded as a composite of deletion and insertion operations (as shown in Figure 6e).

Step:

• (1)

  Delete old fragment: delete $P{F}_{old},P{F}_{old}\subset BP\_old$;

  (2)

  Insert new fragment: inset $P{F}_{new}=(I_{new},O_{new},{N^{\prime }}_{new})$, and inherit the original set of fragment inputs and outputs;

  (3)

  Interface compatibility: determine that the connecting elements remain unchanged, and $I_{new}=I_{\mathrm{old}},O_{new}=O_{\mathrm{old}}$.

Formal representation: let $\varphi (v)=(type(v),attrs(v),parent(v))$, $V_{common}=V_{old}\cap V_{new},\Delta rep=\left\{v\right|v\in V_{common},{\varphi }_{old}(v)\ne {\varphi }_{new}(v)\}$.

Algorithm 2 is a BPMN model change-checking pseudo-code that analyses the BPMN model change elements before and after evolution to obtain a set of evolutionary data in order to support the evolutionary operations of the executable model. In Algorithm 2, let n and m be, separately, the number of nodes in the old BPMN model and the new BPMN model; the time complexity of Algorithm 2 is $O(mn)$.

Algorithm 2 BPMN change detection.

Input: BPMN _old, BPMN _new

Output: changes = (op _type, el _type, el_id)

Start: Initialize def detect_bpmn_changes(BPMN_old, BPMN_new):         change_operations = []         for element in BPMN_old.elements:                 if element.id not in [e.id for e in BPMN_new.elements]:                         change_operations.append({                                 ‘op _type’: ‘delete’,                                 ‘el _type’: element.type,                                 ‘el_id’: element.id,                         })                 else:                         new_element = next (or e in BPMN_new.elements if e.id == element.id)                         if element.attributes != new_element.attributes                                 change_operations.append({                                         ‘op _type’: ‘insert’,                                         ‘el _type’: element.type,                                         ‘el_id’: element.id,                         })         for element in BPMN_new.elements:                 if element.id not in [e.id for e in BPMN_old.elements]:                         change_operations.append({                                 ‘op _type’: ‘replace’,                                 ‘el _type’: element.type,                                 ‘el_id’: element.id,                         })         return change_operations

With the insertion operation taken as an example, the insertion operation under different Petri net structures is shown in Figure 7.

Figure 7. PN structure evolution.

Let $PN=(P,T,A_{\mathrm{r}},M_0)$, $N=P\cup T$, and $x=\{I,O,P^{‘},T^{’}\}$; then, $\exists N_i,N_j\in PN$, $Ev\_Op=\{PN,(N_i,N_j),x,ST)$, where $N_i,N_j\in PN$ is the evolutionary locus and $ST=(Seq,Sel,Par)$ is the structure type.

1.

Sequential insertion.

The process has no branching structure and $N_i\in P,N_j\in T$ (as shown in Figure 7a). $N_i=P_3,N_j=T_3,$ $x=(T\_ins,P\_ins,I,O)$.

2.

Selective insertion.

The process has a selective structure and $N_i\in P,N_j\in P$ (as shown in Figure 7b). $N_i=P_2,N_j=P_4,$ $x=(T\_in1,P\_in1,T\_in2,I,O)$.

3.

Parallel insertion.

The process has parallel structure and $N_i\in T,N_j\in T$ (as shown in Figure 7c). $N_i=T_1,N_j=T_3,$ $x=(P\_in1,T\_in1,P\_in2,I,O)$.

4.5. Case Study of Formal Verification Based on Replace Operations

In order to more concretely reflect the evolutionary formal validation process, we take the process model substitution operation shown in Figure 6e as an example, which replaces the atomic task “Payment” in the original process with “Select Payment Method”, aiming to expand the function of selecting the payment method. Algorithm-driven change detection and HCPN formal validation ensure the semantic consistency of the business logic during the evolution process. The specific validation process is as follows:

(1)

Algorithm-based change extraction.

Algorithm 2 (the BPMN change detection algorithm) is used to compare the structure of the model before and after evolution. The algorithm detects the functional replacement of task node T2 through element ID matching and attribute analysis, and it generates change data:

changes = [{‘op_type’: ‘replace’, ‘el_type’: ‘task’, ‘el_id’: ‘T2’}], which specifies the type of substitution operation, the type of element, and the target element.

(2)

Process execution validation:

Based on the mapping rules, the HCPN executable model is generated (elements are defined as shown in Table 3); the HCPN model is run with the help of simulation tools to check the process path from “Select Gift” to “Purchase Gift” to “T-sub”. The replaced task is mapped to the sub-process variation T-sub, which contains two parallel branches for electronic payment (t₁) and cash payment (t₂) (as shown in Figure 8). The validation process unfolds in two dimensions:

Table 3. Description of the HCPN model element.

Element	Significance	Element	Significance
T1	Select gift	t1	Electronic payment
T2	Purchase gifts	t2	Cash payment
T4	Payment	Silent1	None
T5	Payment confirmation	Silent2	None
T-sub	Choose the payment method	Silent3	None

Figure 8. Mapped Petri net evolution model (replace).

• a.

  Static structure validation: the correctness of the BPMN-HCPN mapping structure is tested by Algorithm 1.

  b.

  Dynamic behavioral validation: state-space analysis is performed using CPN Tools, the reachability is checked with the Strong Connected Component (SCC) graph (as shown in Figure 9), and the state-space report is shown in Table 4.

  

  Figure 9. SCC (strongly connected components) graph.

  Table 4. HCPN-replace model state-space report.

  CPN Tools State-Space Report for the HCPN-Replace Model (Part)
  State Space
  Nodes:	9
  Arcs:	9
  Secs:	0
  Status:	Full
  Scc Graph
  Nodes:	9
  Arcs:	9
  Secs:	0
  Home Properties
  Home Markings:	[9]
  Liveness Properties
  Dead Markings:	[9]
  Dead Transition Instances:	None
  Live Transition Instances:	None

(3)

Analysis of results.

a.

Deadlock analysis: as can be seen from Table 4,the Dead Mark is “9” and all states are terminated states (i.e., states entered at the end of a system run), which is in line with the end state of the process as expected by design, and there is no unintended deadlock; the dead transition instances are none, indicating that all transitions can be triggered in at least one state, and the system does not have transitions that cannot be activated at all, so static deadlock is excluded.

d.

Behavioral accessibility analysis: As can be seen from Figure 9, the identifications of all nodes can be covered, proving that the model satisfies the reachability requirement. The system can evolve from the initial state to all defined states of identification without path blocking or unreachability.

The aforementioned steps facilitate the verification of structural consistency, behavioral reachability, and deadlocks in the model. The results of this verification are presented in Table 5.

Table 5. HCPN-replace model validation results.

Validation Dimensions	Indicators	Results
Structural integrity	Input/output arc	100%
Behavioral properties	State space	Reachable
Exception detection	Number of deadlocks	0

After verification at the functional and execution levels, it is verified that the BPMN substitution operation is correctly evolved in the HCPN model, which guarantees the logical correctness of the process evolution.

It is worth noting that if a deadlock occurs, the model needs to be readjusted. Generally speaking, by combining structural optimization with dynamic control, the probability of deadlock can be reduced. For instance, adding an intermediate place in the loop path to force transition to be activated sequentially, employing priority transitions assigns priorities to critical transitions to ensure determinacy in resource allocation, and combining monitoring strategies (such as timeout rollback) to trigger deadlock recovery mechanisms by monitoring token flow, thereby achieving real-time fault tolerance. Due to space constraints, we do not describe this in detail in this paper.

5. Intelligent AI Service Scenario Model

We take an AI problem-processing system as an example to build a BPMN collaboration process (as shown in Figure 10). The process is mainly divided into three phases:

Figure 10. BPMN original model.

• Problem reception and preliminary processing stage: at the beginning of the process, the user takes the initiative to initiate the interaction with the AI human customer service, and the system then collects the problem information raised by the user.
• Problem analysis and solution generation stage: In the middle, the system pre-processes the collected problem information. Then, with the help of AI algorithms, databases, and other types of resources, the problem is thoroughly analyzed, and corresponding solutions are generated.
• Solution feedback and confirmation stage: At the end, the system will generate good solution feedback to the user. After receiving the feedback results, the user confirms whether the problem has been successfully solved.

In addition, the original BPMN model is divided into two regions, {M1, M2, M3} and {N1}, with a total of four modules based on the modular approach. The resulting HCPN model after mapping is shown in Figure 11.

Figure 11. Original HCPN model.

It is imperative that the system is updated and optimized in a timely manner, given the constant upgrades in technology and the dynamic nature of user needs. Specifically, the following applies:

• In the initial stage, the system introduces an intelligent problem recommendation mechanism, which is capable of speculating on user needs with the assistance of historical data, thereby reducing user initiation steps, effectively shortening the initial processing time, and thus significantly improving the overall efficiency.
• In the middle stage, the system introduces new algorithms and organically combines them with manual services in the problem analysis stage. This approach greatly improves the accuracy of problem processing and ensures that users are provided with more accurate and effective solutions.
• At the end of the process, the system adds an evaluation and feedback module. When the user confirms the end of the problem processing, the system automatically pops up the evaluation window to survey user satisfaction; the module is designed to comprehensively collect user feedback to provide a strong basis for subsequent system optimization.

The updated evolutionary process model is shown in Figure 12. Based on the analysis results of Algorithm 2, the evolutionary modules are identified as M1, M3, and N1, and the corresponding evolutionary operations are deletion, insertion, and substitution, respectively. According to the method described in Section 5, the above evolution modules are extracted, the corresponding evolution operations are performed, and the finally generated evolved HCPN model is shown in Figure 13.

Figure 12. Evolved BPMN model.

Figure 13. Evolved HCPN model.

To ensure the reliability and validity of the evolved HCPN model, it was formally validated using the HCPN Tools tool. The state-space report generated during the validation process is shown in Figure 14. The detailed analysis of this report allows the verification of key attributes such as the reachability, boundedness, and activity of the Petri net model. The analysis shows that the model does not suffer from deadlock problems. The model is able to produce a final result when the execution of all activities is completed, indicating that the model is reachable.

Figure 14. HCPN evolutionary model state-space report.

6. Conclusions

The new wave of technology represented in artificial intelligence is reshaping our work and life patterns, which not only brings technological innovation to modern information systems but also provides a higher dimensional space and a wider range of application scenarios for the development of architectural models [35]. In the context of changing demands and continuous technological development, business process models need to evolve and optimize continuously to support sustainability goals. In this study, for the problem of complex process evolution under scenario change, a collaborative evolutionary modeling method based on BPMN-HCPN has been proposed, and a process evolution framework supporting incremental iteration was constructed through formal mapping and a dynamic evolutionary validation mechanism, and, finally, the case of AI problem processing system was introduced to validate the validity of the model evolution through the CPN Tools. It effectively reduces the complexity and cost of model evolution, avoids mapping repetition, and improves the adaptability of complex business processes to respond to changes in demand scenarios. However, the current research is still insufficient; future research will build a more comprehensive knowledge base of evolution rules, including intersection and complement, combined with reinforcement learning to achieve adaptive evolution strategy generation and extend the framework to the edge computing environment through time Petri nets to support the real-time evolutionary efficiency verification of distributed processes. In practical applications, this method is expected to help enterprises quickly adapt to the fluctuation of market demand and the evolution of service scenarios.