Digital Thread-Based Business Process Collaboration in Digital Manufacturing Systems: Modeling and Data-Driven Mechanisms

Abstract

Cross-organizational collaboration in digital manufacturing systems is often hindered by fragmented data handoff, inconsistent versions, and delayed downstream collaboration across lifecycle stages and heterogeneous systems. To address this issue, a digital thread (DT)-based business process collaboration paradigm is proposed, and its corresponding modeling and execution method is developed in this paper. Firstly, a digital thread-based business collaboration architecture is constructed, in which the unified digital model (UDM) and the authoritative source of truth (ASoT) are integrated to support consistent referencing and authoritative state control of shared data objects. Subsequently, a business process collaboration model and a data-state-driven business collaboration mechanism are established by integrating data state visibility with dual resource constraints. Finally, the proposed method is formalized and evaluated through timed colored Petri net (TCPN) simulation using production business data from a civil aircraft manufacturing enterprise. The results indicate that, under identical resource constraints, the nominal makespan is reduced by approximately 11.3% as collaboration triggering is shifted from document-level handoff to data-state-driven collaboration, thereby improving process parallelism without increasing physical resource inputs.

1. Introduction

Global manufacturing enterprises are undergoing a transition toward smart manufacturing and digital transformation. Specifically, the development paradigms for complex products, such as those in the aerospace and high-end equipment sectors, are experiencing significant evolution [1]. The value creation within these enterprises increasingly relies on end-to-end business processes that span departmental, disciplinary, and even organizational boundaries. Efficiency and acceleration of process execution are achieved through the collaborative alignment of process steps, participant roles, and information exchange [2]. However, constrained by principles of privacy protection and organizational autonomy, cross-organizational business collaborations often lack a shared global process view. Participating organizations typically operate based on their local process views, which can lead to misaligned understandings of collaboration logic and potential conflicts that require effective collaboration mechanisms to resolve [3]. Moreover, cross-organizational business collaboration involves message interactions and shared resources, giving rise to collaboration issues such as resource contention and state consistency checking, thus calling for verifiable collaborative modeling and control support [4]. Consequently, in digital manufacturing systems, explicit modeling of cross-organizational business processes and effective collaboration control have become important topics in business process management (BPM) and manufacturing systems collaboration research [2].

To address the collaboration of cross-organizational business processes, the field of BPM has developed systematic methods in areas such as modeling, interoperability, and model management. A major line of research has focused on modeling and view management, where local process views and public or private view mechanisms are introduced to preserve organizational autonomy while maintaining collaboration consistency [3,5]. Another line of work has addressed interoperability and model exchange by enhancing process semantics and introducing intermediate representation methods to improve compatibility across heterogeneous process models and systems [6,7,8]. In addition, process analysis and verification methods, such as multi-source log mining and extended Petri net-based approaches, have been employed to identify collaboration dependencies and verify behavioral correctness under message and resource interactions [9,10].

Although previous studies have established relatively systematic methods for business process modeling, interoperability, and formal verification, digital manufacturing systems for complex product development are increasingly characterized by multi-stage and multi-system parallel evolution [11]. Traditional collaboration assumptions centered on stage-based handoff are therefore no longer sufficient to fully capture this shift. In manufacturing practice, different lifecycle stages are often managed and executed by different stakeholders through independent information systems [12]. As a result, cross-system data transfer may lead to version inconsistency and information lag [13], thereby causing collaboration discontinuities across business processes. To address this issue, the digital thread has been introduced as a lifecycle information architecture that integrates product data flows and information flows [14]. By establishing a single authoritative data source, it enables consistent, traceable, and continuously connected data across stages, thus providing a data foundation for sustained business collaboration in digital manufacturing systems [15].

Existing studies generally define the DT as a data-driven lifecycle information architecture. Its concept is often traced to engineering demands from the U.S. Air Force to bridge data between design and manufacturing in complex system development [16], and was later extended to a data architecture that connects information generated throughout the lifecycle of manufacturing systems [17]. Literature offers diverse definitions of the DT, characterizing it as an integrated information flow based on authoritative data sources [18], a model linking lifecycle stages [19], or a comprehensive communication framework spanning lifecycle data surveys [20]. Despite these varied perspectives, systematic reviews and methodological studies consistently identify three core capabilities: the authoritative source of truth, data linkage, and architecture construction. These elements collectively support the vision of a single source of truth for information, data, and knowledge in industrial engineering [21].

