UniTwin: Enabling Multi-Digital Twin Coordination for Modeling Distributed and Complex Systems

Abstract

The growing complexity and scale of Cyber–Physical Systems (CPSs) have led to an increasing need for the holistic orchestration of multiple Digital Twins (DTs). Therefore, an extension to the UniTwin framework is introduced within this paper. UniTwin is a containerized, cloud-native DT framework. This extension enables the hierarchical aggregation of DTs across various abstraction levels. Traditional DT frameworks often lack mechanisms for dynamic composition at the level of entire systems. This is essential for modeling distributed systems in heterogeneous environments. UniTwin addresses this gap by grouping DTs into composite entities with an aggregation mechanism. The aggregation mechanism is demonstrated in a smart manufacturing case study, which covers the orchestration of a production line for personalized shopping cart chips. It uses modular DTs provided for each device within the production line. A System-Aggregated Digital Twin (S-ADT) is used to orchestrate the individual DTs, mapping the devices in the production line. Therefore, the production line adapts and reconfigures according to user-defined parameters. This validates the flexibility and practicality of the aggregation mechanism. This work contributes an aggregation mechanism for the UniTwin framework, paving the way for adaptable DTs for complex CPSs in domains like smart manufacturing, logistics, and infrastructure.

1. Introduction

Digital Twins (DTs) play an increasingly important role in modeling, controlling, and optimizing Cyber–Physical Systems (CPSs) [1]. A DT is a digital representation of a physical asset, or Physical Twin (PT), with which it is linked by a bidirectional connection for data and information exchange [2]. This technology enables, for example, real-time monitoring, predictive maintenance, and data-driven decision-making [3]. With systems in domains such as smart manufacturing, smart cities, and logistics becoming increasingly interconnected and distributed, there is a growing need to model not only individual devices but also their combined, coordinated behavior. This results in a trend towards the emergence of multi-DT systems in which several DTs interact, exchange data, and have to be orchestrated across different abstraction levels [4,5,6].

However, the collective management and orchestration of DTs poses several challenges. For instance, the coordination of data exchange, synchronization of actions, and implementation of hierarchical relationships between DTs for different levels of aggregation [4,5,6]. Traditional DT frameworks often lack support for such coordination and aggregation, especially in dynamic environments. The aggregation of DTs describes the ability to group, manage, and orchestrate DTs as composite structures. This capability is crucial for scalability, modularity, and reusability in complex digital ecosystems [7].

This paper addresses the challenges of aggregating several DT instances by extending the UniTwin framework with a hierarchical aggregation mechanism. UniTwin is a containerized, cloud-native DT framework that supports dynamic deployment and reconfiguration of DTs. With the proposed aggregation mechanism, DTs are grouped into composite structures across multiple levels of abstraction. This allows for the provision of suitable representation for individual parts up to complex system aggregates.

The contributions of this paper is the top-level aggregation concept for DT hierarchies, the implementation within the UniTwin framework, and the validation of this mechanism through a demonstrator in a real-world-inspired smart manufacturing case study. It enables modular, composable, and reconfigurable DTs. The approach supports the provision of digital representation for complex systems, as well as their adaptive and scalable control in dynamic operational environments.

This paper is structured as follows. In Section 2, the related work on DT coordination and aggregation is outlined. Section 3 introduces the conceptual aggregation mechanism to be incorporated into the UniTwin framework. In Section 4, the technical implementation in the UniTwin framework is presented, and Section 5 provides a case study of a smart manufacturing line. Section 6 discusses the systems implications, and Section 7 concludes the paper with future research directions.

2. Related Work

Research on DT aggregation has evolved significantly in recent years across domains such as manufacturing, energy, and smart cities [1]. DT aggregation presents the ability to compose multiple DTs into higher-order entities [8]. This section reviews related work on DT aggregation mechanisms, hierarchical modeling, and orchestration. In particular, two representative strands are analyzed: (i) reference architectures that specify how DTs interconnect and aggregate (e.g., SLADTA), and (ii) semantic/methodological approaches that specify what is aggregated at the metadata level (e.g., DTAG). This clarifies which gaps UniTwin addresses at runtime. It also situates the UniTwin framework within the current research landscape.

Grieves and Vickers [2] first introduced the conceptual framework for different types of DTs, including the DT prototype, the DT instance, and the DT aggregate. The DT aggregate laid the foundation for multi-layer DT structures. However, challenges arise when scaling up from isolated DTs to interconnected systems. These challenges have been identified through a variety of reviews. For instance, complex systems typically consist of numerous subsystems and components with distinct DTs. These are often heterogeneous due to the use of different protocols, standards, structures, and data sources, which limit interoperability [5,9]. In addition, these Aggregated Digital Twins (ADTs) must exchange high-volume heterogeneous data while preserving causal consistency [7]. In addition, static aggregations of the underlying DT models are no longer sufficient. Appropriate coordination and orchestration mechanisms are needed for detection, planning, and troubleshooting within the ADTs [10]. This highlights the need for continuous research on dynamic, reconfigurable aggregation layers within DT frameworks. There are already some approaches and frameworks for the aggregation of DTs. However, these are not comprehensive and are subject to certain limitations. Subsequently, the most closely related lines are discussed in more depth and their stated scope and evidence to the general problem setting is shown.

