A Digital Twins Platform for Digital Manufacturing

Abstract

Digital manufacturing aims to make manufacturing more productive, resilient, and competitive by improving production efficiency and enhancing product quality. To achieve this, this paper proposes a novel digital twin framework for representing complex industrial machines, materials, and products in manufacturing production lines. In the framework, digital twins comprise a physical twin, a virtual twin, and digital threads interconnecting these. The physical twin incorporates relevant physical entities in manufacturing production lines, such as production machines, a material, or a product, as well as additional attached sensors needed for measuring the properties of the physical twin. The virtual twin, which contains the description of physical twin, such as the product’s properties, and AI models use the measurements collected from the production machine or the sensors in the physical twin to optimize production efficiency and ensure products consistency/quality. The digital threads provide for bidirectional communication using industrial protocols between the physical and virtual entities, and also between the AI model(s) and the orchestration component of the virtual twin. The paper also proposes a digital twin-based platform for digital manufacturing. The platform supports the creation and lifecycle management of digital twins for the production machines, materials, and products in each production line. In addition, the platform for digital manufacturing supports the development and management of digital manufacturing solutions that enhance the productivity and resiliency of entire production lines. The paper presents a case study from the composite airframe manufacturing sector that includes a sample framework-based implementation of a digital twin of an airframe part product. This product digital twin incorporates sensors that measure the temperature and viscosity of the composite product and AI model that used these real-time measurements to predict the product quality and reduce its curing time, ensuring both the product quality and production efficiency.

1. Introduction

Productivity in manufacturing is critical for competitiveness and profitability. However, despite the introduction of novel technologies, such as robots, manufacturing productivity suffers from production line inefficiencies, equipment failures resulting in unplanned downtime, product quality/consistency issues that escalate production costs, as well as waste of energy and materials [1,2,3]. Traditional manufacturing systems often struggle to meet these challenges and demands due to their reliance on static models, isolated data silos, and limited real-time visibility, hindering agile decision-making [4,5,6]. Industry 4.0 is transforming manufacturing through a data-driven approach that addresses the above-mentioned challenges and suggests that Internet of Things (IoT) and artificial intelligence (AI) are foundational technologies for digital manufacturing, which are often referred to as “data-driven production”, integrating industrial IoT and data analytics to automate and optimize various stages of manufacturing [7].

Product quality is determined by the interplay of multiple interdependent parameters, including raw material properties, machine settings, production processes, and product recipes. Inconsistencies arise from their combined effects; for example, variations in raw material composition can significantly degrade final product quality despite identical process parameters and machine configurations. Such variability often requires discarding defective products or extensive reprocessing to meet quality specifications. Currently, these challenges are often addressed by analysis performed by production engineers based on their intuition and experience. This approach involves training operators to optimize production efficiency while monitoring and controlling product quality by dynamically adjusting machine settings, raw material properties, and product recipes during production [8,9,10]. For instance, in food manufacturing, evaporator machines processing spreads (e.g., jam, vegemite, peanut butter) require operators to fine-tune parameters such as steam pressure, inflow, and outflow to achieve target consistency [11].

Manufacturing environments encompass complex physical entities such as industrial machines, products, materials, and human operators that require precise digital representation. Digital representation of physical entities, referred to as digital twins (DTs), is a key innovation that underpins digital transformation and supports digital manufacturing, which maintains bidirectional data flow with their corresponding physical entities, closely mirroring their state and behavior [1,4,12]. Unlike generic class-based representations, DTs must model individual entities (specific machines, production lines) to capture unique operational contexts. For instance, identical machines on different lines may exhibit varying failure rates due to distinct environmental factors or operator configurations, necessitating entity-specific analysis rather than generic abstractions. This individualized approach, while technically complex due to inter-entity relationships and operational dependencies, enables precise diagnostics and contextual understanding essential for effective manufacturing optimization.

Current industrial IoT platforms and digital manufacturing technologies require significant advancement to address complex manufacturing environments characterized by dynamic interactions and interdependencies. Although digital twins (DTs) promise enhanced productivity, existing IoT implementations remain limited to simple entities using key–value representations, incapable of modeling complex machines with extensive parameters, settings, relationships, and dependencies designed primarily for basic IoT devices [13,14,15,16]. Representing the complex physical entities of one or more sensors, actuators, and built-in automation as independent data collected using these technologies is not sufficient because when representing the entity using independent data, you need to have a lot of knowledge about “what the data means” and “what is the purpose of the data” [17,18]. As productivity is dependent on multiple parameters in complex physical entities, having semantic representations is crucial as they enable a deeper understanding of the physical entities and their operations. By using ontologies and standardized vocabularies, knowledge graph-based representation can define relationships, behaviors, communication protocols, endpoints, and constraints at a granular level, making it easier to integrate and reuse digital twins across different digital manufacturing applications [7]. This semantic layer also allows for automated reasoning and decision-making, enabling more sophisticated optimization and predictive analytics by the AI models. However, there are limitations in existing industrial IoT platforms that support digital twins as a service when representing complex physical entities with lots of parameters, dependencies, and relationships among them.

Moreover, AI integration within digital twins is essential for transitioning from passive sensor monitoring to closed-loop control, enabling proactive defect prevention through real-time predictions [19]. However, current approaches suffer from data inconsistency arising from transient physical states and settings dependencies that produce non-comparable measurements, yielding poor model accuracy when trained on unfiltered data [17,20]. Physical constraints further complicate modeling; for instance, an oven failing to reach 100 °C within manufacturer-specified timeframes signals maintenance issues that must be explicitly factored into models. Machine settings changes (e.g., oven setpoint shifting from 100 °C to 200 °C) generate fundamentally different sensor data, rendering cross-configuration training invalid. Similarly, operator instructions create condition-specific observations that cannot be arbitrarily combined without introducing inconsistency. These inherent physical and operational dependencies demand explicit representation to ensure reliable AI analysis in complex manufacturing environments [1,7,8].

Generic class-based models fail to capture physical constraints and inter-entity dependencies essential for individual entity analysis. Insufficient contextual semantics prevents precise digital representation of specific physical entities rather than class-level abstractions needed for root-cause diagnosis, such as differential failure rates across identical machines on different production lines. Without addressing these gaps, AI models remain inefficient, generative/large language approaches fail due to limited manufacturing data volumes, and digital twins (DTs) cannot enable real-time precision decision-making for production efficiency and quality. Bridging this research-to-industry gap demands a robust framework integrating AI-driven digital twins with industrial IoT, which has demonstrated significant improvements in manufacturing productivity, resilience, and competitiveness [21,22].

Despite significant advances in IoT platforms and digital twin technologies, there remains no generic and reusable platforms for creating digital twins of complex physical entities in manufacturing that integrate semantically rich digital representations, protocol-aware communications, and AI-drive reasoning in a unified query-able representation. Existing approaches focus either on simple device-level twins or platform-specific implementations, which fail to capture the rich dependencies, contextual constraints, and individual behavior of complex physical entities. This gap limits the ability of digital twins to support accurate prediction, closed-loop control, and scalable deployment across heterogeneous manufacturing environments.

These persistent challenges highlight the need for a more comprehensive and data-driven IoT platform that supports the creation of digital twins of complex physical entities and the creation of digital manufacturing applications using digital twins. To solve these problems, this paper has three objectives: (1) to design an ontology-driven digital twin framework consisting of a physical twin, virtual twin, and digital threads for representing complex physical entities; (2) to implement a Digital Manufacturing Platform that supports the development of digital manufacturing applications using these digital twins; and (3) to validate a real-time manufacturing case study demonstrating real-time quality prediction and production efficiency gains. In this research, we adopt the principles and address the challenges outlined in the recent joint report on digital twins by the US National Academies of Sciences, Engineering, and Medicine [12]. Furthermore, this paper focuses mainly on the design and implementation of a digital twin for a physical product. Such digital twins have received limited attention until now, as digital twins for production machines have received the lion’s share of attention in the research literature. Digital twins for products must accurately mimic the structure, context, and behavior of the physical products in the cyber/data world throughout their entire production lifecycle. We present how such digital twins for products can be leveraged in the proposed platform for digital manufacturing to ensure product consistency and improve production efficiency. The main novel contributions of this paper are the following:

• A novel digital twin framework for creating and managing physical products, including physical twins consisting of materials, sensors, and actuators for measuring and affecting the product’s properties; a DT Description of the physical product, which incorporates an AI model for ensuring product consistency/quality; and digital threads for physical to virtual twin communication using existing standard industrial IoT protocols.
• A novel digital twin-based platform for digital manufacturing that manages the digital twin lifecycle and supports the development of digital manufacturing solutions that improve the productivity and resilience of manufacturing production lines.
• Functional assessment of the proposed platform through developing two digital manufacturing applications utilizing (i) a digital twin of a composite airframe product and (ii) a digital twin of an evaporator machine, demonstrating the platform’s capability to support digital manufacturing applications to improve product quality.