Regarding the engineering implementation of the DT in digital manufacturing systems, prior work has adopted Model-Based Definition (MBD) as the primary lifecycle data carrier to support the establishment of authoritative information sources in Model-Based Enterprise (MBE) practices [22,23]. To enhance data trust, knowledge support, and heterogeneous data linkage, root of trust mechanisms, knowledge-based engineering (KBE) methods, and interoperability standards such as STEP AP242 and OSLC or FMI have been introduced to improve traceability and cross system connectivity [10,24,25,26]. At the semantic level, ontologies and knowledge graphs have been employed to reduce semantic ambiguity across multi-source data [27], and DT-driven integrated application frameworks have been developed for representative industrial scenarios [28,29]. Related studies on the digital reconstruction of machine tools have further shown that three-dimensional models can document structural configuration, motion transmission, and operating principles, thereby preserving technical knowledge and supporting educational interpretation of complex mechanical assets [30]. However, existing studies still focus mainly on data continuity and architectural design, while limited attention has been paid to how authoritative data states can be mapped to business process models and then used to support cross organizational business collaboration.

To improve cross-organizational collaboration efficiency in digital manufacturing systems, a DT-based business process collaboration method is developed in this study. Firstly, a DT-based business collaboration architecture and paradigm are established to support consistent referencing of shared data objects across lifecycle stages and heterogeneous systems. Subsequently, a business process collaboration model and a data-state-driven business collaboration mechanism are established by combining data state visibility with dual resource constraints. Finally, a timed colored Petri net-based simulation is conducted using production business data from a civil aircraft manufacturing enterprise to verify the effectiveness of the proposed method.

2. DT-Based Business Collaboration Architecture and Paradigm

2.1. DT-Based Business Collaboration Architecture

According to existing research results, the DT is generally understood as an enterprise-level information architecture for digital manufacturing systems spanning the full product lifecycle, with the purpose of organizing dispersed data, information, and knowledge into an authoritative and continuously connected basis for cross-stage access and reuse [19]. In a business collaboration context, the DT requires not only continuous data linkage across systems and stages, but also a clear way to determine which shared data should be trusted and used at a given moment. For this reason, this study introduces the unified digital model and the ASoT as two complementary means for implementing the DT in cross organizational business collaboration. The UDM is used to organize shared data objects through unified identifiers, semantic associations, and lifecycle links, so that different activities can consistently reference the same objects across systems and stages. The ASoT is used to identify the authoritative version and effective state of those objects, so that collaboration is carried out on currently valid data rather than on local copies or outdated instances.

On this basis, a DT-based business collaboration architecture for digital manufacturing systems is established in this paper, as illustrated in Figure 1. The architecture comprises four core elements: the physical space, the virtual space, the UDM, and the ASoT. The physical space represents the execution environment of business activities and the source of raw state data. It acquires state and event information of production factors, such as personnel, equipment, materials, and the environment, via sensing and data collection mechanisms, and transfers these data into business systems and databases (e.g., PLM, ERP, and MES) through data interactions. The virtual space consists of process-related digital models across lifecycle stages and supports analysis, simulation, and process verification. The UDM provides the unified reference space for shared data objects, whereas the ASoT provides authoritative state control over those objects. These four elements connect physical execution, virtual analysis, shared object referencing, and authoritative state control within a single DT framework, thereby providing an operable basis for sustained business collaboration across systems and lifecycle stages.

2.2. DT-Based Business Collaboration Paradigm

In the typical production practice of discrete manufacturing enterprises, cross-organizational business collaboration often takes the form of phased handoff and cross-system exchange [31]. Such practices could be abstracted in this paper as the traditional business collaboration paradigm, as shown in Figure 2. Under this paradigm, business collaboration mainly relies on the transfer of phased data snapshots between departments and systems. In the absence of unified semantic references and consistency constraints, such interactions between systems often depend on local copies and manual alignment, which may lead to semantic inconsistency, version confusion, and delayed downstream collaboration.

To address these limitations, a DT-based business collaboration paradigm is proposed in this paper, as shown in Figure 3. Under this paradigm, data generated in the physical and virtual spaces are organized through the UDM, while the ASoT identifies their authoritative version and effective state. On this basis, downstream activities no longer collaborate through local static copies, but through consistent referencing of shared data objects and the propagation of explicit state transition events across systems.