Redelinghuys et al. [11] propose a Six-Layer DT model for Aggregation (SLADTA). The model incorporates the aggregation concept through hierarchical coupling. Their extension, SLADTA, connects DTs primarily via Layer 3 (local data repositories) using OPC UA, while Layer 4 (custom IoT gateway) manages data-to-information conversion and inter-DT interaction. Configuration is pulled from the cloud (Layer 5) and can be expressed as XML, which supports reconfigurability. The paper demonstrates SLADTA on a manufacturing-cell scenario and explicitly positions a broader proof-of-concept as future work, without reporting quantitative orchestration/latency/scale metrics.

In short, SLADTA advances a reference architecture with modularity and reconfigurability claims but does not evaluate runtime orchestration performance or fault handling at scale, which are central to our use case.

González-Gerpe et al. [12] introduce an approach called DTAG (Digital Twin Aggregation), which is a lightweight methodology for aggregating multiple DTs into a DT aggregate. The methodology focuses on semantic characteristics and applies the Web of Things Digital Twin (WoTDT) ontology. Concisely, the paper contributes (i) the WoTDT ontology to describe a five-dimensional DT model, and (ii) the DTAG workflow with steps for instantiation, dimension-wise aggregation, and maintenance. The emphasis is on metadata/semantic aggregation and discoverability. There is no quantitative evaluation of orchestration latency, throughput, or scaling behavior across many DTs.

Ball et al. [13] present the Hierarchical System of Digital Twins (HSDTs), a goal-oriented architecture designed for swarm systems. It supports both functional and aggregation hierarchies and offers a metamodel to integrate with Asset Administration Shell (AAS) for interoperability. While it targets hierarchy and goals, published descriptions emphasize modeling and integration rather than measured runtime orchestration across heterogeneous deployments. Yu et al. [4] advocate for the Internet of Federated Digital Twins (IoFDTs), which integrates heterogeneous DTs across services, enabling Society 5.0 applications. Through its hierarchical architecture and AI-native networking, it emphasizes horizontal and vertical coordination. However, accounts remain largely conceptual, with limited evidence on scalability or industrial validation across domains. Nguyen et al. [14] define the orchestration of DTs as the task of “managing and coordinating the interactions between multiple digital twins”, enabling simulation and optimization across domain borders. Based on this definition, a DT orchestrator framework is proposed, which offers services for federating, translating, and synchronizing. The concept of a Federated Digital Twin (FDT) is introduced by Vergara et al. [15], which consists of connected autonomous DTs. It facilitates a comprehensive understanding of complex systems and the links between the DTs. Furthermore, it provides the foundation for the DTs to collaboratively accomplish shared goals. In the context of manufacturing, Nie et al. [16] propose a multi-agent, cloud-edge orchestration framework. This framework addresses the increasing demand for mass individualization and collaborative manufacturing by combining DT and multi-agent technology for optimizing the production process. Human et al. [17] introduce a more general design approach for DT frameworks combining DT aggregation hierarchies with service-oriented layers. This approach focuses on reliable, system-oriented, and adaptable business-oriented services. In the domain of power grids, Ruhe et al. [18] propose a hierarchical design for power systems that integrates models at various grid levels in real-time to mirror their physical behavior. Across these orchestration-oriented works, detailed quantitative evidence (e.g., p95 orchestration latency at load, reconfiguration time under topology change, or availability under injected failures) is seldom reported, which complicates head-to-head assessment with deployment-ready frameworks. In addition to the structural and semantic limitations described above, several domain-specific studies have demonstrated that the implementation of DT aggregation on a large scale remains challenging. For instance, in smart energy systems and urban infrastructures, the integration of heterogeneous DTs is constrained by asynchronous data streams, time shifts, and the lack of standardized interfaces [19,20]. These observations reinforce the need for runtime mechanisms that go beyond information/ontology alignment to provide policy-driven orchestration, dynamic recomposition, and fault containment under real workloads.

Existing approaches are often limited to isolated or loosely linked DTs. Most prior work address either a single DT or ad hoc DT collaborations [4,12]. Although previous research has provided a basic understanding of the aggregation and coordination of DTs, significant limitations remain in current frameworks. Specifically, SLADTA excels at defining where aggregation interfaces live (Layers 3–6 with OPC UA and cloud-driven configuration) but does not quantify how orchestration performs at scale or under failure; DTAG/WoTDT clarify what is aggregated semantically and how to organize it methodologically, but stop short of an execution framework with measured runtime properties.

Consequently, there is a need for DT frameworks that are flexible, modular, and use-case-independent. These frameworks should offer solutions for the aggregation of DTs and support dynamic reconfiguration at runtime. To address these challenges, the UniTwin framework was developed with a focus on modularity, containerization, and dynamic reconfiguration. In the following, the UniTwin framework is introduced, which forms the foundation for the hierarchical DT aggregation mechanism presented in this work.

UniTwin Framework

