ISO 23247 Digital Twin Architecture
- ISO 23247 is a digital twin reference architecture that standardizes entity-based and function-based decompositions for manufacturing and related fields.
- It decomposes systems into Device Communication, Digital Twin, and User entities, with functional entities handling tasks like data collection, control, simulation, and reporting.
- The standard promotes interoperability and adaptability, serving as a baseline for AI simulation and implementations in domains such as automotive and XR-integrated production systems.
Searching arXiv for papers on ISO 23247 reference architecture and digital twins. ISO 23247 Reference Architecture is the reference architecture defined in the ISO standard “Digital twin framework for manufacturing.” It provides an entity-based and function-based decomposition for engineering digital twins, specifying both the architectural entities that bound system scope and the Functional Entities (FEs) that perform elementary tasks such as data collection, synchronization, simulation, reporting, access control, and actuation. In the recent literature, the architecture is treated both as a standardized conceptual baseline for digital twin-enabled AI simulation and as an implementable systems blueprint in domains extending beyond manufacturing, including automotive and XR-integrated production systems (Liu et al., 6 Jun 2025, Ramdhan et al., 26 Aug 2025, Cao et al., 20 Aug 2025).
1. Standard scope and architectural purpose
ISO 23247 is described as a standard for manufacturing digital twins whose goal is to provide a set of architectural entities and a set of functional entities that perform elementary groups of tasks (Liu et al., 6 Jun 2025). In the surveyed treatment of AI simulation by digital twins, the architecture is organized roughly into Device Communication Entities, Digital Twin Entities, and Observable Manufacturing Elements, with the analysis focusing primarily on the Device Communication and Digital Twin groups (Liu et al., 6 Jun 2025). In a separate implementation-oriented account, the standard is presented as an entity-based, layered reference architecture in which four primary entities constitute the core: Observable Manufacturing Element, Data Collection and Device Control Entity, Digital Twin Entity, and User Entity (Ramdhan et al., 26 Aug 2025).
A complementary implementation paper presents ISO 23247 as a vendor-neutral, standardized framework intended to guarantee interoperability, real-time synchronization, and a clear separation of responsibilities across physical assets, digital models, communication middleware, data management, and user-facing services (Cao et al., 20 Aug 2025). That account also decomposes the standard into four main components: General Principles, Reference Architecture, Digital Representation, and Information Exchange (Cao et al., 20 Aug 2025). Taken together, these descriptions indicate that the reference architecture is not merely a static component taxonomy; it also establishes a disciplined partition of operational concerns, data exchange responsibilities, and interface roles.
A plausible implication is that ISO 23247 functions as a coordination layer between heterogeneous digital twin concerns rather than as a prescriptive implementation stack. This suggestion is consistent with repeated descriptions of the architecture as protocol-agnostic, technology-neutral, and suitable as a starting point even in domains for which it was not originally designed (Ramdhan et al., 26 Aug 2025).
2. Entity groups, domains, and Functional Entities
Across the cited studies, the architecture is described through closely related decompositions. One view emphasizes Device Communication Entities and Digital Twin Entities, with Observable Manufacturing Elements as the physical systems being twinned (Liu et al., 6 Jun 2025). Another presents four domains: OME Domain, Data Collection & Device Control Domain, Core (DT) Domain, and User Domain (Cao et al., 20 Aug 2025). A further case study uses four primary entities—OME, Data Collection and Device Control, Digital Twin, and User—and additionally identifies a Cross-System Entity that can host functions such as data translation (Ramdhan et al., 26 Aug 2025).
The functional decomposition is more granular. Within the Device Communication side, the Data Collection sub-entity includes Data Collecting FE, Data Pre-processing FE, and Collection Identification FE, while the Device Control sub-entity includes Control Identification FE, Controlling FE, and Actuation FE (Liu et al., 6 Jun 2025). Within the Digital Twin side, the Operation and Management layer includes Synchronization FE, Presentation FE, Digital Representation FE, and Maintenance FE; the Application and Service layer includes Simulation FE, Analytic Service FE, Reporting FE, and Application Support FE; and the Resource Access and Interchange layer includes Interoperability Support FE, Access Control FE, Plug-and-Play Support FE, and Peer Interface FE (Liu et al., 6 Jun 2025).
The domain-based implementation literature adds concrete instantiations and adjacent functions. In the XR-integrated production-system implementation, the OME Domain contains CAD Files FE, Sensors FE, and PLCs FE; the Data Collection & Device Control Domain contains Real-time Monitoring FE, Data Analysis FE, Control Logic of PLCs FE, OPC UA Communication FE, Connectivity FE, Data Translation FE, and Security Support FE; the Core Domain contains Kepware Server FE, PTC ThingWorx FE, Synchronization FE, Interoperability FE, Remote Access FE, Emulate3D Software FE, Simulation FE, VR Technology FE, Presentation & Representation FE, and Digital Modeling FE; and the User Domain contains User Interface FE instances such as desktop UI, HMI screens, VR controllers, and web mashups (Cao et al., 20 Aug 2025).
The following table consolidates the FE groupings that recur in the cited descriptions.
| Architectural area | Functional Entities explicitly identified | Role |
|---|---|---|
| Data collection | Data Collecting FE, Data Pre-processing FE, Collection Identification FE | Sensing, filtering, selection |
| Device control | Control Identification FE, Controlling FE, Actuation FE | Command selection, protocol translation, physical actuation |
| Operation and management | Synchronization FE, Presentation FE, Digital Representation FE, Maintenance FE | State alignment, visualization, model hosting, model evolution |
| Application and service | Simulation FE, Analytic Service FE, Reporting FE, Application Support FE | Prediction, analytics, reporting, orchestration |
| Resource access and interchange | Interoperability Support FE, Access Control FE, Plug-and-Play Support FE, Peer Interface FE | Bridging, authorization, discovery, federation |
This FE-oriented organization is one of the architecture’s defining characteristics. The automotive case study explicitly characterizes an Entity as a logical grouping of related FEs, and an FE as a smaller unit responsible for a particular task such as actuating the OME, transforming data into a human-interpretable format, or interfacing with the user (Ramdhan et al., 26 Aug 2025).
3. Interfaces, data flows, and control semantics
The reference architecture is operationalized through data flows, control interfaces, and service interfaces. In the AI-simulation mapping, a “Query” is issued by the AI agent to the Simulation FE, which executes the model and returns a “Simulation trace” as output (Liu et al., 6 Jun 2025). Real-world observations arrive via the Data Collecting FE and Data Pre-processing FE, while the Collection Identification FE may trigger active observation by experimenting with the real plant; the Maintenance FE then updates the model stored in the Digital Representation FE (Liu et al., 6 Jun 2025). For batch-training scenarios, the Simulation FE may pass traces to the Analytic Service FE for operations such as smoothing or labeling before onward delivery to AI components or dashboards via the Presentation FE (Liu et al., 6 Jun 2025).
Control paths are similarly layered. When an AI agent or the twin injects control commands into the plant, the sequence passes through Control Identification FE, Controlling FE, and Actuation FE, ending in physical actuation (Liu et al., 6 Jun 2025). Access Control FE governs direct AI-to-physical interactions as well as AI-to-twin calls (Liu et al., 6 Jun 2025). This establishes an important architectural principle: control is not modeled as a monolithic operation, but as a staged pathway involving selection, translation, and actuation.
Implementation case studies supply concrete communication realizations. In the automotive ACC digital twin, interfaces among entities are realized as ROS 2 topic/service definitions or UDP/JSON packets, with the Data Translation FE ensuring type and unit conversions (Ramdhan et al., 26 Aug 2025). The communication infrastructure is described as a required layer providing real-time, reliable, bi-directional connectivity among OME, Data Collection, Digital Twin, and User entities; in that case, the realized connectivity combined ROS 2 intra-entity publish/subscribe with Wi-Fi/UDP links, with end-to-end latency below 100 ms under requirement R7 and NTP-based clock synchronization within 100 ms under requirement R8 (Ramdhan et al., 26 Aug 2025).
The production-system implementation elaborates a protocol stack: Emulate3D communicates with Kepware via OPC UA; Kepware communicates with ThingWorx through HTTPS (REST) or MQTT; ThingWorx communicates with CODESYS via RemoteLink or OPC UA client; and CODESYS communicates with PLCs over industrial Ethernet or fieldbus (Cao et al., 20 Aug 2025). In that system, the observed round-trip latency for simulation request to real PLC response to simulation update was approximately 1 s, while the standard is reported as recommending dwell times below 500 ms for tight control loops (Cao et al., 20 Aug 2025).
These examples suggest that ISO 23247 defines interface responsibilities more strongly than it constrains concrete middleware choices. The literature repeatedly maps abstract FE boundaries onto domain-specific protocol stacks without altering the core FE decomposition (Ramdhan et al., 26 Aug 2025, Cao et al., 20 Aug 2025).
4. Mapping to AI simulation and model lifecycle management
A central recent development is the explicit mapping of AI-simulation concepts onto ISO 23247. In the digital twin-enabled AI simulation survey, the authors derive a reference framework termed DT4AI and then map its concepts to ISO 23247 Functional Entities (Liu et al., 6 Jun 2025). The mapping identifies direct correspondences and multi-FE correspondences.
The mapping is explicit as follows:
| DT4AI concept | ISO 23247 FE mapping | Mapping type |
|---|---|---|
| Simulator | Simulation FE | Strong |
| A: Query | Simulation FE input | Strong |
| B: Simulation data | Simulation FE output | Strong |
| M (model) | Digital Representation FE | Strong |
| C: Observe | Synchronization FE + Collection Identification FE | Partial |
| D: Real data | Data Collecting FE + Data Pre-processing FE | Partial |
| E: Update (model evolution) | Maintenance FE input | Strong |
| F: Control | Control Identification FE + Controlling FE + Actuation FE | Partial |
| Access Control | Access Control FE | Strong |
The distinction between “strong” and “partial” mapping is analytically important. A strong mapping denotes a direct one-to-one functional correspondence, whereas a partial mapping indicates that several FEs or layers participate in a single DT4AI interaction (Liu et al., 6 Jun 2025). This clarifies how AI-centric abstractions such as observation, control, and model evolution distribute across the standard’s more granular FE structure.
The same study also notes that it does not supply explicit formal-math definitions for simulation traces, data schemas, or interface signatures; instead, it relies on informal notions such as “Query,” “Simulated data,” and model “M” (Liu et al., 6 Jun 2025). This absence of a formal data-type calculus or process algebra is significant for advanced readers because it marks a boundary between architectural standardization and formal semantic specification. A plausible implication is that interoperability at the FE level does not automatically guarantee machine-checkable interoperability of model interfaces, simulation traces, or learning data schemas.
Model lifecycle management is represented primarily through the relation between Digital Representation FE and Maintenance FE. Real observations enter through collection and preprocessing, active observation may be triggered, and Maintenance FE updates the representation held in the model repository (Liu et al., 6 Jun 2025). In this reading, the architecture accommodates continuous calibration and model evolution, but it does so through informal lifecycle semantics rather than through a dedicated formal version calculus.
5. Implementations and domain transfer beyond manufacturing
Although ISO 23247 originates in manufacturing, recent work treats it as a transferable architectural baseline. The automotive ACC case study explicitly states that, although not developed for automotive systems, the standard is one of the few feasible starting points for automotive digital twins (Ramdhan et al., 26 Aug 2025). In that implementation, the 1/10th-scale autonomous vehicle served as the OME, point-cloud clustering and tracking were mapped to Data Pre-Processing FE, low-level actuation to Actuation FE, visualization preprocessing to Presentation FE, report generation to Reporting FE, data collection to Data Collecting FE, and adaptive cruise control logic to Controlling FE (Ramdhan et al., 26 Aug 2025). The study further reports that lead-vehicle selection and headway calculation per ISO 15622 Sections 6.1–6.2 were implemented in the Digital Twin Entity as Controlling FE, whereas low-level motor commands remained on the OME in its Actuation FE (Ramdhan et al., 26 Aug 2025).
The same paper identifies service-level mappings in which data monitoring involves components feeding real-time state and 3D pose to the UI, computation offloading places ACC logic in the Digital Twin Entity FE, and remote management combines Control Panel and Actuation FE (Ramdhan et al., 26 Aug 2025). These mappings illustrate how ISO 23247 can separate high-level control intelligence from low-level execution while preserving a standard FE vocabulary.
In XR-integrated human-centric manufacturing, the standard is instantiated in a lab-scale drone factory with conveyors, stations, robots, pallets, RFID tags, sensors, Allen-Bradley and Siemens PLCs, Emulate3D simulation, ThingWorx for IoT modeling and dashboards, Kepware as OPC UA server, and HTC Vive for VR interaction (Cao et al., 20 Aug 2025). A representative use case, “Pass Docking Station,” traverses multiple domains and interfaces: a user triggers the action through VR, ThingWorx UI, or HMI; the command becomes an OPC UA write, passes through Kepware, ThingWorx, and CODESYS, sets a PLC coil, and then physical sensing propagates the resulting state change back to Emulate3D (Cao et al., 20 Aug 2025).
This domain transfer reveals both the adaptability and the abstraction level of the reference architecture. The same FE vocabulary accommodates AI simulation workflows, automotive ADAS-oriented control, and XR-mediated factory operation, but the implementation mechanisms differ substantially. This suggests that ISO 23247 standardizes architectural roles more effectively than vertical-domain execution patterns.
6. Strengths, limitations, and misconceptions
The recent literature consistently identifies the architecture’s strengths in clarity and neutrality. The automotive case study states that the reference architecture provides a clear, tutorial-friendly decomposition of digital twin functionality into entities and FEs, and that its protocol-agnostic, technology-neutral stance makes it easy to map middleware such as ROS 2 and TCP/UDP onto abstract interfaces (Ramdhan et al., 26 Aug 2025). The same study also reports that there was no steep learning curve, noting that two graduate students ported it to a course project in weeks (Ramdhan et al., 26 Aug 2025). In the production-system implementation, the architecture is similarly associated with interoperability, real-time synchronization, and clear separation of responsibilities (Cao et al., 20 Aug 2025).
At the same time, the cited work documents recurrent limitations. One survey-driven analysis identifies the absence of a dedicated FE for large-scale data storage or “data lake” services; the lack of an explicit FE for AI/ML analytics beyond generic Analytic Service; the absence of an ontological or semantic-model FE; the lack of built-in support for Verification, Validation and Uncertainty Quantification (VVUQ); minimal guidance on digital-twin composition and lifecycle versioning of AI-enhanced twins; and only basic security FEs centered on access control, without dedicated FE support for audit logging, non-repudiation, or blockchain-style data traceability (Liu et al., 6 Jun 2025). The automotive study independently reports the absence of a Data Storage FE, lack of guidance on safety-critical assurance, and the lack of a first-class “Physical Twin Entity,” which becomes salient when real vehicles host significant sensing and computation locally (Ramdhan et al., 26 Aug 2025).
A common misconception is that ISO 23247 is a complete implementation prescription. The evidence does not support that reading. The architecture defines entities and FEs, but concrete implementations repeatedly introduce additional components or reinterpret FE placement to satisfy domain requirements. Examples include Data Translation FE in a Cross-System Entity, Security Support FE and Connectivity FE in the production-system implementation, and explicit off-vehicle/on-vehicle partitioning concerns in automotive systems (Ramdhan et al., 26 Aug 2025, Cao et al., 20 Aug 2025). Another misconception is that the architecture already contains all capabilities required for AI-centered digital twins. The AI-simulation literature explicitly rejects that assumption by pointing to missing support for AI/ML-specific services, VVUQ, semantic modeling, and data-intensive training infrastructure (Liu et al., 6 Jun 2025).
7. Proposed extensions and likely evolution
Several papers propose extensions that would make ISO 23247 more prescriptive for emerging digital twin use cases. In AI-centered settings, suggested gaps include large-scale data storage, explicit AI/ML analytics support, semantic or ontological modeling, VVUQ, richer support for digital-twin composition, lifecycle versioning for AI-enhanced twins, and more extensive security and traceability mechanisms (Liu et al., 6 Jun 2025). These proposals reflect a shift from conventional operational digital twins toward twin-based AI training and sim-to-real pipelines.
The automotive case study recommends elevating the Physical Twin to a named entity so that FEs can be deployed dynamically across on-vehicle and off-vehicle hosts, in a manner compared with AUTOSAR’s hardware-agnostic software components (Ramdhan et al., 26 Aug 2025). It also recommends defining a “Safety Assurance FE” or entity aligned with ISO 26262, enriching the Cross-System Entity with security FEs such as authentication and end-to-end encryption together with data-governance FEs such as access control and provenance tracking, and introducing a Storage FE for long-term archival, indexing, and query interfaces (Ramdhan et al., 26 Aug 2025).
The production-system implementation points toward further integration of AI and sustainability metrics. It explicitly treats IBM Watson IoT for anomaly detection and data fusion, TensorFlow for data pre-processing, machine learning for classification of downtime causes, deep learning for predictive maintenance, and reinforcement learning for autonomous dispatch strategies in simulation as planned or future modules (Cao et al., 20 Aug 2025). It also proposes environmental performance indicators based on material flow, energy consumption, and waste generation, with future work embedding Life-Cycle Assessment and COe models in the Core DT domain (Cao et al., 20 Aug 2025). These are framed as next stages rather than as standardized ISO 23247 capabilities.
A plausible implication is that the long-term evolution of the reference architecture will be driven by three converging pressures: AI-native workflows, safety- and assurance-critical cyber-physical systems, and human-centric interfaces such as XR. The current literature positions ISO 23247 as an effective reference baseline, but not yet as a complete architectural closure for those demands (Liu et al., 6 Jun 2025, Ramdhan et al., 26 Aug 2025, Cao et al., 20 Aug 2025).