The rest of the paper is organized as follows: Section 2 presents the related work, and Section 3 presents the novel digital twin framework for creating and managing complex physical entities. Section 4 presents the Digital Manufacturing Platform that realizes the above framework for supporting the production of consistent/high quality products in a real-world production line. Section 5 presents the proof-of-concept implementation of the Digital Manufacturing Platform. Next, Section 6 presents an assessment of the platform’s functional ability to support the development of two digital manufacturing applications that improve product quality using digital twins in composite airframe and food manufacturing use cases. Finally, Section 7 concludes the paper.

2. Related Work

Digital manufacturing increasingly leverages IoT platforms and digital twins (DTs) for simple sensor management. However, manufacturing encompasses complex entities, machines, people, and products beyond basic sensors. Existing research and commercial platforms rely on simple data structures inadequate for these complexities. Section 2.1 provides a general DT overview; Section 2.2 examines IoT platform DT capabilities; Section 2.3 addresses digital manufacturing complexity and DT-AI integration challenges.

2.1. Digital Twins

The “digital twin” concept emerged in 2010 during NASA’s technical roadmapping co-led by John Vickers, formalized in NASA reports and Glaessgen and Stargel [23,24]. Early formulations emphasized monitoring/visualization. The National Academies define DTs as “virtual information constructs mimicking structure, context, and behavior of physical systems, dynamically updated with counterpart data” [12]. DT architecture comprises three components: a physical asset, digital model, and bidirectional data connection enabling real-time synchronization [25,26]. Physical assets incorporate sensors/actuators/communication interfaces capturing operational/environmental/performance metrics [27]. This sensor data forms the foundation for creating accurate digital representations and enabling continuous model updates [28]. This definition emphasizes not only structural mirroring but also contextual awareness and dynamic synchronization.

The literature distinguishes Digital Shadows (unidirectional physical to digital) from true DTs (bidirectional) supporting Industry 4.0 applications [29]. Barthelmey et al. [30] proposed dynamic DTs for flexible production predictive maintenance. Digital models typically include geometric representations, physics-based simulations, behavioral models, and historical repositories, but fail to capture constraints/dependencies affecting system parameters [31]. Despite the conceptual advances, a major limitation in current DT-related work lies in the level of abstraction at which twins are defined. Current DT research operates at Process Twin (production lines/workflows) or Type Twin (generic asset classes) abstraction levels. DTs enable real-time monitoring, optimization, control, and decision-making [32,33,34].

However, these process-level approaches cannot detect entity-specific defects, necessitating personalized digital twin instances. In recent work, the health industry has shown interest in having a personalized digital twin for each cancer patient that collects parameters that describe the initial tumor location, geometry, and burden, and parameters that describe the specific patient’s response to treatments. Decision tasks might include personalized treatments [35]. The manufacturing industry is growing, as it contains both simple and complex entities. Projects like AUTOWARE and ReconCell showcase DT use in cognitive manufacturing and robotics [36,37,38]. Tao et al. proposed a hierarchical DT model, distinguishing unit-level DTs (machines/components) and system-level DTs (process lines/shop floors). Rasheed et al. categorized enabling technologies into physical-based modelling, data-driven modelling, big data cybernetics, platforms/infrastructure, and human–machine interfaces [39,40]. Ongoing advances in 3D simulation (e.g., OpenFOAM), machine learning, big data, and IoT/cloud platforms continue to drive DT evolution [41]. Implementation examples include CAD-based models in Altair Inspire Motion, with real inputs managed via MQTT and Twin Activate. However, such tools face limitations in handling complex machines and lack robust AI/ML predictive capabilities. Hybrid approaches combining CAD-based simulations with IoT-linked real-time data support predictive maintenance and feedback control [42,43,44,45]. These approaches limit the representations of digital twins of complex entities with thousands of parameters and constraints among them. Moreover, these DT implementations rely on flat data structures such as JSON or XML to represent sensor readings and asset attributes. While these formats support data exchange, they are insufficient for expressing relationships, dependencies, and constraints that govern complex physical behavior and will lead to inaccurate predictions. Ontology-based approaches have been proposed to address this limitation by introducing explicit semantics into DT representations. Standards such as SSN/SOSA provide a common vocabulary for sensors, observations, and actuators, improving interoperability across heterogeneous systems [38]. Among the earliest standards are the SSN and SOSA ontologies, with SOSA formalized as a W3C recommendation. These ontologies primarily focus on describing sensors, including the data they produce and the systems to which they belong, thereby providing a structured representation of sensor-related information. However, their scope is limited to simple devices that generate outputs only [46]. However, these ontologies do not explicitly model computational procedures, such as AI-based prediction or data transformation steps, nor do they capture multi-physics constraints and operational dependencies that influence final product quality [7]. While SSN/SOSA provide a structured representation of sensor-related information, they remain “static” in nature, focusing on the provenance of data rather than the logic of the entity. The proposed framework advances beyond these by using the CTM ontology to map the physical “rules” (constraints and dependencies) of a machine directly into the AI’s input space. This transforms the AI from a black-box observer into a dependency-aware reasoner that understands, for example, why a temperature increase is a defect in one machine state but normal in another [1]. AI-driven approaches are expected to revolutionize digital twin technology by significantly expanding current reliance on traditional simulations by enhancing real-time decision-making, predictive modeling, and process optimization. Unlike traditional simulation-based methods [47], which often rely on predefined scenarios and assumptions that limit responsiveness due to time-consuming calculations and dynamic environments [48], AI has the potential to learn from vast amounts of historical information, physical simulation, and real-time monitoring data to generate accurate predictions, adapt dynamically to changing conditions, and provide context-based insights and ultimately better informed decisions [19]. AI-driven defect detection [49], predictive maintenance [50], and quality assurance can leverage various sources of data, information, and knowledge without relying only on a single resource-intensive simulation, offering manufacturers a more scalable and efficient approach. In the context of current manufacturing trends where manufacturing ecosystems are increasingly characterized by cyber-physical integration, interoperability, and data-driven decision-making [51], the limitations of traditional simulation-based digital twins in addressing scalability, responsiveness, and contextual awareness have become evident. To address these challenges, we propose an AI-enabled digital twin framework to make real-time forecasting not only using the real-time data, but also using the dependencies and constraints described in the representation of the digital twin to behave like a dependency-aware AI model [1]. However, these approaches do not unify protocol-aware connectivity with dependency-aware AI reasoning for complex physical entities, as achieved in the proposed framework.

2.2. IoT Platforms Supporting Digital Twins

Industry 4.0 DT applications integrate sensors/actuators on IoT platforms using key–value descriptions or platform vocabularies [13,14] or platform-specific vocabularies [15]. Application developers lacking machine expertise create incomplete representations. Moreover, key–value-based models are insufficient to capture the complex relationships among sensors, actuators, automation logic, and machine constraints, making such descriptions difficult to interpret and reuse [52,53]. Although ontology-based approaches have been explored [54,55,56], existing IoT platforms provide only limited semantic support. For example, OpenIoT integrates sensors using the SSN ontology [57,58], while DataTweet enables semantic machine descriptions [59]; however, these approaches do not adequately support the modelling of complex physical entities. Similarly, platforms such as FIWARE rely on predefined domain data models [60,61], which require significant extensions for manufacturing contexts, while Insights Hub IoT employs semantic data interconnects without providing expressive machine models [16]. The CTM [7] ontology has been introduced to capture all the complexities of a complex machine, including its parameters, settings, dependencies, relationships, and constraints. Additionally, it can represent the communication protocols and endpoints, which are required to represent all the digital threads. To overcome the limitations of the existing IoT platform with the lack of semantic representations, our Digital Manufacturing Platform supports digital twin developers in using CTM ontology [7] to represent industrial machines and products, moving beyond the only limitations of SOSA/SSN to capture machine automation, control logic, and multi physical dependencies that have all the necessary information that application developers require to create the manufacturing applications. In this approach, application developers do not require expert knowledge about the entity. Most current IoT platforms configure MQTT, OPC UA, HTTP, etc., at the device or application level rather than representing them as explicit elements of the digital twin, so a twin usually assumes a single dominant protocol or relies on custom glue logic to mediate heterogeneous channels [62]. Several studies emphasize the lack of mechanisms for generating generic and reusable digital twins, as current DT creation workflows depend heavily on proprietary schemas, platform-specific modelling templates, and expert-driven mapping of machine parameters [63,64]. Portability remains a key limitation in existing IoT platforms, as DT creation workflows are often tightly coupled to proprietary schemas, platform-specific device templates, and hard-coded communication logic [65]. Due to limitations in the existing IoT platforms for using simple key–value, JSON-LD, or DTDL mechanisms to describe physical entities, these limit the ability to dynamically bind each communication protocol for sensors, machines, and even AI models’ input and output streams to use multiple protocols for data exchange within the digital twin as well as outside the digital twin with external applications [66,67,68]. To address this, the proposed platform has the ability of managing multi-protocol digital threads (MQTT.OPC UA, HTTP) through a single semantic interface, which allows for individual-entity analysis that generic class-based digital twins cannot achieve. In the proposed platform, communication details are explicitly represented within the DT Description itself, using semantic constructs for communication protocols, endpoints, and topics.