Typical DT frameworks are characterized by implementations that are designed specifically for certain domains or use cases [21]. This limitation restricts the adaptability and transferability of the framework to other applications. The development of the UniTwin framework was driven by the need to overcome these limitations. UniTwin, therefore, offers modular DTs that are dynamically reconfigurable and can be adapted across domains. As a cloud-native framework, UniTwin utilizes containerization technology to provide efficient deployments [22,23,24,25].

Figure 1 shows the architecture of the UniTwin framework. The framework consists of two central components: the Digital Twin Provisioning Service (DTPS) and the UniTwin base image. In addition to these two components, the framework includes a Time Series Database, Configuration Storage, DT Database, and Object Storage. The DTPS handles various orchestration tasks related to DT deployments and management within the framework. It features a connection to the DT database. The DT Database stores serialized representations of DTs. The DTPS is also connected to the Configuration Storage. In the Configuration Storage, configurations of individual DTs are stored.

The UniTwin base image also shares a connection with the Configuration Storage. It utilizes this connection for requesting its configuration. To store different types of data, it is connected to the Time Series Database and Object Storage. The UniTwin base image provides modular DTs through its ability to dynamically incorporate classes defined in its configuration [22].

According to the outlined architecture, the framework is implemented using containerized components managed in a Kubernetes-based runtime environment. The DTPS and the UniTwin base image are implemented in Python and containerized. The DTPS comprises various management skills, for example, updating changed configurations of DTs, initiating the DTs’ reconfiguration procedure, and assigning DTs to nodes within the cluster. The UniTwin base images are structured according to the composite design pattern. This structure enables the composition of hierarchical tree-like structures through standardized interfaces. It provides modularity and adaptability of the DTs within the framework. Both the DT Database and the Configuration Storage are implemented with MongoDB containers. An InfluxDB container is used for the Time Series Database, and the Object Storage utilizes a MinIO container. Kubernetes is used as the runtime environment for all containers within the framework [23].

The process of creating a new DT in the UniTwin framework is outlined below. First, the request for a new DT must be submitted to the DTPS API. This can be performed either manually or by the PT itself. The configuration for the DT to be provided is transmitted with this request. Next, the DTPS generates and serializes a new DT object featuring a Unique Identifier (UID). The DTPS stores the DT’s configuration in the Configuration Storage under the UID. Next, the DTPS creates a new Kubernetes pod from the UniTwin base image and transfers the UID in the environmental variables. The DT then retrieves its configuration from the Configuration Storage with this UID.

Subsequently, the DT iterates through the classes and instances defined within its configuration. It requests missing class files from the DTPS and installs missing dependencies dynamically. It then adds all class instances to its composite, thus completing its initiation. Furthermore, the DT features the ability for recomposition at runtime in case of changing requirements and configurations. This gives the framework its special reconfiguration capabilities [23,24].

Although these capabilities provide modularity and adaptability to individual DTs, modern CPSs often require coordination across multiple DT instances, representing interdependent components [26]. In distributed environments, there is a need to aggregate DTs into higher-level entities in order to enable collective behavior, simplify orchestration, and reflect structural hierarchies [27]. The following section introduces a hierarchical aggregation concept that integrates with the UniTwin framework to address this need.

3. Aggregation Concept

Modern CPSs consist of numerous interconnected devices operating in distributed environments ranging from cloud data centers to edge devices close to the physical process. In order to efficiently coordinate, control, and model such heterogeneous systems, it is necessary to aggregate DTs in hierarchical structures. Aggregation not only reduces system complexity by encapsulating functions, but also enables scalable orchestration and abstraction across multiple layers of a CPS.

The UniTwin framework addresses this need for aggregation utilizing a structured aggregation concept that supports flexible composition of DTs into multi-level hierarchies. These hierarchies are not only logical but can also reflect the potential runtime distribution. For example, low-level DTs can run close to the physical layer (Edge), mid-level aggregations can reside in intermediate nodes (Fog), and System-Level aggregations can be deployed in the Cloud. This makes the framework suitable for the dynamic and resource-aware use of DTs in distributed CPS infrastructures.

The previous section outlined the need for sufficient aggregation concepts for combining multiple DTs into larger units and introducing the UniTwin framework. In order to address the need for aggregating DTs, this section focuses on the aggregation concept developed to integrate with the UniTwin framework.

In Figure 2, the concept for the aggregation of multiple DTs into larger units is displayed. To support such hierarchical modeling, the concept is divided into three levels: Part-Level, Component-Level, and System-Level.

The Part-Level is the lowest level in the hierarchy. Here, the individual parts are located, which are generically named DT 1 to DT n. Each Part represents a fundamental, self-contained DT capable of operating independently. These DTs are the most granular elements within the aggregation concept.

Above the Part-Level is the Component-Level. Within this level, the components are named Component-Aggregated Digital Twin (C-ADT). These C-ADTs form the first abstraction beyond individual autonomy. For instance, C-ADT 1 is the aggregation of DT 1 and DT-2. Compared to DT, a C-ADT does not represent independent, operable units and cannot exist alone. The C-ADTs take over supervisory or coordinating functionalities over their constituent DTs. Components can also include previously aggregated components, enabling recursive aggregation structures.