Compared with the traditional business collaboration paradigm, the proposed DT-based paradigm offers three main advantages. First, it replaces local copy-based interaction with shared object referencing under unified semantics, thereby reducing semantic inconsistency and version confusion. Second, collaborative information is propagated through an event bus and contractual interfaces, rather than relying mainly on customized point-to-point exchanges between systems. As a result, the interface and maintenance complexity of multi-system interactions can be reduced from $O(N^2)$ to a linearly growing $O(N)$. Finally, the basis of collaboration is shifted from stage-based handoff to governed data-state-based triggering, so that downstream activities can be activated according to explicit object states instead of waiting for complete upstream handoff. In this way, collaboration can evolve from phased synchronization to continuous triggering, and the collaboration logic is shifted from control flow-centered progression to data-state-driven activation. Based on this, a business process modeling method and a DT-based business collaboration mechanism are further developed with data-state-driven collaboration as the core operational logic in this paper, thereby transforming the DT-based business collaboration paradigm into a deployable engineering method for digital manufacturing systems.

3. DT-Based Business Process Modeling and Collaboration Mechanism

On the basis of the DT-based business collaboration paradigm presented in Section 2, this section further formalizes the proposed approach through a business process modeling method and a DT-based business collaboration mechanism.

3.1. DT-Based Business Process Modeling Method

In the DT context, where business data are generated and updated across physical and virtual spaces and governed through unified object referencing and authoritative state constraints, the essence of business process collaboration lies in the functional delegation between responsible organizational entities and the data interaction relationships between business systems under unified object referencing and authoritative state constraints. These relationships undergo logical mapping and dynamic coupling under UDM constraints and are driven by state transition events of data objects whose authoritative version and effective state are identified by the ASoT. To accurately characterize this process, the business collaboration system in the DT context is denoted as BM and abstracted as the following 6-tuple:

$$BM=(R,S,D,E,A,CR)$$

(1)

Definition 1. 

Let $R=\{r_1,r_2,\dots ,r_n\}$ denote the set of organizational entities that undertake function assignments in the collaboration process. For each $r_i\in R$, define an attribute $\mathrm{Cap}(r_i)\in \mathbb{N}$, which represents the maximum number of business activities that the responsible department $r_i$ can process concurrently within the same time window.

Definition 2. 

Let $S=\{s_1,s_2,\dots ,s_n\}$ denote the set of software/systems that support the execution of business activities.

Definition 3. 

Let $D=\{d_1,d_2,\dots ,d_n\}$ denote the information artifacts that are generated, consumed, or shared in the UDM. For each $d_i\in D$, its object instance can be represented as a triple $〈ID,Ver,State〉$, where ID is the unique identifier of data item, Ver is its version number, and $State\in \{Null,Working,Released\}$ denotes the data status in the current process. To enable cross-system concurrent consistency control in the DT context, this paper abstracts business data instances under concurrency-control semantics into the following three mutually exclusive states:

• Null. The data item exists in the UDM only as a specification/definition, and no versioned instance accessible to business activities has been created; therefore, the data object is not retrievable in this state.
• Working. The latest version instance of the data item is currently involved in an ongoing write operation, and the write privilege is exclusively held by a specific business activity. A data item in the Working state is mutually exclusive with other concurrent write requests targeting its latest version; however, collaborators are permitted to read historical Released versions of the item on demand.
• Released. The data item is not subject to any ongoing write operation and remains in a stable, referenceable state. Historical Released versions are frozen and can only be read for reference, while the latest Released version can serve as an authoritative version baseline provided by the ASoT to downstream entities.

Definition 4. 

Let $E=\{e_1,e_2,\dots ,e_n\}$ denote the set of data state transition events, which serve as signals that drive collaborative business-process execution. For each $e_i\in E$, it can be represented as a 4-tuple:

$$e_i=〈d_{ID},d_{Ver},d_{State},t〉$$

(2)

where $d_{ID}$ is the unique identifier of data item d, $d_{Ver}$ is the version number of d, $d_{State}$ is the status of d, and $t\in {ℝ}^{+}$ is the time instant at which the transition event occurs.

Definition 5. 

Let $A=\{a_1,a_2,\dots ,a_n\}$ denote the set of execution units in the overall business process. For each $a_i\in A$, it is represented as a 5-tuple:

$$a_i=〈I_{a_i},O_{a_i},r_{a_i},s_{a_i},{\tau }_{a_i}〉$$

(3)

where $I_{a_i}\subseteq D$ is the input set, $O_{a_i}\subseteq D$ is the output set, $r_{a_i}\in R$ is the responsible department for the activity, $s_{a_i}\in S$ is the system/tool required to execute the activity, and ${\tau }_{a_i}\in {ℝ}^{+}$ is the estimated duration of the activity.

Definition 6. 

Let $CR=\{f_1,f_2,\dots ,f_n\}$ denote the set of logical predicates that govern process progression. For each $f_i\in CR$, $f_i$ is a Boolean function used to determine whether the current business activity satisfies its execution conditions.

Mainstream business process modeling approaches usually describe collaboration through activity sequencing, control dependencies, and resource or message interactions [2]. On this basis, the six-tuple model proposed in this study further incorporates shared data objects, data state transition events, and collaboration rules under DT constraints into a unified formal representation. In this way, the model can explicitly characterize not only the relationships among organizational entities, systems, and activities, but also the participation of authoritative data versions, effective states, and state transition events in cross-organizational business collaboration.

3.2. A DT-Based Business Process Collaboration Mechanism

3.2.1. Concurrency Collaboration Constraints

Based on the business process collaboration model BM established in the previous section, the DT-based business collaboration mechanism is developed in the DT context. Unlike the traditional business collaboration paradigm that mainly advances through control flow commands, the proposed mechanism takes governed data referencing, state awareness, and controlled read/write access as the operational basis of business activities. To ensure executability under concurrent collaboration scenarios, the following four constraints are imposed. These constraints, respectively, address responsibility allocation, data version evolution, digitalization prerequisites, and concurrency consistency in DT-based business collaboration.

Constraint 1. 

For $\forall a\in A$, $\exists !r\in R$ serving as its responsible department. Meanwhile, $\forall r\in R$ may govern multiple software/system resources.

Constraint 2. 

For $\forall d\in D$ in the UDM, $\exists !a\in A$ along the business chain that triggers its creation; subsequent modifications to the already created d shall generate a new version instance.

Constraint 3. 

The comprehensive digitalization of manufacturing enterprise business objects is a prerequisite for collaborative governance.

Constraint 4. 

To guarantee concurrency consistency in the DT context, the latest writable version instance of a data item in the Working state is subject to an exclusive locking mechanism, so as to block other concurrent write requests targeting the same latest version. Historical Released versions remain frozen and read-only, and therefore can still be referenced by other activities without causing version conflict. Meanwhile, data state transition events are propagated through the event bus and become near real-time visible to downstream activities across the entire business process.

3.2.2. Design of the DT-Based Business Collaboration Mechanism

Subject to the above constraints, the DT-based business collaboration mechanism is designed as the operational realization of the DT-based business collaboration paradigm. In this mechanism, the object semantics defined in the UDM are adopted as the reference baseline, the ASoT is used to determine authoritative and effective data states, and downstream activities are triggered through state transition events across heterogeneous systems. From an operational perspective, the mechanism first checks whether the required input data of an activity have reached an authoritative and referenceable state, and then whether the required organizational resources are currently available. Only when both conditions are satisfied can the activity be activated, after which updated data states are released to support downstream collaboration. On this basis, the collaboration logic is abstracted into the collaboration rule set CR in BM, and $\mathrm{Load}(r,t)$ is defined as the concurrent activity workload of responsible organizational entity r at time t. The formal definitions of the business collaboration rules are as follows.

Rule ${\mathit{f}}_{\mathbf{1}}$. 

This rule ensures when a business activity is initiated, all required upstream input data already satisfy the ASoT authoritativeness requirement. Let $\mathrm{Latest}(d)$ denote the highest version number of data item d in the UDM. For the input set $I_a$ of business activity a, the rule holds if and only if $\forall d\in I_a$, d is in the Released state and its version equals $\mathrm{Latest}(d)$.

$$f_1(a)=\underset{\forall d\in I_a}{\wedge }(d.State==\mathrm{Released}\wedge d.Ver==\mathrm{Latest}(d))$$

(4)

Rule ${\mathit{f}}_{\mathbf{2}}$. 