Furthermore, digital twins in manufacturing increasingly rely on AI-driven functions such as anomaly detection, predictive maintenance, multi-sensor reasoning, and decision support to extract actionable insights from operational data. However, in most existing IoT platforms and digital twin solutions, AI capabilities are not natively embedded within the digital twin model itself. Instead, AI/ML models are typically deployed as external analytics services or offline pipelines, with data manually extracted from the platform, processed in separate environments, and reintegrated through custom-coded interfaces or application-specific logic. Recent research in electrochemical machining (ECM) suggests that integrating Explainable AI (XAI) methods, such as SHAP and Grad-CAM, is essential for visualizing process dynamics and detecting anomalies, a capability that next-generation DT platforms must facilitate [69,70]. This separation between the twin and the reasoning engine limits the ability of the digital twin to reason over predictions and prevents AI models from being treated as first-class components of the twin. In contrast, our framework implements Semantic AI Binding, where the AI model is itself a “digital thread” within the twin. This allows for “Dependency-Aware Reasoning”, a capability missing in the current literature, where the framework can automatically invalidate an AI prediction if the underlying physical constraints (defined in the CTM ontology) are violated, ensuring a level of industrial safety and reliability that standard data-driven models cannot guarantee.

2.3. Digital Twins in Manufacturing

Smart manufacturing DTs reveal system vs. entity granularity disparity. While system-level twins optimize shop-floor throughput and energy consumption [71,72], they often fail to address the micro-scale complexities inherent in precision manufacturing processes. The strategic importance of digital representations in manufacturing is highlighted by the need for high-fidelity simulation of physical phenomena. Research has demonstrated that digital models are essential for evaluating CNC machining performance, friction stir welding, and five-axis milling [73]. These virtual environments allow for the proactive analysis of residual stresses, displacement errors, and cutting temperatures in difficult-to-cut materials [74]. However, as established by Soori et al., most existing simulations are utilized as isolated validation tools rather than integrated components of a continuous digital thread [73]. This isolation prevents the bidirectional feedback required to adjust machine parameters dynamically based on observed tool wear or thermal defects during the operation [75]. A fundamental limitation identified in the current manufacturing literature is the lack of digital twin instances (DTI). Most industrial implementations utilize “Type” twins generic models for a class of machines or products, which cannot account for the unique physical evolution of an individual serialized part [76]. In precision sectors, such as composite fabrication or aerospace components, two parts produced using identical designs can exhibit different material properties due to micro-variations in heat exposure or raw material inconsistencies [74]. Consequently, there is an urgent need for frameworks that can instantiate and maintain unique digital records for every individual physical entity, moving beyond general process averages to part-specific quality assurance. To address the complexity of modern manufacturing, where machine settings, environmental data, and material behavior are intrinsically linked, the role of AI is shifting. While traditional regression and neural network models have been applied to risk analysis and quality detection [75,77], they often lack the contextual grounding to provide explainable insights. Furthermore, the scope of industrial AI is expanding beyond traditional time-series methods toward Large Language Models (LLMs) capable of multi-modal reasoning. Optimized pre-trained models (e.g., GPT-2) utilizing multi-modal cross-attention can outperform standard methods by fusing historical sensor data with unstructured inputs, such as maintenance logs or operator records [78]. A robust manufacturing platform must, therefore, provide the architectural flexibility to integrate these diverse AI services as native components of the twin. This ensures that forecasting is not based solely on raw telemetry but is grounded in the semantic dependencies and unique physical constraints of the individual manufacturing entity. Poor accuracy of AI models in manufacturing is not caused by any specific black box or explainable AI model. The cause of poor AI accuracy is due to (1) the physical constraints of the machines, and (2) products that are subject to and affect the data provided to the AI models and the interferences between machine settings and machine/product parameters [20,79].

To address all the gaps identified in recent research, in this paper, we propose a digital twin-based Digital Manufacturing Platform, which includes functionalities such as using CTM ontology for representing industrial machines and products, semantic binding of AI to enable dependency-aware reasoning, and a single semantic interface to manage multiple protocol digital threads to allows individual-entity analysis.

3. Digital Twin Framework

This section defines the conceptual framework for digital twins (DTs) of complex manufacturing entities. The framework specifies what must be included in a digital twin and how each component is related.

In this study, digital twins are defined for complex industrial entities involved in manufacturing, including machines and products. Each such entity is treated as a first-class cyber entity with a dedicated digital twin. The proposed framework extends Grieves’ original three-part digital twin model [27] and the U.S. National Academies’ [12] definition.

The proposed framework builds upon two foundational digital twin definitions widely accepted in the literature. First, it extends Grieves’ original three-part digital twin model (physical entity, virtual model, bidirectional data connections) [24]. Second, it adopts the U.S. National Academies of Sciences, Engineering, and Medicine’s 2024 definition from Foundational Research Gaps and Future Directions for digital twins, co-funded by the U.S. National Science Foundation: “a set of virtual information constructs that mimic the structure, context, and behavior of a physical system and are dynamically updated with data from its physical counterpart”. This framework specifically implements four key principles from the National Academies’ report that distinguish true digital twins from simulators or static models:

• No digital twin exists without sensors; state information must continuously reflect real-world conditions.
• Simulators generating synthetic data alone do not constitute digital twins.
• Abstraction for applications: Digital representations must enable manufacturing applications to interact without understanding implementation details.
• Three-layer architecture: physical twin, virtual twin (semantic DT Description), and digital threads for bidirectional connectivity.

These principles directly inform our architecture, positioning it as a conceptual extension for complex manufacturing entities that overcomes limitations of process-only or type-based digital twins identified in Section 2.

Each digital twin in the framework consists of three conceptual components: (1) physical twin: the real-world entity, including machines, products, materials, people, and associated sensing or actuation capabilities; (2) virtual twin: a semantic, knowledge-graph-based representation that captures parameters, relationships, constraints, dependencies, and embedded AI capabilities integrated with the DT; (3) digital threads: protocol-aware bindings that enable bidirectional data exchange between the physical and virtual twins and between AI models and DTs. This framework addresses limitations in Section 2 through several key design decisions.

• CTM ontology-based semantically rich knowledge-graph-based representations for complex entities consisting of a physical entity and AI representation.
• Considering additional devices, sensors as the physical twin, when representing entities like products, materials, or people.
• Closed-loop AI control via semantic bindings of AI in the knowledge graph.
• Multi-protocol digital threads to allow for an individual-entity digital twin rather than a generic class-based digital twin.

These are all summarized in the framework presented in Figure 1.

3.1. Physical Twin

The physical twin represents the tangible manufacturing entity and the means by which its state is observed or influenced. Physical twins may correspond to machines, products, materials, or people, depending on the manufacturing context. For machines, the physical twin may directly expose built-in sensors, machine parameters, and automation interfaces. In such cases, no additional sensing infrastructure is required, but embedded automation logic must be explicitly modeled to ensure correct interaction with the digital twin [80]. For products and materials, the physical twin often includes supplementary sensing or measurement devices required to observe quality-relevant properties (e.g., temperature, composition, spectral characteristics) [9,10]. In industrial settings, quality measurements may be produced by specialized equipment operated either autonomously or by human operators. In such cases, the physical twin encompasses both the measurement system and, where relevant, the human actor involved in the measurement process [11]. When representing people, the physical twin may include wearable sensors or other monitoring devices that capture motion, posture, or physiological indicators relevant to production activities.

This approach differs from traditional physical–virtual separations in prior literature, as physical twins may hierarchically include other digital twins for complex state translation. While simple cases involve direct sensor readings, industrial quality assessment often requires sophisticated measurement equipment operated autonomously or manually, highlighting the framework’s capability to handle complex entity interactions beyond basic IoT sensor connectivity.

3.2. Virtual Twin

The virtual twin provides a comprehensive digital representation of a specific manufacturing physical entity, serving as the primary interface for applications to understand and interact with the physical counterpart. The virtual twin comprises three main elements: (1) DT Description, (2) trained AI model(s), and (3) DT orchestrator. A conceptual description of each component is presented in the section below.

3.2.1. DT Description