At the top of the hierarchy, the System-Level, which represents the highest form of aggregation within this concept for aggregating DTs, is placed. Here, systems are located, which are called System-Aggregated Digital Twins (S-ADTs). Systems or C-ADTs can be composed of a combination of both components and parts. As displayed in Figure 2, S-ADT 1 is an aggregate of C-ADT 1 with DT 3 and DT n. The System-Level enables centralized governance, orchestration, and overarching decision-making across all included elements, regardless of their level of abstraction.

It must be noted that Figure 2 presents a streamlined abstraction of the aggregation concept. This concept is designed to support greater complexity by allowing for multiple intermediate Component-Levels. These intermediary levels are omitted from the figure to enhance clarity and focus on the core structural principle.

The UniTwin aggregation mechanism is designed to support flexible and adaptive composition strategies. It can accommodate various system architectures, like hierarchical nesting, including Part-, Component-, and System-Level, but also S-ADT, which directly aggregates individual DTs from the Part-Level without an intermediate Component-Level C-ADT. Additionally, the aggregation mechanism supports bottom-up and top-down aggregation logic. In the bottom-up case, individual DTs expose their capabilities and metadata, which can be discovered and combined into higher-level ADTs. Top-down aggregation is also possible. In this case, a System- or Component-Level ADT predefines the expected DTs and binds them dynamically at runtime using declared interfaces. The two aggregation mechanisms are formally defined in the following.

The set of individual DTs is denoted by $DTs=\{D{T}_1,D{T}_2,\dots ,D{T}_n\}$. A C-ADT is defined as $C\_ADT=\{DT{s}_i,DT{s}_j,\dots ,C\_ADT{s}_k\}$, where the elements can be individual DTs or other C-ADTs. This forms a recursive structure. Similarly, a System-Aggregated Digital Twin (S-ADT) is defined as $S\_ADT=\{C\_ADT{s}_m,\dots ,DT{s}_p\}$.

Bottom-Up Aggregation: Each DT exposes its metadata $M\left(DT\right)$, including its capabilities, interfaces, and operational constraints. ADTs are constructed by discovering compatible DTs and recursively aggregating them into C-ADTs or S-ADTs. Algorithm 1 clarifies this aggregation procedure.

Algorithm 1 Bottom-Up Aggregation

Require:$DTs$   1: Initialize empty aggregation set $ADT=\varnothing$   2: for each $DT\in DTs$ do   3:       Retrieve $M\left(DT\right)$   4:       Determine compatibility with existing $ADT$   5:       if compatible then   6:             Add $DT$ to existing C-ADT   7:       else   8:             Create new C-ADT containing $DT$   9:       end if 10: end for 11: Recursively aggregate C-ADTs into higher-level S-ADTs

Top-Down Aggregation: At the System- or Component-Level, an ADT predefines the required DTs or C-ADTs through declared interfaces $I\left(ADT\right)$. At runtime, the aggregation mechanism dynamically binds the available DTs to those interfaces.

Algorithm 2 illustrates this procedure. These formal definitions and pseudo-algorithms clarify the semantics of the aggregation mechanism utilized within the UniTwin framework. The UniTwin aggregation mechanism dynamically switches between bottom-up and top-down strategies based on system configuration and requirements. It provides flexible orchestration across heterogeneous layers.

Algorithm 2 Top-Down Aggregation

Require:$ADT,DTs$ 1: for each interface $i\in I\left(ADT\right)$ do 2:       Find $DT\in DTs$ compatible with i 3:       Bind $DT$ to i 4: end for 5: Recursively bind sub-ADTs if present

4. Aggregation Implementation

After introducing the structure and functionality of the aggregation concept, this section covers its implementation and integration into the UniTwin framework. Figure 3 shows the implementation of the aggregation mechanism within UniTwin.

On the Part-Level, the DTs named DT 1 to DT n, which are provided with the UniTwin framework, are displayed. To enable aggregation functionalities within the framework, a dedicated class file named class_part was developed. This class file is incorporated during the DT’s initialization process and provides the DTs with the ability to become part of an aggregation. Therefore, it equips the DTs with the necessary RESTful API endpoints to support data exchange and coordination in aggregated configurations. Through these API endpoints, external components can interact with the DT’s skills, status, and internal methods, thereby enabling a unified interface for aggregation.

Table 1. Overview of example API endpoints exposed by class_Part.

HTTP Method	Endpoint	Description
GET	/api/v1/get-methods	Returns callable methods or operations that the DT exposes to its parent component.
GET	/api/v1/get-attribute	Retrieves the value of a configurable attribute (e.g., position, state, or sensor reading).
GET	/api/v1/get-status	Returns the operational status of the DT (e.g., active, inactive).
GET	/api/v1/get-capabilities	Lists available capabilities or functional interfaces.
POST	/api/v1/invoke-method	Invokes a defined method or function on the DT.
POST	/api/v1/update-attribute	Updates the value of a configurable attribute.

provides a list of the available example endpoints. These reflect a typical implementation but can be adapted to different domain requirements. The implementation of class_Part relies on commonly used Python packages such as FastAPI for lightweight REST APIs and requests for outbound communication. This ensures reproducibility without complex dependencies.

The logic for executing methods within the class_Part and exposed by the endpoint /api/v1/invoke-method is outlined by the following pseudocode in Algorithm 3.