This rule ensures that physical resource constraints are not overloaded. For business activity a, let Owner(a) denote its responsible department. The rule holds if and only if the current load of that department is smaller than its maximum concurrency capacity Cap.

$$f_2(a)=\left\{\begin{array}{l}\mathrm{True}, \mathrm{if} \mathrm{Load}(Owner(a),t)<\mathrm{Cap}(Owner(a))\hfill \\ \mathrm{False}, \mathrm{otherwise}\hfill \end{array}\right.$$

(5)

Rule ${\mathit{f}}_{\mathbf{3}}$. 

This rule requires that a business activity a can be activated only when both its required data are ready and the relevant resources are available.

$$f_3(a)=f_1(a)\wedge f_2(a)$$

(6)

Based on the above rules, the dynamic operation of the DT-based business collaboration mechanism can be divided into three stages, with the corresponding pseudocode given in Algorithm 1.

• Activity state awareness and readiness determination. The event bus listens for state transition events of data objects in the UDM. For any not yet executed activity $a\in A$, once an update event is captured for any item in its input set $I_a$, the system triggers the evaluation of $f_1(a)$. If $f_1(a)=\mathrm{True}$, a is enqueued in the pending queue;
• Resource scheduling and concurrency locking. For any activity a in the pending queue, the system continuously monitors the workload of its responsible department $r=Owner(a)$ according to $f_2(a)$. If $f_2(a)=\mathrm{True}$, one unit of resource capacity is allocated and the load is updated as $\mathrm{Load}(r)\leftarrow \mathrm{Load}(r)+1$. The activity a is then formally started. Meanwhile, for all $d_{out}\in O_a$, the data state is set to Working, and a state transition event $e=〈d_{ID},d_{Ver},\mathrm{Working},t〉$ is published via the event bus. If $f_2(a)=\mathrm{False}$, the activity remains in the pending queue and waits;
• State publication and closed-loop feedback. During the execution of activity a, for any $d\in O_a$, once an update/write operation on d is committed, the state of d is updated to Released. When the data states of all $d\in O_a$ become Released, activity a is considered completed, and the department resources are released by updating the load as $\mathrm{Load}(r)\leftarrow \mathrm{Load}(r)-1$.

  Algorithm 1: DT-Based Business Collaboration Mechanism

  Input: A; Cap(r); Load(r); UDM states

  Output: time-stamped execution trace 1:$\mathrm{Initialize} \mathrm{global} \mathrm{clock} t\leftarrow 0, \mathrm{Run}\leftarrow \left\{\right\}, \mathrm{Done}\leftarrow \left\{\right\}, \mathrm{Trace}\leftarrow \left\{\right\}$ 2:$\mathrm{Initialize} \mathrm{department} \mathrm{loads} \mathrm{Load}(r)\leftarrow 0$$\mathrm{for} \mathrm{all} r\in R$ 3:$\mathrm{While} \mathrm{Done}!=A$ do 4:$\mathrm{Identify} \mathrm{Ready} \mathrm{set} \mathrm{Ready}\leftarrow \left\{\left.a\in \mathrm{A}\backslash (\mathrm{Run}\cup \mathrm{Done})\right|f_1\right(a)=\mathrm{True}\}$ 5:$\mathrm{Select} \mathrm{subset} \mathrm{Start}\subseteq \mathrm{Ready} \mathrm{such} \mathrm{that} \forall a\in \mathrm{Start}, f_2(a)=\mathrm{True}$ 6:$\mathrm{For} \mathrm{each} a\in \mathrm{Start}: \mathrm{Load}(Owner(a))\leftarrow \mathrm{Load}+1$$; \mathrm{Set} O_a\to \mathrm{Working}$ 7:$\mathrm{Update} \mathrm{Run}\leftarrow \mathrm{Run}\cup \mathrm{Start}$; Record start events in Trace 8: Advance t to the earliest completion time of activities in Run 9:$\mathrm{For} \mathrm{each} \mathrm{completed} a: \mathrm{set} O_a\to \mathrm{Released}$$; \mathrm{Load}(Owner(a))\leftarrow \mathrm{Load}-1$ 10: Move completed activities from Run to Done; Record finish events in Trace 11: End while

Within the modeled collaboration scenario, the proposed mechanism exhibits basic robustness through its version and resource control logic. Data version conflicts are constrained by version evolution, authoritativeness checking by the ASoT, and exclusive locking of the latest writable version. Meanwhile, resource allocation is governed by capacity constraints under single-responsibility ownership, which helps avoid cyclic waiting in the current collaboration structure.

4. Simulation Experiments

To validate the effectiveness of the proposed DT-based business process modeling method and collaboration mechanism, this chapter employs TCPN as the modeling and simulation formalism. Based on the CPN Tools 4.0.0 simulation environment, a representative collaboration scenario for civil aircraft manufacturing is constructed.

4.1. TCPN-Based Mapping of Business Collaboration Model

TCPN is adopted in this study because it can jointly represent activity concurrency, resource competition, and data state evolution within the proposed collaboration mechanism. Based on the business process collaboration model BM, the proposed mechanism is mapped to the TCPN subnet shown in Figure 4, so that the interaction among data readiness, resource availability, and activity execution can be formally described and simulated. The main mapping rules are summarized as follows.

• Token and color set mapping. Define the color set DATA with attributes {ID, Ver, State}. Each business data object is represented by a unique DATA token, and the token’s location corresponds to its current state. Define the color set RES as a counting unit; its token count represents the currently available concurrent resource capacity of a responsible department.
• Place mapping. The global repository place ${\mathrm{P}}_{UDM}$ stores DATA tokens whose state is Released, representing ASoT versions that can be referenced. The resource place ${\mathrm{P}}_{Res}$ stores RES tokens. The execution place ${\mathrm{P}}_{Exec}$ stores DATA tokens in the Working state; when a token enters ${\mathrm{P}}_{Exec}$, it is removed from ${\mathrm{P}}_{UDM}$, thereby realizing an exclusive lock over the data object at the structural level. Meanwhile, ${\mathrm{P}}_{Exec}$ incorporates a time delay $\tau$ to emulate the execution time of a business activity.
• Transition and control logic mapping. The start transition ${\mathrm{T}}_{start}$ reads and removes from ${\mathrm{P}}_{UDM}$ those DATA tokens that satisfy the guard rule $f_1$; simultaneously, it consumes one RES token from ${\mathrm{P}}_{Res}$, updates the DATA token state to Working, and pushes it into ${\mathrm{P}}_{Exec}$. The end transition ${\mathrm{T}}_{end}$ updates the version number of DATA token, changes its state to Released, and returns it to ${\mathrm{P}}_{UDM}$; meanwhile, it returns the RES token back to ${\mathrm{P}}_{Res}$.

4.2. Simulation Experiment Design

To verify the effectiveness of the proposed business process collaboration mechanism in improving development parallelism and resource efficiency, this study constructs a discrete event simulation experiment based on real operational data from a civil aircraft manufacturing enterprise. Under resource constrained conditions, the operational performance of a conventional collaboration paradigm is compared with that of a DT-based collaboration paradigm.

4.2.1. Experimental Scenario and Dataset

The experimental data are derived from business process logs of a specific civil aircraft development program. The dataset contains 64 core business activities, including top-level aircraft design, overall process planning, and procurement of airframe structural components, spanning 13 key responsible departments such as the design department, manufacturing engineering center, and assembly workshop. By parsing the input–output dependency relations among activities, a directed acyclic graph (DAG) comprising 64 nodes and more than 120 data dependency edges is constructed.

To emulate resource scarcity in real production environments, the experiment sets the upper bound of concurrent task capacity for each responsible department to 2. Thus, at most two activities can be executed in parallel within the same department at any time, and tasks exceeding this limit must queue and wait.

4.2.2. Configuration of Comparison Groups

To quantitatively evaluate the mechanism’s effectiveness, two comparative experimental scenarios are designed as follows. Both scenarios adopt a first-in-first-out (FIFO) resource scheduling policy.

• Baseline model S0. This scenario simulates the traditional business process collaboration mechanism, in which the data produced by upstream activities are released for downstream use only after the upstream activities have fully completed and the corresponding documents have been archived. Under this mode, downstream activities must strictly wait for upstream completion, even if the required critical data have already been generated during execution.
• Collaboration model S1. This scenario applies the DT-based business collaboration mechanism proposed in this paper and allows data to circulate in a fine-grained manner. In the simulation, data release follows an accompaniment style publishing strategy, under which upstream activities can make intermediate data progressively available to downstream entities during execution, thereby supporting data state driven collaboration.

4.2.3. Analysis of Experimental Results

Figure 5 and Figure 6 present the simulated Gantt charts of S0 baseline model and the S1 collaboration model, respectively, under identical resource constraints.

From the perspective of temporal distribution, the S0 baseline exhibits a fragmented, stepwise task arrangement. Because downstream activities must strictly wait until upstream activities have fully completed before they can start, the process contains non-negligible waiting time due to delayed information release. Under this setting, the achievable degree of parallelism is mainly constrained by the number of activities without data dependencies, resulting in a relatively small number of active tasks within the same time window. In contrast, the S1 collaboration model demonstrates higher process parallelism and greater task aggregation. Benefiting from the DT-enabled fine-grained data circulation, downstream activities can access intermediate data during upstream execution, thereby breaking the rigid timing constraints of the traditional paradigm. The results further show that tasks associated with the manufacturing department (MD) and the assembly workshop exhibit clear shingle-like overlaps along the time axis, where downstream tasks successfully execute in parallel within the execution window of upstream tasks. This accompaniment style mode enabled by data state visibility increases the density of concurrent tasks per unit time.

Simulation statistics indicate that, under the same resource capacity limit, the nominal makespan of the S0 model is 207.0 labor hours, whereas that of the S1 collaboration model is reduced to 183.6 labor hours. This corresponds to an overall reduction of approximately 11.3%. According to field investigation conducted in the same civil aircraft manufacturing enterprise, the actual production cycle of the corresponding business chain is estimated by the responsible personnel to be about 228 labor hours. This value is closer to the S0 result than to the S1 result, indicating that the current on-site collaboration mode still largely follows the logic of phased handoff, whereas the S1 result reflects the improvement potential of data state driven collaboration under the same resource capacity constraints. In actual industrial processes, this increase in parallelism means that downstream departments can begin preparation or execution earlier once the required data objects become authoritative and referenceable, thereby compressing waiting intervals between adjacent activities and improving the utilization of existing organizational and system resources.

The difference between the simulated results and the field-estimated production cycle mainly arises from the gap between the controlled assumptions of the TCPN model and the actual execution conditions of the enterprise. In the simulation, activity durations are treated as nominal values and state transitions are triggered once the corresponding logical conditions are satisfied. In the actual production process, however, the overall cycle is also affected by additional waiting and disruption factors, including logistics coordination, approval delays, and extra time associated with unexpected damage handling. According to the enterprise investigation, these factors may introduce a fluctuation of approximately ±5% around the estimated cycle. Therefore, the reported 11.3% reduction should be regarded as the theoretical improvement potential of the proposed collaboration logic under controlled conditions.

5. Conclusions

To address data silos and collaboration discontinuities in digital manufacturing systems, a DT-based business process collaboration architecture and paradigm are established in this paper, and a business process modeling method together with a DT-based business collaboration mechanism is further developed. Different from conventional collaboration approaches that mainly rely on phased handoff and control-flow progression, the proposed approach incorporates shared object referencing and authoritative state control into the collaboration logic through the UDM and the ASoT. On this basis, business collaboration is transformed from document level handoff to data-state-driven triggering, thereby providing a deployable engineering method for cross-organizational collaboration in digital manufacturing systems.

To validate the proposed approach, TCPN-based simulation experiments are conducted on a production process comprising 64 core business activities. Comparative results demonstrate that, under identical resource constraints, the proposed DT-based business collaboration mechanism improves process parallelism and reduces the nominal makespan by approximately 11.3%. This result indicates that, when authoritative and referenceable data objects are made available earlier in the process, downstream activities can be activated more promptly, thereby reducing waiting gaps between adjacent activities and improving the utilization of existing organizational and system resources.

The present study mainly examines DT-based business collaboration under controlled execution conditions, where activity durations are represented by nominal values and the collaboration process is analyzed from a deterministic perspective. Therefore, the current results primarily reflect the improvement potential of the proposed method in structured collaboration scenarios. In addition, the current validation is based on a representative business chain from a civil aircraft manufacturing enterprise, and its applicability to other digital manufacturing scenarios still requires further verification. Future work will focus on extending the method to collaboration processes with stochastic disturbances, dynamic rescheduling requirements, and abnormal event recovery, while further validating its applicability across a wider range of complex manufacturing processes.