The DT Description constitutes the knowledge-graph-based representation for digitally modeling complex manufacturing entities and enabling their corresponding digital twins. This structure captures measurable/controllable properties, parameter relationships, physical/operational constraints, settings dependencies, AI model representations (inputs, outputs, execution bindings), and communication details (protocols, endpoints) reviewed in Section 2. Manufacturing systems exhibit physical constraints, and delayed responses cannot represent by key–value structures; for example, machine setting changes produce non-instantaneous, nonlinear, state-dependent effects requiring explicit representation for safe digital twin operation.

To address IoT platform limitations identified in Section 2, this framework adopts the CTM ontology presented in [7], extending SSN/SOSA’s sensor/observation constructs with classes for machine inputs/outputs, settings, automation, control logic, communication protocols, and endpoints. Trained AI models for predictions/translations integrate within digital twins, with their representations, protocols, and endpoints captured via CTM classes to enable communication with AI models.

This structured DT Description enables sophisticated SPARQL querying (“Which parts using material X experienced temperature anomalies in stage Y?”, “Which sensors detected out-of-range values?”, “What are predicted/historical trends for tensile strength/thermal stability?”). This comprehensive representation consists of semantic bindings of AI transforming digital twins from passive monitors into proactive predictive systems, eliminating reliance on predefined setpoints, historical recipes, or operator intuition. Application developers use the DT Description as the sole knowledge source for each digital twin’s physical entity, integrated AI models, and protocol bindings.

3.2.2. Trained AI Model(s)

A digital twin may incorporate multiple trained AI models, each serving distinct purposes such as data translation, prediction, or optimization. Some models operate at lower levels (e.g., translating raw sensor signals into meaningful physical quantities), while others perform higher-level reasoning to improve efficiency, quality, or reliability. The proposed platform is intentionally model agnostic, allowing any suitable AI approach to be integrated. What is essential is that AI models are semantically represented within the DT Description, which provides semantic binding of AI that enables their inputs, outputs, and dependencies to be explicitly defined and orchestrated within the digital twin.

3.2.3. DT Orchestrator (Conceptual Role)

Within the framework, the DT orchestrator is the logical component responsible for coordinating interactions among physical entities, AI models, and applications. Conceptually, it interprets the DT Description, resolves relevant digital threads, and ensures consistent bidirectional data flow. This is the component that exposes the DT Description to the application developers to create the digital manufacturing applications using specific digital twins. Detailed runtime behavior and platform-specific orchestration mechanisms are described in Section Instantiation of the Digital Twin.

3.3. Digital Threads

Digital threads constitute the communication layer enabling bidirectional interaction between physical and virtual twins, facilitating measurement acquisition and setting actuation across diverse protocols. The framework leverages the existing industrial and IoT protocols, which are already available in industrial IoT platforms for comprehensive bidirectional data exchange. For instance, Power over Ethernet (PoE) security cameras utilize RTSP (video streaming), HTTP (configuration), MQTT (alerts), ONVIF (interoperability), and G.711 µ-law (audio), demonstrating protocol specialization.

As detailed in Section 3.2.1, the knowledge graph captures complete communication specifications within each DT Description, encompassing physical entity digital threads (machine properties) and AI digital threads (model input/output streams). This enables precise protocol routing: high-frequency streaming, configuration management, real-time notifications, control commands, or interoperability with third party systems like different servers that handle AI. This multi-protocol approach extends IoT platforms beyond sensor–actuator limitations, generalizing protocol usage across all digital twin components, including AI model interactions. While smart home systems and industrial applications already utilize multiple protocols, current IoT platforms primarily focus on sensor–actuator interactions. This study generalizes protocol usage across all digital twin components, including AI model interactions.

A detailed description of physical entities, digital threads, and AI digital threads is presented in the following sections.

3.3.1. Physical Entity Digital Threads

Physical entity digital threads are responsible for either receiving measurements from the physical entities corresponding to DT Description concepts with input direction bindings or sending control commands (setpoint) to actuators of the physical entities associated with DT Description concepts having output direction bindings, assuming MQTT as the standard protocol for communication with sensor readings, with each physical entity digital thread configured accordingly.

3.3.2. AI Digital Threads

AI digital threads manage the data exchange between AI models and the digital twin (DT) orchestrator by connecting the input and output data streams of AI model bindings with the corresponding DT Description concepts, assuming HTTP as the standard protocol for communication with AI models, with each AI digital thread configured accordingly.

4. Digital Manufacturing Platform

This section presents the architecture of the proposed digital twin-based Digital Manufacturing Platform. The platform introduces three novel functionalities addressing limitations in existing IIoT platforms: (1) The CTM ontology representing industrial machines and products, moving beyond the only limitations of SSN/SOSA to capture machine automation, control logic, and multi physical dependencies. (2) Semantic Binding of AI: Unlike standard IIoT research where AI is a loosely coupled analytic service, our framework treats the AI model as a first-class component of the twin’s description, enabling dependency-aware reasoning. (3) The innovation of managing multi-protocol digital threads (MQTT.OPC UA, HTTP) through a single semantic interface, which allows for individual-entity analysis that generic class-based digital twins cannot achieve.

The following subsections illustrate these capabilities through dedicated diagrams: Section 4.1 details physical entity representation and digital twin integration; Section 4.2 presents AI model representation and interaction patterns; Section 4.3 describes orchestration creation for manufacturing applications; Section 4.4 examines scalability and extensibility; and Section 4.5 outlines platform limitations.

The Digital Manufacturing Platform includes a web interface that allows users (e.g., DT developers and application developers) to interact with the platform and consumes the services provided by the platform. Next, we briefly describe the three phases provided by the platform to support creating digital manufacturing applications using digital twins created by the platform.

4.1. Digital Manufacturing Platform Supports Physical Entity Representation, Integration, and Interaction in DTs

Figure 2 illustrates how Digital Manufacturing Platforms allow the DT developer to create knowledge-graph-based representation of the physical entity and its integration and interaction in digital twins. In this study, we refer to the knowledge-graph-based representation as “DT Description”, as presented as a component in the virtual twin in the digital twin framework. The following subsections illustrate how each platform service and repositories provided by the platform is used to achieve that.

4.1.1. DT Modelling Service

The process begins with CTM ontology-based modelling of the physical entity to construct a DT Description (knowledge graph), which serves as input to the DT Modelling Service. This service acts as an editor enabling digital twin developers to create and refine DT Descriptions by specifying parameters, operational settings, relationships, and constraints characterizing the physical entity. Each semantic entity representing a measurable, controllable, or descriptive property is termed a “DT Description Concept”.

For example, in the milk pickup monitoring application, the milk pickup truck machine is first modelled using the CTM ontology. This model provides input to the DT Modelling Service, allowing developers to define machine-specific parameters, settings, relationships, and constraints to generate the complete DT Description

4.1.2. DT Description Repository

To make the produced DT Descriptions accessible by other components in the platform, applications, and other external digital twins, there is a necessity to store them. DT Description Repository is an RDF Triple store that allows storing, querying, and retrieving the DT Descriptions of the physical entities generated by the DT Developer in Section 4.1.1.

Unlike existing industrial IoT platforms that rely primarily on key–value pair modelling, the proposed platform adopts a semantically rich DT Description using CTM ontology (Section 3.2.1), enabling complex relationships, contexts, and behaviors of physical and virtual entities to be captured and queries using technologies like SPARQL.

4.1.3. Protocol Implementation Repository

The platform manages multi-protocol communication by enabling DT developers to either add new protocols or utilize existing protocols available from the IoT platform’s open-source Protocol Implementation Repository. These implementations are not digital twin-specific but reusable across services and multiple digital twins. Protocols are registered with their Protocol Name (PN) alongside the Protocol Implementation (PI), which includes executable code or integration logic for communication/data exchange. This version-controlled repository ensures universal accessibility and reusability for all platform components.

4.1.4. Protocol Configuration Service

To create configured protocols, DT developers first select a Protocol Name (PN) and query the Protocol Implementation Repository via the Protocol Configuration Service. This returns the (PN, PI) pair, where PI provides the URL pointer to the executable implementation, eliminating manual configuration. Pre-registration avoids runtime discovery latency, PI URLs ensure container-agnostic deployment (Docker/Kubernetes), RESTful APIs standardize access, and MQTT/CoAP/OPC UA deliver proven industrial protocol support.

During digital twin runtime, Protocol Implementations map to Protocol Configurations (PCs) specific to each digital twin. PCs define protocol usage templates specifying parameters, topics, tags, subscriptions, ports, endpoints, and data structures, which are then populated with actual values.

The Protocol Configuration Service generates configured protocol tuples by mapping each PC with its corresponding (PN, PI) pair in the following format:

Configured Protocol = (Configured Protocol ID, PN, PC, PI)

(1)

4.1.5. Protocol Configuration Repository