Algorithm 3 execSkill(DT, SkillToExecute)

1: function ExecuteSkill(method, parameter = None)   2:       skillToExecute ← parent object’s methods[method]   3:       mqttInstance ← parent object getChild(“Class_MQTT-I1”)   4:       payload ← {“name”: this object’s UID, “method”: method}   5:       if parameter ≠ None then   6:             method[“parameter”] ← parameter   7:       end if   8:       mqttInstance.publish(topic = parent object’s UID + “/method”, message = method)   9:       return {“status”: “run method “ + method} 10: end function

In the Component-Level resides the C-ADT 1, which represents the aggregation of DT 1 and DT 2. This C-ADT is equipped with a dedicated class file named class_Aggregation, which provides the necessary functionalities to orchestrate, visualize, and control the ADTs. This class exposes these capabilities through a RESTful API, which provides standardized interaction with external systems. This includes a rendered HTML interface to visualize the ADTs structure based on positioned rectangles retrieved by all ADTs. Additionally, execution sequences of the skills of the contained individual DTs can be defined and executed, enabling the mapping of modular, dynamically executable workflows. The provided endpoints are displayed in

Table 2. Overview of example API endpoints provided by class_Aggregation.

HTTP Method	Endpoint	Description
GET	/api/v1/interface	Provides a visualization or interface representing the aggregated structure (e.g., hierarchy or topology).
GET	/api/v1/get-attributes	Retrieves aggregated and processed attribute data from all subordinate DTs or sub-aggregations.
POST	/api/v1/upload-metadata	Uploads structured metadata about the ADTs (e.g., layout, roles, capabilities).
POST	/api/v1/set-sequence	Defines a sequence of operations to be executed across the ADTs.
POST	/api/v1/run-sequence	Executes the previously defined operation sequence on the aggregated structure.

.

The orchestration logic for running a sequence exposed under /api/v1/run-sequence in class_Aggregation is displayed in Algorithm 4.

At the System-Level, aggregations can be composed of both individual DTs and nested C-ADTs. In Figure 3, such a configuration is displayed by S-ADT 1, which utilizes the class class_Aggregation to orchestrate a combination of individual DTs 1 and 2 with the lower-level aggregations C-ADT 1. This hierarchical nesting allows for multi-level coordination by abstracting complexity while maintaining modularity. For clarity, the figure shows only one Component-Level, but the aggregation concept supports any number of nested aggregation levels, as described in the previous section. Thus, it enables scalable system modeling. This enables scalable system modeling and ensures consistent interfaces and functions at all levels of the hierarchy by using the class_Aggregation uniformly at the Component- and System-Levels.

To determine the aggregation structure of a DT aggregation, UniTwin offers manual configuration and automated composition via API. The JSON-based configuration descriptor contains the topology, execution sequences, and dependencies. The aggregation configuration is incorporated at the initialization of the aggregated DT in the class_Aggregation. Aggregation can optionally be bootstrapped from semantic metadata shared by the incorporated DTs. For example, this could include declared capabilities or roles.

Algorithm 4 runSequence()

1: function runSequence()   2:     if sequence ≠ {} then   3:         for each step in sequence do   4:            if “dt” in sequence[step] then   5:                  dt ← sequence[step][“dt”]   6:                  method ← sequence[step][“method”]   7:                  endpoint ← “/api/v1/invoke-method”   8:                  if “parameters” in sequence[step] then   9:                      parameters ← sequence[step][“parameters”] 10:                  else 11:                      parameters ← {} 12:                  end if 13:                  response ← POST(dt + endpoint, {method, parameters}) 14:                  if response = NetworkError then 15:                      print(“Failed to invoke method on “ + dt) 16:                  else 17:                      print(response) 18:                  end if 19:              else 20:                  for each dt in sequence[step] do 21:                        method ← sequence[step][dt][“method”] 22:                        response ← POST(dt + endpoint, {method, parameters}) 23:                        if response = NetworkError then 24:                              print(“Failed to invoke sequence on “ + dt) 25:                        else 26:                              print(response) 27:                        end if 28:                  end for 29:              end if 30:           end for 31:       else 32:           print(“No sequence defined”) 33:       end if 34: end function

The pods housing the UniTwin DTs in a distributed CPS are dynamically distributed across the available infrastructure within the Kubernetes cluster using the underlying Kubernetes scheduler. The DTPS can assign specific DTs to specific nodes. For instance, Part-Level DTs, such as machines, can be deployed to edge nodes. Meanwhile, System-Level DTs are placed in centralized fog or cloud environments for higher-level orchestration.

5. Case Study: Smart Manufacturing Line

After outlining the underlying technical implementation of the aggregation mechanism and integration within the UniTwn framework, this section focuses on a current development utilizing the aggregation mechanism.

This case study comprises a smart production line where personalized shopping cart chips are manufactured. It is a compact demonstration setup with the ability to produce the chips with a name and with or without a logo on demand [23]. Figure 4 shows the model of the demonstrator setup with all contained components.

The demonstrator setup contains a warehouse in which the blank chips are stored. Two conveyor belts are installed to transport the chips. Various sensors are mounted on the conveyor belts to determine the position, material, and quality of the finished chips. The setup also features a quality management camera to inspect the finished chips. The procedure of the demonstrator is explained in the following. The first conveyor belt transports a blank chip from the warehouse for further processing. Next to this conveyor belt that connects to the warehouse, there is the robot that can pick up the blank chips and place them in or remove them from the laser engraver. The robot also transfers the blank chips from the laser engraver to the second conveyor belt after engraving is finished. This second conveyor belt finally takes the finished chips from the production line to the storage area for finished goods if the inspection with the quality management camera is successful. In the event of an unsuccessful inception, the chip is then transported to the scrap, and the production process is restarted.

All components of the demonstrator have a skill-based structure. This structure provides interfaces for external orchestration. This external orchestration is accomplished through the utilization of designated DTs for every component. The DTs for the individual components are provided via the UniTwin framework. The individual DTs themselves do not communicate with each other autonomously. Instead, the orchestration is coordinated via a higher-level, ADT. This centralized orchestration reflects the architectural focus on modularity and reusability. Although the individual DTs are intentionally stripped of internal logic and self-awareness, they become collectively intelligent through the embedded orchestration logic of the ADT.

The digital mapping of the demonstrator is based on a Raspberry Pi 5. The Raspberry Pi 5 serves as a local edge controller and hosts a single-node Kubernetes cluster using k3s. This cluster runs the UniTwin framework. In addition, a local network is provided by the Raspberry Pi. This local network enables all communication between PTs and DTs, as well as between the DTs. All physical devices have a customized controller that allows them to request a DT. The DTs are requested by each device at system startup. This request is transmitted to the DTPS and includes the specific device configuration. After receiving the requests, the DTPS generates a new UID and stores the configuration of the requesting PT under this UID in the Configuration Storage. Then, it starts a new Kubernetes pod in the cluster that contains the UniTwin base image and injects the UID as an environmental variable. During the initialization phase, the DTs extract the configuration from Configuration Storage using their UIDs. Subsequently, the DTs utilize the configuration to incorporate the specified classes. Each DT’s configuration contains a class_Part. This class enables external orchestration and execution of the PTs’ skills via the corresponding DTs. The class_Part provides the necessary interfaces for external orchestration and skill execution by an ADT. The configuration for this class contains the information necessary for each DT to execute the skills of its corresponding PT. Parallel to the provision of the individual DTs, the Raspberry Pi initiates an ADT, more precisely, an S-ADT. This S-ADT features the class_Aggregation and the information to aggregate all individual DTs of the production line. It allows for the joint control and orchestration of all DTs. The S-ADT can indirectly control and execute the skills of the PTs via the interfaces provided by the DTs. Due to the persistence in the UniTwin framework, requesting a DT is only necessary at the first start-up.

The Raspberry Pi also provides a web interface. This interface allows users to enter the parameters required for producing the shopping cart chip. It also facilitates a button for starting the skill-based production workflow. The web interface is available and can be interacted with via a touchscreen connected to the Raspberry Pi. The chip production parameters include a name and one of two logos. Both parameters are optional and do not have to be selected. This allows chips to be ordered with a name, a logo, both, or neither. The web interface is directly connected to the API endpoints of the production line S-ADT. These endpoints enable the definition, monitoring, and execution of production sequences.

The entire skill-based production workflow can only be described by two algorithms. These are based on the DT level and are outlined in the following. Algorithm 5 defines the reusable procedure executeSkill, which requires a corresponding DT and a skill to be executed via the PT associated to this DT. This algorithm abstracts the interaction between a DT and its assigned PT. Algorithm 6 outlines the full production sequence coordinated by the S-ADT. It utilizes the reusable skill execution pattern.

Algorithm 5 executeSkill(DT, SkillToExecute)

Require: DT, SkillToExecute 1: DT sends SkillToExecute to its assigned physical device 2: Physical device executes SkillToExecute 3: DT receives confirmation from physical device 4: return confirmation

Algorithm 6 Production Sequence Execution with Optional Name and Logo

Require: Optional name, Optional logo   1: S-ADT initializes production sequence with name, logo   2: S-ADT.executeSkill(WarehouseDT, “fetch a chip blank”)   3: S-ADT.executeSkill(ConveyorBelt1DT, “transport to RobotDT”)   4: S-ADT.executeSkill(RobotDT, “place in engraver”)   5: if name is provided then   6:     S-ADT.executeSkill(LaserEngraverDT, “engrave name”)   7: end if   8: if logo is provided then   9:     if name is provided then 10:         S-ADT.executeSkill(RobotDT, “turn chip for logo”) 11:     end if 12:     S-ADT.executeSkill(LaserEngraverDT, “engrave logo”) 13: end if 14: S-ADT.executeSkill(ConveyorBelt2DT, “transport chip to quality inspection”) 15: passedInspection←S-ADT.executeSkill(QualityCameraDT, “inspect chip”) 16: if passedInspection then 17:     S-ADT.executeSkill(ConveyorBelt2DT, “transport to finished goods storage”) 18: else 19:     S-ADT.executeSkill(ConveyorBelt2DT, “transport to scrap”) 20: end if