This service allows storing and retrieving the created Configured Protocol tuples in Section 4.1.4 to support creating multi-protocol digital threads in Section 4.1.6. As illustrated in the figure, each configured protocol existing in the repository is identified by the “Configured Protocol ID”.

4.1.6. DT Binding Service

To enable multi-protocol digital thread management through a unified semantic interface, the platform allows DT developers to map configured protocols to DT Description concepts. This innovation supports diverse communication protocols across Physical Twin entities, as outlined in Section 3.3.2, enabling seamless integration of heterogeneous industrial protocols.

The DT Binding Service facilitates developer association of DT Description concepts with configured protocols retrieved from the Protocol Configuration Repository and DT Description Repository. Each binding passes a (DT Description Concept, Configured Protocol Variable) pair to the service. Assuming protocols support appropriate physical twin data structures, the service executes two operations: (1) it stores generated physical entity digital threads, and (2) it updates the DT Description with these digital thread bindings.

4.1.7. Digital Thread Repository

Physical entity digital threads are stored in the Digital Thread Repository, uniquely identified by Digital Thread ID:

Physical Entity Digital Thread = (Digital Thread ID, DT Description Concept, Configured Protocol Variable)

(2)

Through this mechanism, application designers interact exclusively with high-level DT Description concepts, while the platform transparently resolves underlying protocols, configurations, and data channels. This abstraction layer enables scalable integration of heterogeneous devices, sensors, machines, and AI services without requiring application-level protocol expertise.

At phase completion, DT developers receive a Bound DT Description (.ttl file) defining measurable/controllable entities as concepts linked to configured protocols, including protocol names, URLs, endpoints (topics/NodeIds), and implementation pointers. This concludes the binding phase, delivering production-ready, protocol-agnostic physical entity digital twins as specified in the digital twin framework.

4.2. Digital Manufacturing Platform Supports AI Representation, Integration, and Interaction in DTs

To enable dependency-aware reasoning, the digital twin framework serves AI models as a first-class component of the DT Description. To support that, our platform allows the DT developer to create a semantic knowledge-graph-based representation including AI and generate AI digital threads supporting multi-protocol integration alongside physical entities as illustrated in Figure 3.

To support semantic biding AI, the same DT Modelling Service can be used to update the DT Description created at the end of Section 4.1. This paper does not contribute to AI models for digital manufacturing beyond proposing an architecture that shows how AI models are incorporated and utilized in digital twins for machines and products, and how the proposed Digital Manufacturing Platform incorporated these to support digital manufacturing applications. Consequently, we assume the DT developer has trained AI models, which are required for the digital twin offline. As a result, they are aware of all the input and output data streams of all the AI models used in the digital twin.

These dependencies are formally represented within the DT Description during the AI representation phase. Upon completion, DT developers receive an updated Bound DT Description (.ttl file) incorporating physical entity digital threads and AI representations with complete dependency mapping.

4.2.1. Trained AI Model Repository

To support platform’s model-agnostic capability, allowing any suitable AI approach to be integrated, trained AI models, developed by DT developers using domain-specific data, are stored in the Trained AI Model Repository for runtime utilization. Each model entry comprises the AI Model Name (AIN) and AI Model Implementation (AII), where AII includes model architecture and source code, trained parameters/weights, configuration metadata, and usage documentation. This standardized storage ensures model reusability, version control, and platform-wide accessibility.

AI Model Instantiation: During digital twin instantiation, the DT Orchestrator utilizes AI Model Implementations (AII) to deploy executable model instances and expose dedicated communication endpoints. These operationalized trained AI models manifest as Trained AI Model(s) components within the virtual twin layer of the digital twin framework.

4.2.2. AI Model Configuration Service

AI model configuration follows the protocol configuration approach using dedicated platform services and repositories. The AI Model Configuration Service accepts AI Name (AIN) input, querying the Trained AI Model Repository to retrieve the (AIN, AII) pair, where AII provides a URL pointer to the model inference service location (analogous to PI).

DT developers specify AI Model Configuration (AIC), defining model execution within specific digital twins, including input/output mappings, execution frequency, endpoint details, and security policies. This generates Configured AI Model tuples with the following structure:

Configured AI Model = (Configured AI Model ID, AIN, AIC, AII)

(3)

4.2.3. AI Configuration Repository

The configured AI models created in Section 4.2.2 are stored in the AI Configuration Repository, enabling consistent reuse and lifecycle management. As illustrated in the figure, each configured protocol existing in the repository is identified by the “Configured AI Model ID”.

4.2.4. DT Binding Service

Once configured, the same DT Binding Service is used bind the DT Description concepts created for each input and output data stream of the AI model with configured protocols and the Configure AI Model Variable. This mechanism creates AI digital threads, extending the same binding principles used for physical entities. The input to the binding service is the triplet (DT Description Concept, Configured AI Model Variable, Configured Protocol Variable). The DT developer will use these and create AI digital thread tuples with the following structure:

AI Digital Thread = (Digital Thread ID, DT Description Concept, Configured Protocol Variable, Configured AI Model Variable)

(4)

The service then (1) updates the Bound DT Description in the end of Section 4.1 with AI digital threads and (2) stores the generated AI digital threads in the Digital Thread Repository.

4.2.5. Digital Thread Repository

The created physical entity digital threads are stored in the Digital Thread Repository. As illustrated in the figure, each thread existing in the repository is identified by the “Digital Thread ID”.

At phase completion, DT developers receive the Bound DT Description (.ttl file) integrating physical entity and AI digital threads, with each concept explicitly linked to its communication protocol and for the AI models’ corresponding input/output data streams.

AI Digital Threads, framework components, enable runtime communication between DT Orchestrators and AI models. The Digital Manufacturing Platform operationalizes the DT Description by instantiating entities, relationships, constraints, and AI capabilities through standardized protocol bindings. Application developers interact exclusively with DT Descriptions, while the platform transparently manages protocol resolution, AI integration, and data flows. This study employs MQTT, HTTP, and OPC UA for their prevalence in industrial IoT, low-latency performance, and heterogeneous device compatibility.

4.3. Digital Manufacturing Platform Supports DT Orchestration and Incorporation in Digital Manufacturing Applications

The Digital Manufacturing Platform enables development of digital manufacturing applications leveraging digital twins for individual machines, products, materials, and entities, with applications combining multiple digital twins for higher-level functionality. This study emphasizes digital twin-level intelligence through AI model integration within digital twins.

The DT Orchestrator integrates configuration artifacts from Section 4.1 and Section 4.2, extending traditional API orchestration with digital twin-specific capabilities to function as the digital twin operating system [81,82]. Unlike conventional API aggregators, the DT Orchestrator dynamically queries the DT Description Repository, selects digital threads from the Digital Thread Repository, invokes physical entity digital threads and trained AI models via Configured Protocol Tuples, and exposes a unified semantic API to developers. This architectural extension justifies the “DT Orchestrator” designation and advances beyond existing API orchestration literature.

As shown in Figure 4, DT developers construct the DT Orchestrator without predefined input/output knowledge, implementing core interactions extensible as needed. The DT Description provides a unified namespace mapping DT Description concept to sensors, AI models, protocols, and digital threads. The DT Orchestrator manages communication/data flow identifying digital threads, handling configured protocols, collecting inputs from physical twins/AI models, processing outputs, and delivering responses via standardized APIs for application development.

Applications interact exclusively through the DT Protocol, remaining agnostic to physical twin protocols and low-level implementation details. Upon receiving an application request, the DT Orchestrator resolves it by querying the Bound DT Description, activating relevant physical entity digital threads, collecting/processing data, and serving output while abstracting protocol complexity.

Instantiation of the Digital Twin