The process begins when a user submits an order through the web interface with the specified optional parameter name and logo. The parameters are transmitted to the S-ADT of the manufacturing line, which orchestrates the production process. First, the S-ADT defines the tailored production sequences based on the users inputs.

The S-ADT orchestrates the sequence by invoking executeSkill() on the relevant DTs, which are aggregated within itself. Each DT is responsible for delegating the specified skill to its associated PT and receiving confirmation of its execution. The DT then forwards that confirmation back to the S-ADT.

The production sequence starts with the S-ADT invoking the warehouseDT to fetch a blank chip. The warehouse DT triggers its PT to release a blank chip onto conveyor belt 1. After the process is complete, the PT sends a confirmation to the warehouse DT, which then forwards it to the S-ADT. Next, the S-ADT calls conveyor belt 1 DT to transport to RobotDT. Conveyor belt 1’s DT delegates the transport task to its PT, and after successful delivery to the robot, the confirmation is routed back to the S-ADT.

Following transportation, the S-ADT then activates the robot DT’s skill to place in the engraver, to transfer the chip to the laser engraver. The robot DT then instructs its PT to execute the placement task. The confirmation of the placement task is propagated back to the S-ADT through the robot DT.

If the user provided a name, the S-ADT triggers the engrave name through the laser engraver DT. The laser engraver DT then delegates the engraving task to its PT to engrave the name onto the chip. Once the engraving is complete, the DT confirms the result to the S-ADT.

If the user made a selection and a name was engraved, the S-ADT first executes turn chip for logo via the robot’s DT to reorient the chip. This is followed by the engrave logo skill of the laser engraver DT to engrave the logo onto the chip. Each task follows the same interaction pattern: the DT sends the command to its PT, receives confirmation, and passes it back to the S-ADT.

After engraving, the chip must be removed. The S-ADT calls the robot DT to remove from the engraver, which instructs the robot to retrieve the chip from the engraver and place it on conveyor belt 2. Once removal is complete, confirmation is returned to the S-ADT.

The S-ADT calls the conveyor belt 2 DT to transport chip to quality inspection for quality inspection. After the chip is successfully transported, the PT confirms with the S-ADT via its DT. The quality management camera, represented by the quality camera DT, performs an automated inspection of the chip to verify engraving accuracy and detect potential defects utilizing its inspect chip skill. This inspection returns a boolean result (passedInspection) to the S-ADT.

If the chip passes the test, it is sent to the finished goods storage using conveyor belt 2’s DT and issues the transport to finished goods storage skill. Confirmation of the transport is then routed back to the S-ADT from the PT via the conveyor belt 2’s DT. This concludes the production sequence. If the chip fails inspection, conveyor belt 2’s DT is instructed to transport it to scrap using the transport to scrap skill. In this case, the entire production sequence is restarted after the transport to scrap is confirmed using a new blank chip.

In this setup, the aggregation mechanism of the UniTwin framework provides a structural abstraction and simultaneously enables dynamic reconfiguration. The system can execute different engraving workflows based on the order without changing the individual DT logic. In this study, the S-ADT orchestrates heterogeneous DTs into a single production flow. This demonstrates UniTwin’s ability to coordinate modular units with minimal coupling. It emphasizes that skill-based devices without control logic can participate in complex workflows by employing coordination through an ADT enabled by the UniTwin aggregation mechanism.

6. Discussion

The case study in the previous section demonstrates UniTwin’s core contribution, a dynamic aggregation mechanism that enables modular, runtime-coordinated DT systems. Unlike static DTs or pure information models, such as the AAS, UniTwin offers execution-level coordination with real-time binding, reconfiguration, and orchestration. Its ability to group and control heterogeneous DTs into reusable structures makes UniTwin suitable not only for manufacturing but also for any distributed CPS domain requiring System-Level behavior, such as smart logistics, energy, and infrastructure.

The aggregation mechanism introduced within the UniTwin framework presents an advancement in the orchestration of DTs across hierarchical system levels. The hierarchical structuring enables modularity and reusability but also simplifies system-wide control and monitoring, which is a known challenge in conventional DT frameworks. The major advantage of this implementation is the flexibility to deploy the DTs and ADT across the available infrastructure. For instance, DTs can be deployed locally near the machine layer, enabling real-time control and data acquisition, while the ADTs reside in a central cloud or edge node, orchestrating complex workflows and providing a global view of system operations. By abstracting system behavior into composable and reconfigurable DTs, UniTwin addresses key limitations in current DT frameworks, such as the lack of runtime dynamism, poor scalability, and lack of cross-domain transferability. Furthermore, the absence of technical implementations for the aggregation of complex systems consisting of multiple DT instances is addressed.

Utilizing standardized RESTful APIs and dynamic class integration contributes to a high degree of interoperability. This allows the aggregation mechanism to be adapted across various domains. Unlike existing DT frameworks, which often rely on static and monolithic implementations, UniTwin’s approach supports dynamic runtime reconfiguration. This capability extends not only to individual DTs but also to the aggregated System-Level DTs. This System-Level reconfiguration is demonstrated through the customization of shopping cart chips in the case study. This makes the UniTwin framework well-suited for providing DTs for systems with changing requirements, high levels of customization, or decentralized control architectures. Examples of such systems are smart manufacturing, logistics, and autonomous infrastructure.

The presented case study showed the real-world applicability and performance of the aggregation mechanism implemented in UniTwin. It also validated the orchestration ability over the DTs in an aggregation provided through the developed class class_Part and class_Aggregation, as well as the coordination logic over the PTs.

A comparison between UniTwin and established standards, such as the AAS, reveals a fundamental difference. The AAS structures digital assets through predefined information models, focusing on data interoperability and static descriptions. In contrast, UniTwin emphasizes execution-level control and runtime behavior such as DT coordination, orchestration, and reconfiguration. These features position UniTwin for deployment in operational environments where topologies, workflows, or configurations frequently change. Furthermore, UniTwin’s reliance on containerization, modular Python components, and RESTful APIs enables it to be adapted across domains without domain-specific implementation. Containerization and modular runtime orchestration introduce additional complexity, such as dependency management, orchestration overhead, and potential debugging challenges. These must be considered when deploying UniTwin in industrial-scale environments.

Nevertheless, several aspects need further investigation. Although the framework is highly flexible and modular, its performance under high concurrency or in large-scale industrial deployments has yet to be evaluated. In addition, fault tolerance mechanisms and strategies for handling partial system failures within aggregations are currently not implemented. Although the presented case study demonstrates orchestration in a compact smart factory environment and the observations are limited to the scope and complexity of the presented case study. Large-scale CPS implementations may involve hundreds or thousands of DTs. In such scenarios, performance factors such as orchestration latency, network overhead, and scheduling efficiency are critical. Initial considerations suggest that UniTwin’s containerized, Kubernetes-based architecture provides a foundation for horizontal scaling by dynamically distributing DTs across cluster nodes. These aspects, as well as the behavior of such large-scale scenarios, require further empirical examination, and if necessary, adjustments to the UniTwin framework must be made.

In summary, UniTwin’s aggregation mechanism fills a critical gap in current DT research by enabling composable, coordinated, and reconfigurable DT representations of complex systems. It provides a foundation for further research into adaptive and intelligent DT ecosystems that align with the principles of Industry 4.0 and beyond. Future work should focus on quantifying performance and scalability metrics, evaluating potential trade-offs caused by containerization and modular orchestration, and examining operational and large-scale scenarios.

7. Conclusions

This paper presents a novel hierarchical aggregation mechanism for DTs within the UniTwin framework. It advances the orchestration and management of multiple DT instances of complex, distributed systems. The proposed mechanism allows for the dynamic grouping, aggregation, and recomposition of DTs at various hierarchical levels. With this extension, the UniTwin framework can map not only individual assets, but also entire systems. This addresses key challenges regarding the coordination of distributed, interconnected assets in CPSs.

The contribution of this paper is the design and implementation of a scalable aggregation mechanism for the UniTwin framework. This mechanism maintains autonomy at the individual DT level while providing centralized control at higher levels of aggregation. These capabilities are enabled by standardized RESTful APIs, dynamic class integration, and containerization technologies. It allows for flexibility and interoperability across different DT instances. A smart manufacturing case study was utilized to validate the introduced aggregation mechanism. It showed how multiple physical assets can be orchestrated to perform complex synchronized tasks through their associated DTs. These results led to four summarized conclusions:

(1) Separating local decision loops from aggregation-level policies leads to predictable global behavior without compromising the independence of individual DTs. (2) First-class aggregation supports grouping and recomposition during operation, shortening reconfiguration cycles and facilitating the evolution of multi-domain CPS deployments (e.g., smart cities, energy systems, logistics, and autonomous infrastructures). (3) Standardized APIs and modular loading enable interoperability of heterogeneous DTs without custom adapters, improving reusability and portability. (4) The aggregation layer is effective for implementing scheduling, security checks, and observability once, rather than for each DT individually.

In addition to the strengths outlined, this paper identifies potential areas for future research and improvement. These include evaluating performance in use cases with high concurrency and in large-scale industrial deployments. Additionally, fault tolerance and security mechanisms as well as strategies for handling partial system failures must be explored and developed. The following aspects will be the focus of the structured plan of future work:

First, a high-concurrency performance evaluation in both the existing demonstrator and a production plant will be conducted. This assessment will quantify orchestration latency, throughput, reconfiguration time, and resource efficiency under increasing numbers of DTs, and will include failure-injection tests to measure availability and mean time to recovery. Second, beyond scalability and fault tolerance, the security and cross-domain interoperability will be hardened. Concisely, mutual TLS and token-based authentication as well as signed state updates, especially within the standard APIs with industrial protocols (e.g., OPC UA, MQTT) need to be implemented and secured. Third, a systematic benchmarking, enabling direct comparisons to existing frameworks across orchestration latency, scaling behavior, and reconfiguration cost, including ablations against baseline variants will be carried out.

The aggregation mechanism introduced within the UniTwin framework is a significant step forward in the digital modeling and orchestration of complex CPSs. It provides a flexible and scalable solution for coordinating multiple DT instances as one aggregation. It establishes a foundation for future research and development in DT ecosystems, paving the way for next-generation adaptive systems capable of meeting the demands of increasingly dynamic and interconnected operational environments.