During digital twin (DT) instantiation, the Docker-based DT Orchestrator clones protocol repositories (e.g., http://x.x.x.x:3000/repo/mqtt.git) from the Protocol Implementation Repository into the local container, making client libraries, templates, and Python v3.11 scripts available for runtime instantiation and communication with sensors and AI models as defined in the DT Description. During image build, it fetches AI model repositories, executes their Dockerfiles to create dedicated containers with dependencies and inference services, and exposes endpoints (e.g., CNN–LSTM at http://x.x.x.x.5000/v1/models/temperature-prediction/) for predictions. This ensures reproducible deployments and seamless integration. The orchestrator exposes DT Description and DT Protocol to application developers via “/dt/{dtId}/description” and “/dt/{dtId}/protocol” endpoints, respectively. Applications can communicate with the specific digital twin via OPC UA DT Protocol through “/dt/{dtId}/input” and “/dt/{dtId}/output”.

4.4. Scalability and Extensibility of the Digital Manufacturing Platform

Scalability is achieved through separation of concerns into independent microservices, enabling workload-specific scaling. Protocol handling and AI inference services replicate independently without modifying DT Descriptions or application logic. Configured tuples, protocols, physical entity digital threads, configured AI models, and AI digital threads manage numerous digital twins through configuration rather than redesign. The DT Orchestrator supports complex AI pipelines by binding model outputs (e.g., translation) to downstream inputs (e.g., optimization), providing standardized plumbing without custom wiring.

Extensibility is ontology-driven and repository-based, enabling incremental evolution without core orchestration changes. New physical entities, sensors, machines, AI models, or protocols integrate via CTM-based DT Description extensions through the DT Modelling Service and repository registration. New protocols require only Protocol Name entries in the Protocol Implementation Repository; new AI models need AI Name, AI Implementation, and AI Configuration entries. The DT Binding Service generates immediately consumable digital threads used by the existing DT Orchestrator via standard APIs, ensuring backward compatibility with emerging technologies.

4.5. Limitations of the Digital Manufacturing Platform

Despite its comprehensive capabilities, the Digital Manufacturing Platform exhibits several limitations requiring future research. AI usage occurs at three conceptual levels: data translations, digital twin-level intelligence, and application-level intelligence. This work addresses only digital twin-level intelligence, assuming externally trained AI models registered post-training in the Trained AI Model Repository via AI Model Name (AIN) and AI Model Implementation (AII). Future work will integrate training simulators generating synthetic data from DT Description constraints and in-platform model training services for end-to-end AI lifecycle management.

Runtime performance overhead from semantic querying (SPARQL over DT Descriptions) and dynamic digital thread resolution may impact latency in time-critical scenarios. While enhancing flexibility, this design necessitates caching, query optimization, or hybrid approaches for real-time constraints. Automated orchestrator discovery assuming known endpoints currently is excluded from scope, with future exploration of LLM-based mechanisms like recent API orchestration frameworks.

5. Proof-of-Concept Implementation of the Digital Manufacturing Platform

This section details the proof-of-concept implementation of the Digital Manufacturing Platform outlined in Section 4, specifying the software and technologies used for each component. As shown in Figure 5, the platform operates as a containerized microservices architecture, supporting independent development, deployment, and scaling of components. This implementation serves as the basis for platform evaluation in Section 6.

5.1. Implementation Environment and Experimental Setup

The proof-of-concept was deployed on Nectar Research Cloud (Ubuntu 20.04 LTS instances) with the following infrastructure:

• Web Server Instance (8 GB RAM, 4 vCPU, 30 GB disk): Hosts four Docker containers via Docker Compose v5.0.1, comprising WebProtege v3.0.0 (https://hub.docker.com/r/protegeproject/webprotege (accessed on 15 September 2025)) for DT modelling and three Flask 3.0.3 microservices [83,84]:
• protocol-config-service:1.0: GET/protocols/{PN} and POST/configure (use protocol_config schema)
• ai-config-service:1.0: GET/models/{AN} and POST/configure (use ai_config schema)
• dt-binding-service:1.0: POST/digitalthreads → digital_threads schema
• Orchestrator VM Instance(s) (4 GB RAM, 2 vCPU, 30 GB disk): One dedicated instance per digital twin hosting dt-orchestrator-{dtId}:1.0 (FastAPI v0.128.0, port 80) serving DT-specific web UI and REST API with auto-generated OpenAPI/Swagger documentation.
• DT Description Instance (4 GB RAM, 2 vCPU, 30 GB disk): Deploys Apache Jena Fuseki 5.6.0 Docker container as RDF triple store using https://jena.apache.org/download/ (accessed on 22 January 2026).
• Data Repository Instance (4 GB RAM, 2 vCPU, 30 GB disk): Deploys PostgreSQL v15.4 database dm_platform_db (postgres:v15.4; port 5432) with three repository schemas and Gitea 1.25.4 (https://docs.gitea.com/installation/install-with-docker (accessed on 10 January 2026)):
• PostgreSQL Schemas (dm_platform_db): The database contains three schemas. The protocol_config schema stores configured protocol, including configured_protocol_id, protocol_name, protocol_configuration (JSON), protocol_impl (Gitea ref). The ai_config schema stores configured AI model including configured_ai_model_id, ai_model_name, ai_model_configuration (JSON), ai_model_impl (Gitea ref). The digital_threads schema captures type (physical/ai), digital_thread_id, dt_concept (RDF URI), configured_protocol_id, configured_ai_model_id.
• Gitea hosts Repositories for Protocol implementations include mqtt_client.py, and Trained AI models includes cnn-lstm_temppredict:v1.0.

5.2. Implementation Challenges and Solutions

Several key challenges emerged during proof-of-concept deployment and were systematically addressed.

• Semantic Query Performance: Initial SPARQL queries over 50 K RDF triples exceeded 2 s latency. Apache Jena Fuseki 5.6.0 with TDB2 backend and query caching reduced response times to 38 ms, enabling real-time DT binding.
• Multi-Protocol Blocking: Concurrent MQTT, OPC UA, and HTTP streams caused blocking under high-frequency data. Python asyncio v3.11 with Digital Thread abstraction enabled non-blocking, concurrent protocol execution while maintaining semantic mappings.
• AI Model Reproducibility: Versioning risks across DT lifecycles. Git tagging + Docker image pinning (e.g., cnn-lstm-temppredict:v1.0) ensured reproducible inference and rollback capability.
• Container Orchestration: Startup ordering failures. Docker Compose v2.20.1 health checks and explicit depends on constraints achieved stable deployment sequencing.
• Network Latency: Nectar Cloud cross-instance communication. Internal Docker networking + PostgreSQL v15.4 connection pooling reduced orchestration latency to <5 ms.
• Repository Management: Plain Git lacked web access and authentication for protocol implementation code (e.g., mqtt_client.py) and trained AI model artifacts (e.g., cnn-lstm_temppredict:v1.0). Gitea 1.25.4 provided HTTP/SSH access, web UI, and authentication enabling scalable management across multiple digital twins.

5.3. Explicit Mapping Between the Proposed Framework and the Platform Implementation

The proof-of-concept implementation precisely realizes Section 3’s digital twin Framework (Figure 1). Physical twin entities (machines, products, materials, people + sensors, Section 3.1) connect via physical entity digital threads (Section 3.3.1) through protocol-config-service:1.0 (GET/protocols/{PN}, POST/configure), storing configured protocols in protocol_config schema referencing Gitea (mqtt_client.py) and dt-binding-service:1.0 (POST/digitalthreads) creating threads stored in digital_threads schema (type = physical).

Virtual twin (Section 3.2) maps to DT Description Instance (Jena Fuseki v5.6.0, http://x.x.x.x:3030/composite-airframe-product/query, CTM/SSN-SOSA, Section 3.2.1), ai-config-service:1.0 (GET/models/{AN}, POST/configure), storing configured models in ai_config schema referencing Gitea (cnn-lstm_temppredict:v1.0, Section 3.2.2) and Orchestrator VM instances (dt-orchestrator-{dtId}:1.0, FastAPI v0.128.0 port 80, Section 3.2.3).

AI digital threads (Section 3.3.2) link AI models to DT concepts via digital_threads schema (type = ai, configured_ai_model_id). The dm_platform_db multi-schema PostgreSQL v15.4 design implements Section 3.2.1’s knowledge graph representation with logical repository isolation (protocol_config, ai_config, digital_threads). Per-DT Orchestrator instances and Docker Compose microservices on Nectar Research Cloud validate scalable architecture, providing complete traceability from conceptual framework (Figure 1) to production deployment (Figure 5).

6. Functional Assessment of Digital Manufacturing Platform Support Developing Different Digital Manufacturing Applications Using Digital Twins

In this section, we present the assessment of the proposed Digital Manufacturing Platform for its ability to support developing diverse digital manufacturing applications leveraging digital twins of complex physical entities to improve product quality. This section focuses on functional capabilities rather than platform performance. It demonstrates generality and reusability of the platform that the same Digital Manufacturing Platform can support fundamentally different digital twins, serving different applications across different manufacturing sectors, without redesigning the platform.

The composite curing application is chosen particularly because the application incorporates a digital twin of a product that represents multiple sensors and integrates AI models to make curing predictions handle communication via multiple industrial protocols. Next, we choose the product quality improvement application from the food manufacturing industry as it uses a digital twin of a machine that has physical dependencies, which impact on product quality.

6.1. Composite Curing Application Use Digital Twin of Composite Airframe Part to Improve Product Quality

In the liquid composite molding (LCM) process, manufacturing proceeds through resin infusion, composite curing, and demolding stages. HexFlow RTM6 epoxy resin served as the matrix system in this study. Resin heating to 100 °C during the fill ramp reduced viscosity, facilitating efficient permeation through the fiber preform. This temperature was maintained throughout infusion to ensure uniform impregnation. Curing commenced at 180 °C for 2 h, following manufacturer specifications to achieve target cure degree and glass transition temperature (Tg). Continuous monitoring of thermal profiles and dielectric properties mitigated exothermic runaway risks inherent to HexFlow RTM6, ensuring curing uniformity. Controlled cooling post-curing enabled safe demolding of the composite component.

The subsequent section presents a Composite Curing Quality Improvement Application, ensuring adherence to manufacturer-specified thermal profiles [9] during airframe part production. This application leverages the Composite Airframe Part digital twin for real-time process monitoring and AI-based forecasting of part temperature and resin glass transition temperature (Tg), preventing thermal deviations that compromise structural integrity. Section 6.1.1 details digital twin creation for the composite airframe part.

The CNN-LSTM hybrid model was selected for thermal profile forecasting due to its proven efficacy across multiple thermal applications [9,85,86], where CNN effectively extracts complex spatial patterns from multi-sensor temperature distributions while LSTM captures temporal dependencies and thermal inertia throughout curing cycles.

6.1.1. Digital Twin of Composite Airframe Part

As described in Section 3, each digital twin consists of a physical twin, a virtual twin, and digital threads.

• Physical twin

The composites manufacturing process operates sequentially, initiating process monitoring via sensors, which are thermocouple, dielectric, and heat flux sensors during curing. The thermocouple sensor monitors part temperature, the dielectric sensor captures electrical properties correlated with resin viscosity and glass transition temperature (Tg), and the heat flux sensor measures heat transfer rates arising from conduction, convection, and radiation during curing. This data is used in the curing application to improve product quality.

As explained in Section 3.1, to represent a product digitally, supplementary sensors or devices used to collect properties of the product are required. Therefore, the physical twin of the composite airframe part is depicted in Figure 6.

2.

Virtual twin

Figure 7 depicts the CTM ontology-based DT Description of the airframe part. “ssn”, “sosa”, and “cto” prefixes are used for properties of SSN, SOSA, and CTM ontologies, respectively. The Composite Product System is modelled as a system (ssn:System). Following the CTM ontology [7,87], each system receives a unique identifier via cto:Identification (e.g., DT_001), enabling SPARQL queries to the DT Description Repository for DT Descriptions retrieval.

• Physical Entity Representation

Three sensors (thermocouple, dielectric, heat flux) are modeled as sosa:Sensor integrated via cto:hasSensor to the composite system. Monitored properties like temperature, resin resistivity/Tg, and heat rate are represented as sosa:ObservableProperty. Sensor observations employ sosa:Observation with sosa:Result and xsd:dateTime timestamping. MQTT/TCP communication endpoints use datatype properties cto: URL, cto:CommunicationProtocol, cto:Namespace, and cto:SubscribedTopic (e.g., thermocouplesensor001/temperature).

• AI Representation

CNN-LSTM (Model_001_PartTempandTg) and MLP (Model_002_CtoV) models are reusable sosa:procedure instances with unique cto:Identification, integrated into the composite product system. Each model features dedicated HTTP/REST endpoints (cto:Url) for ssn:Input/ssn:Output exchange via CommunicationProtocol. CNN-LSTM links temperature and Tg as ssn:hasInput, producing PredictedTempandTg as ssn:hasOutput. MLP uses resistance as ssn:hasInput, outputting viscosity as ssn:hasOutput.

3.

Digital Threads

As described in Section 4.1, both physical entity and AI digital threads facilitate communication between virtual and physical twins.

Table 1. Configured protocols and configured AI models for digital twin of airframe part.

Repository	ID	PN or AIN	PC or AIC	PI or AII
Protocol Configuration (protocol_config)	mqtt_001	MQTT	{broker:“tcp://x.x.x.x:1883”, topic:“/thermocouplesensor001/temperature”, qos:1}	http://x.x.x.x:3000/repo/mqtt.git
	mqtt_002	MQTT	{broker:“tcp://x.x.x.x:1883”, topic:“/dielectricsensor001/resistance”, qos:1}	http://x.x.x.x:3000/repo/mqtt.git
	http_001	HTTP	{base_url:“http://x.x.x.x:8080/v1/models/temperature-prediction/”, method:“POST”}	http://x.x.x.x:3000/repo/http.git
	opcua_001	OPC UA	{url:“opc.tcp://x.x.x.x:4840/”,security_mode:“None”, node_id:“ns=2;i=1001”, subscription_interval:500}	http://x.x.x.x:3000/repo/opcua.git
AI Configuration (ai_config)	model_001	CNN-LSTM	{output:“PredictedTempandTg”, input:“Temperature,Tg”}	http://x.x.x.x:3000/repo/cnn-lstm_temppredict.git
	model_002	MLP	{output:“Viscosity”, input:“Resistance”}	http://x.x.x.x:3000/repo/mlp_viscopredict.git

presents the configured protocols and configured AI models resulting in a digital twin of the composite airframe part. These configured protocols and configured AI models are stored in the Protocol Configuration Repository and AI Configuration Repository, respectively, following the schema presented in Section 5.

Even though the platform is capable of handling multiple-protocol digital threads for both physical entities and AI models, in this study, we use HTTP as the AI protocol without loss of generality, which is widely adopted for REST-based inference services and ensures interoperability.

Next,

Table 2. Physical entity and AI digital threads for digital twin of composite airframe part.

Type	Digital Thread ID	DT Concept	Configured Protocol Id	Configured AI Model Id
Physical	dth_001	Temperature	mqtt_001	NULL
Physical	dth_002	Resistance	mqtt_002	NULL
AI	dth_003	PredictedTempandTg	http_001	model_001
AI	dth_003	Viscosity	http_002	model_002

presents how these above-configured protocols and configured AI models are used to create both physical entities and AI digital threads. All these digital threads are stored in the Digital Threads Repository, as presented in Section 5.

Physical entity digital threads (dth_001, dth_002) enable sensor data ingestion (MQTT), while AI digital threads (dth_003, dth_004) route predictions from CNN-LSTM and MLP models to DT concepts, demonstrating complete protocol-aware binding across the Digital Manufacturing Platform repositories (dm_platform_db).

6.1.2. Development of Composite Curing Application to Improve Product Quality

The composite curing application is created using a digital twin of the composite airframe presented in Section 6.1.1. It visualizes predicted part temperature and Tg values alongside the manufacturer’s thermal curve to detect curing deviations. Figure 8 illustrates the end-to-end workflow integrating real-time sensor data and AI predictions for quality improvement.

The application visualizes CNN-LSTM forecasts via Power BI dashboards (Figure 9), comparing real-time temperature (dth_001) and Tg (dth_002) measurements against 10-ahead predictions generated every 10 s. Figure 8 illustrates the complete workflow: POST requests to dt/DT_001/input (PredictedTempandTg) trigger SPARQL queries retrieving DT_001 semantics and Model_001 (CNN-LSTM) configuration. The DT Orchestrator collects second-by-second sensor streams through physical entity digital threads, interpolating to 10 s model inputs via dth_003. Forecasts expose alongside real-time evolution via OPC UA endpoint dt/DT_001/output.

Cure profile monitoring continuously validates against HexFlow RTM6 manufacturer specifications (100 °C fill ramp → 180 °C/2 h hold). Deviations exceeding ±5 °C (temperature) or ±2 °C (Tg) trigger Power BI alerts, signaling exothermic runaway or incomplete cure risks. Proactive interventions (manual or automatic) adjust heat rates or activate cooling via identical request patterns with updated setpoints, preserving composite structural integrity. Digital threads integration unifies:

• Physical Entity: dth_001 (temperature), dth_002 (Tg), dth_003 (interpolation)
• AI Digital Thread: CNN-LSTM (Model_001) 10-ahead forecasting

The application demonstrates semantic orchestration enabling physics-aware, deviation-driven process control across complex composite manufacturing cycles.

Figure 9 illustrates the real-time visualization of manufacturing process parameters and predictive forecasting of process trends generated by the CNN-LSTM resin cure model. The interface integrates live sensor data with forecasted values such as part temperature and glass transition temperature (Tg) to support informed, AI-driven decision-making.

6.2. Product Quality Improvement Application Using a Digital Twin of a TFE Machine for Improving Product Quality

In industrial yeast paste manufacturing, the evaporation phase critically determines final product consistency as the key quality attribute. This application targets the evaporation process, where diluted yeast extract concentrates to target the solids percentage using two coupled machines, a Steam Pressure Controller (SPC) and Thin Film Evaporator with condenser (TFE). The SPC regulates steam pressure (P401) via continuous sensor monitoring (P402) and valve adjustment, while the TFE evaporates water under vacuum control, tracking density (D303), vacuum (P502), temperature (T304), motor voltage (E306), and flow (F307). Operator yeast type selection via HMI automatically initializes optimized setpoints for SPC steam pressure, TFE discharge solids (D301), and vacuum (P501). The inline-calculated discharge solids percentage (D302), produced by the DischargeSolidsAutomation module, serves as the primary real-time quality indicator, strongly correlating with delayed offline RFM measurements (D304) despite 1–2 h transport delays. D302 deviations trigger quality alerts: values too low signal batch failure requiring reprocessing, while values too high indicate energy overuse.

The Machine State Learner (MSL) model was selected following [80], which presents a novel algorithm specifically designed to capture dependencies between product quality metrics (D302 solids percentage) and machine states, enabling real-time goodness score generation and proactive intervention during evaporation to minimize low-solids batches while optimizing TFE productivity.

6.2.1. Digital Twin of TFE Machine

4.

Physical Twin

As shown in Figure 10, the TFE machine incorporates a discharge solids controller and vacuum pressure controller.

The discharge solids controller monitors the discharge density sensor (D303), while the vacuum pressure controller utilizes the vacuum pressure setting (P501), pressure sensor (P502), and temperature sensor (T304) to regulate pressure through actuation of the pressure control valve. Additionally, the TFE features a voltage sensor (E306) and flow rate sensor (F307). All sensor measurements and computed values from the TFE are exposed as machine outputs.

5.

Virtual Twin

Figure 11 depicts the CTM ontology-based DT Description of the TFE machine (MachineID: k8:22:eb:33:xx:xx). Only the discharge density sensor (D303, driving D302 solids%) and vacuum pressure sensor (P502, ensuring process stability) were modeled, as these directly support the 61–63% quality threshold monitoring required by the production application.

• Physical Entity Representation

Figure 11 extends the TFE machine model with controller hierarchy and data flows. The discharge solids controller (sosa:MachineAutomation) consumes D303 sensor output (sosa:MachineOutput) to compute D302 solids percentage, which feeds the vacuum pressure controller (sosa:MachineControl). This produces the P501 vacuum setting (sosa:MachineSetting) monitored by the P502 sensor output. Observable properties employ sosa:ObservableProperty semantics with sosa:Observation instances timestamped via xsd:dateTime.

Communication endpoints for D303 and P502 sensors are modeled as cto:Endpoint instances with MQTT/TCP protocols (cto:CommunicationProtocol), including cto:Url, cto:Namespace, cto:SubscribedTopic (D303), and cto:PublishedTopic (P502) properties required for data access. The pressure control valve employs sosa:Actuator semantics. Variable tags (P501, P502, D301, D302) use cto:Tag datatype properties. The zero-tolerance physical dependency between the P501 vacuum setting and P502 sensor data is represented without tolerance annotation.

• AI Representation

The MSL model (MSL_001) is represented as a reusable sosa:Procedure with unique identification (cto:Identification) integrated into the CTM ontology. Model communication employs a dedicated cto:Endpoint with HTTP/REST protocol (cto:CommunicationProtocol), specifying cto:Url and cto:Namespace properties. Model input streams (D302 solids percentage, P502 vacuum pressure) and output predictions are formalized as ssn:input and ssn:output relationships, enabling seamless RESTful integration with the production application.

6.

Digital Threads

As described in Section 4.1, both the physical entity and AI digital threads facilitate communication between virtual and physical twins.

Table 3. Configured protocols and configured AI models of TFE Machine.

Repository	ID	PN or AIN	PC or AIC	PI or AII
Protocol Configuration (protocol_config)	mqtt_004	MQTT	{broker:“tcp://x.x.x.x:1883”, topic:“dischargedensity”, qos:1}	http://x.x.x.x:3000/repo/mqtt.git
	mqtt_005	MQTT	{broker:“tcp://x.x.x.x:1883”, topic:“vacuumpressure”, qos:1}	http://x.x.x.x:3000/repo/mqtt.git
	http_003	HTTP	{base_url:“http://{msl_model_server_ip}:5000/predict/”, method:“POST”}	http://x.x.x.x:3000/repo/http.git
	opcua_002	OPC UA	{url:“opc.tcp://x.x.x.x:5001/”, security_mode:“None”, node_id:“ns=2;i=1001”, subscription_interval:500}	http://x.x.x.x:3000/repo/opcua.git
AI Configuration (ai_config)	model_003	MSL	{output:“goodnessscore“, input:“DischargeSolidsPercentage”}	http://x.x.x.x:3000/repo/msl_001.git

presents the configured protocols and configured AI models resulting in a digital twin of the TFE machine. These configured protocols and configured AI models are stored in the Protocol Configuration Repository and AI Configuration Repository, respectively, following the schema presented in Section 5. Even though the platform is capable of handle multiple-protocol digital threads for both physical entities and AI models, in this study, we use HTTP as the AI protocol without loss of generality, which is widely adopted for REST-based inference services and ensures interoperability.

Next,

Table 4. Physical entity and AI digital threads for digital twin of TFE machine.

Type	Digital Thread ID	DT Concept	Configured Protocol Id	Configured AI Model Id
Physical	dth_004	DischargeDensity	mqtt_004	NULL
Physical	dth_005	VacuumPressure	mqtt_005	NULL
AI	dth_006	GoodnessScore	http_003	model_003

presents how these above-configured protocols and configured AI models are used to create both the physical entity and AI digital threads. All these digital threads are stored in the Digital Threads Repository, as presented in Section 5.

Physical entity digital threads (dth_004, dth_005) enable sensor data ingestion (MQTT), while AI digital threads (dth_006) route predictions from MSL model DT concepts, demonstrating complete protocol-aware binding across the Digital Manufacturing Platform repositories (dm_platform_db).

6.2.2. Development of Product Quality Improvement for Food Manufacturing

The application leverages the digital twin of the TFE machine described in Section 6.2.1 to dynamically optimize production parameters and ensure consistent product quality. Figure 12 illustrates the end-to-end workflow integrating real-time sensor data and AI predictions for quality improvement.

This section presents the Product Quality Improvement Application for maintaining targeted yeast paste consistency (61–63% solids) within a digital manufacturing environment through TFE digital twin orchestration.

The application regulates discharge solids percentage (D302) by dynamically adjusting vacuum pressure setting (P501) using integrated MSL model reasoning. DischargeSolidsAutomation continuously monitors the discharge density sensor (D303) via MQTT endpoint mqtt_004 (“dischargedensity”), calculating real-time D302 values. When D302 falls below 61%, VacuumPressureControl consumes this output to recalibrate P501, transmitting updated setpoints to the pressure control valve (4–20 mA, sosa: Actuator). Feedback from vacuum pressure sensor P502 (mqtt_005: “vacuumpressure”) maintains the PhysicalDependency between setpoint and measurement.

Upon reaching D302 ≥ 61%, the MSL model (http_003/model_003) classifies machine states and computes goodness scores (≥0.85 threshold), quantifying empirical probability of target solids achievement. Low scores trigger corrective VacuumPressureControl adjustments through digital threads. Digital Threads Repository integrates

• Physical Entity: mqtt_004 (D303 → D302), mqtt_005 (P501 ↔ P502)
• AI Digital Thread: http_003/model_003 (MSL inference)

The application visualizes live D302/P502 KPIs, state transitions, and goodness score evolution, demonstrating CTM ontology-driven, dependency-aware quality control that minimizes low-solids batches while optimizing TFE productivity.

7. Conclusions

The proposed digital twin (DT) framework provides a unified foundation for creating and managing complex industrial entities such as machines, products, and people through individualized digital representations. By incorporating supplementary sensing and measurement devices, the framework enables product-specific quality monitoring and data-driven decision-making across all lifecycle stages, thereby improving product quality and operational transparency. The accompanying Digital Manufacturing Platform demonstrates strong generalizability, supporting the development of diverse industrial applications using different digital twins. As an AI model-agnostic environment, the platform allows the seamless integration of various AI models as first-class components within each twin for predictive and translational reasoning during process execution. The inclusion of the CTM ontology enables semantic representation and binding of both physical and AI entities, ensuring that every AI-driven decision remains traceable and interpretable. This semantic integration facilitates AI reasoning rather than reliance on pattern-only analytics, thereby improving operator trust and system transparency. Additionally, the proposed multi-protocol digital thread architecture unifies heterogeneous communication protocols (MQTT, OPC UA, HTTP) into a single semantic layer, extending traditional IoT platforms by enabling closed-loop interaction between physical assets, AI services, and digital manufacturing applications. Despite these advancements, the current platform operates with offline-trained AI models and lacks an embedded simulation module for real-time scenario testing. Future research will focus on coupling simulation engines for online AI training and predictive validation, extending digital threads to incorporate unstructured data sources such as maintenance logs and operator records, and employing Large Language Models (LLMs) to merge human expertise with sensor-based insights. These developments will further enhance the platform’s adaptability, explainability, and relevance to complex industrial contexts, advancing the vision of fully intelligent and transparent digital manufacturing.