ISO 23247: Digital Twin Framework
- ISO 23247 is an international standard that defines digital twin frameworks for manufacturing by standardizing system architecture, digital representations, and information exchange.
- It organizes the digital twin space into four cohesive parts—general principles, reference architecture, digital representation, and information exchange—to address interoperability challenges.
- Recent studies showcase its adaptability in both manufacturing and automotive sectors, while highlighting the need for domain-specific extensions and robust synchronization.
Searching arXiv for papers on ISO 23247 and related digital twin implementations. ISO 23247 is the international standard series for digital twin frameworks in manufacturing. In recent implementation-oriented studies, it is presented as the only digital-twin-specific architectural standard currently available and as a practical starting point for digital twin engineering, even when adaptation beyond manufacturing is required (Ramdhan et al., 26 Aug 2025). Its full title is ISO 23247 -- Digital twin framework for manufacturing, and it was published in 2021. The standard is organized into four parts—Overview and general principles, Reference architecture, Digital representation of physical manufacturing elements, and Information exchange—with the Reference architecture functioning as the main architectural basis in both a manufacturing demonstrator and an automotive adaptation study (Ramdhan et al., 26 Aug 2025, Cao et al., 20 Aug 2025).
1. Scope, purpose, and formal organization
ISO 23247 is described as a standard series intended to provide a standardized way to define, architect, and connect a manufacturing digital twin so that the twin is not merely a simulation, but a structured system with a defined relationship to the physical manufacturing system, standardized digital representations of physical assets, specified information exchange requirements, and a reference architecture that organizes DT functions and interfaces (Cao et al., 20 Aug 2025). In this framing, the standard addresses recurrent DT implementation problems such as lack of interoperability, inconsistent architecture definitions, difficulty synchronizing physical and digital systems, fragmented communication interfaces, and insufficient guidance for practical manufacturing implementations (Cao et al., 20 Aug 2025).
The four-part structure is central to how the standard is understood in recent work. The series is presented as comprising: General Principles, Reference Architecture, Digital Representation, and Information Exchange (Cao et al., 20 Aug 2025). In a parallel formulation, the same structure appears as Overview and general principles, Reference architecture, Digital representation of physical manufacturing elements, and Information exchange (Ramdhan et al., 26 Aug 2025). The practical emphasis in both studies falls on the reference architecture, while digital representation and information exchange are treated as necessary supporting components for synchronization and runtime operation (Cao et al., 20 Aug 2025).
A recurring distinction in the literature is between what ISO 23247 standardizes and what must be supplied through implementation choices. The standard is treated as defining the DT framework and architecture, whereas technologies such as OPC UA, CODESYS, Kepware, ThingWorx, ROS2, UDP, or custom communication mechanisms are implementation decisions layered onto that framework (Ramdhan et al., 26 Aug 2025, Cao et al., 20 Aug 2025). This suggests that ISO 23247 is primarily an architectural and organizational standard rather than a prescriptive technology stack.
2. Reference architecture and core terminology
The architectural vocabulary used in implementations is strongly entity-based. One study extracts the following core entities from ISO 23247: Observable Manufacturing Element (OME), Data Collection and Device Control Entity, Digital Twin Entity, and User Entity (Ramdhan et al., 26 Aug 2025). A manufacturing implementation expresses the same structure as four main domains: OME Domain, Data Collection and Device Control Domain, Core Domain (DT Domain), and User Domain (Cao et al., 20 Aug 2025). In both readings, the standard provides a layered and functionally decomposable architectural schema.
The Observable Manufacturing Element (OME) is defined as any item with an observable physical presence or operation in manufacturing, such as equipment, facilities, products, personnel, or processes (Ramdhan et al., 26 Aug 2025). In manufacturing implementations, OMEs are the physical manufacturing entities whose behavior and state are observed, collected, represented, and mirrored digitally; in a lab-scale drone factory demonstrator, the OME includes the conveyor system, branch assembly stations, buffer space, docking stations, pallets, sensors, RFID-tagged items, and PLC-controlled equipment (Cao et al., 20 Aug 2025). Under ISO 23247’s general principles, physical systems are defined as OMEs that need to be twinned (Cao et al., 20 Aug 2025).
Each entity is composed of Functional Entities (FEs), which are finer-grained functional units. Reported FE roles include actuating the OME, transforming data into a human-interpretable format, and interfacing with the user (Ramdhan et al., 26 Aug 2025). Standard-derived FE terms used in implementations include Data Translation FE, Data Pre-Processing FE, Data Collecting FE, Reporting FE, Presentation FE, Controlling FE, Actuation FE, and User Interface FE (Ramdhan et al., 26 Aug 2025). In a manufacturing instantiation, the core domain additionally includes named FEs such as Digital Modelling FE, Presentation & Representation FE, Simulation FE, Interoperability FE, Remote access FE, Synchronization FE, Connectivity FE, Data Assurance FE, and Security Support FE (Cao et al., 20 Aug 2025).
The standard is also presented as non-prescriptive with respect to FE implementation technology. One paper explicitly notes that ISO 23247 does not prescribe implementation technology for the FEs; for example, OPC UA (IEC 62541) may be used for the Data Translation FE, or a custom communication mechanism may be adopted (Ramdhan et al., 26 Aug 2025). This implementation freedom is one of the principal architectural properties attributed to the standard.
| Component | Role in reported implementations | Representative terms |
|---|---|---|
| Physical side | Twinned asset and associated sensing/actuation functions | OME, Data Collection and Device Control |
| DT side | Digital representation, models, control, data management logic | Digital Twin Entity, Core Domain |
| User side | Human interaction, visualization, monitoring, command initiation | User Entity, User Domain |
| Boundary functions | Cross-system communication and translation | Data Translation FE, interoperability, synchronization |
The architectural interpretation that emerges from these studies is that data moves from the physical system toward the DT via collection and pre-processing, while commands move from users and/or DT control logic back toward the physical system, with translation and communication middleware required at entity boundaries (Ramdhan et al., 26 Aug 2025). This suggests that ISO 23247’s reference architecture is best understood as a decomposition scheme for bidirectional cyber-physical coordination.
3. Digital representation, information exchange, and synchronization
Digital representation in ISO 23247 is described as defining the essential information attributes for typical OMEs, including static information, such as design specifications or CAD information, and dynamic information, such as real-time sensor values and operational states (Cao et al., 20 Aug 2025). In practice, these representations have been realized through simulation models, CAD-imported geometry, I/O tags and bindings, runtime state mirrored from sensors and PLCs, SQL-backed state storage, and VR-rendered views (Cao et al., 20 Aug 2025, Ramdhan et al., 26 Aug 2025).
Information exchange is treated as the mechanism by which the DT remains synchronized with its physical counterpart. In the manufacturing case, ISO 23247 information exchange is instantiated through OPC UA between simulation and Kepware, Kepware as middleware, ThingWorx as IIoT platform, and CODESYS between middleware/platform and PLC-related physical control, with application keys and IP whitelisting used for secure access (Cao et al., 20 Aug 2025). In the automotive case, communication is organized as a ROS2 network within the DTS and Wi-Fi using UDP transport between entities, with a dedicated Data Translation component responsible for serializing data, aligning message types, and performing unit conversions (Ramdhan et al., 26 Aug 2025).
Synchronization is a central operational concern in both implementations. In the manufacturing demonstrator, synchronization means ensuring that missions initiated in VR or the simulation correspond to real actions in the physical factory, that the physical system validates actions, and that the simulation mirrors pallet movement and station behavior (Cao et al., 20 Aug 2025). The authors report that synchronization is demonstrated, though not complete, because only selected sensors and actuators are connected, RFID-based real-time pallet position updates are not yet integrated, and communication latency is around 1 second (Cao et al., 20 Aug 2025). In the automotive case, synchronization-related constraints are formulated more explicitly through requirements on network latency and clock synchronization: network latency of at most 100 ms from the vehicle to the DT Entity, and clock synchronization accuracy of 100 ms across DTS components (Ramdhan et al., 26 Aug 2025).
These two implementations illustrate distinct operational regimes under the same standard. The manufacturing system treats the real system as the master: the simulation model sends a request to start a mission, the request propagates via OPC UA, Kepware, ThingWorx, and CODESYS, the physical system validates mission availability, and the simulation then mirrors the executed behavior (Cao et al., 20 Aug 2025). The automotive system uses DT-mediated offloading and control, where perception-derived object tracks are sent to the DT, the ACC component identifies the lead vehicle and computes following speed, and the resulting desired speed is returned for vehicle actuation via a PID controller (Ramdhan et al., 26 Aug 2025). A plausible implication is that ISO 23247 can accommodate both factory-supervised and control-loop-oriented digital twin deployments, but only at a fairly abstract architectural level.
4. Manufacturing implementations under ISO 23247
A detailed manufacturing implementation based on ISO 23247 is provided by a lab-scale drone factory demonstrator in the Stena Industry Innovation (SII) Laboratory in Gothenburg (Cao et al., 20 Aug 2025). The physical system comprises a conveyor belt transporting drone pallets, six branch assembly stations, an Autonomous Mobile Robot (AMR), a buffer space, docking station I/O arrangements, RFID-tagged pallets, PLCs, and sensors for pallet detection, elevator transfer monitoring, and queue-stop regulation (Cao et al., 20 Aug 2025). This physical setup is treated as the OME domain.
The virtual model is built in Emulate3D, which provides simulation, digital twin platform functions, imported CAD files, modeled components such as conveyors and robots, and VR capability (Cao et al., 20 Aug 2025). The industrial IoT stack includes ThingWorx for data collection, storage, visualization, and application development; Kepware for secure communication, traffic management across firewalls, remote device administration, and OPC UA server functionality; and CODESYS for communication between the Kepware/IoT layer and the physical system or PLC environment (Cao et al., 20 Aug 2025). These choices instantiate the standard’s data collection/device control and core connectivity functions rather than being mandated by ISO 23247 itself.
The most concrete runtime use case is “Pass Docking Station.” A pallet blocked at a docking station can be released by a request initiated from VR controllers, the ThingWorx user interface, or the physical HMI/PLC side (Cao et al., 20 Aug 2025). The request enters the DT communication chain, the physical system validates mission availability, the blocking sensor deactivates, the pallet proceeds, and the simulation model mirrors the movement in real time (Cao et al., 20 Aug 2025). Validation focuses on synchronized behavior between physical and virtual systems, bidirectional communication, successful server connection and data transfer, the ability to trigger missions from multiple interfaces, and visual correspondence across real system, simulation, and VR view (Cao et al., 20 Aug 2025).
The manufacturing study states that this demonstrator is intended to show compliance or alignment with ISO 23247, especially with respect to standardized architecture, digital representations, information exchange, interoperability, and synchronization (Cao et al., 20 Aug 2025). It also reports TRL 7 demonstration in a representative environment for a use case characterized by smart manufacturing, production-phase application, real-time connectivity in DT, and virtual-physical connection with bidirectional transfer (Cao et al., 20 Aug 2025). Beyond the implemented prototype, the same study positions ISO 23247 as a base for future extensions in AI, XR, sustainability KPI integration, and Industry 5.0-oriented operator support, while stressing that these are extensions rather than standardized features of ISO 23247 itself (Cao et al., 20 Aug 2025).
5. Automotive adaptation and nontrivial reinterpretation
A separate case study investigates whether ISO 23247’s manufacturing-oriented reference architecture can be used to engineer an automotive digital twin, specifically an Adaptive Cruise Control (ACC) DT for a 1/10th-scale autonomous vehicle (Ramdhan et al., 26 Aug 2025). The physical platform is retrofitted from a Traxxas teleoperated vehicle and organized into three layers: lower level chassis, upper level chassis, and autonomy elements including NVIDIA Jetson Orin Nano, Hokuyo UST-10LX LiDAR, Intel Deepsense D435i Depth Camera, and Vedder Electronic Speed Controller (Ramdhan et al., 26 Aug 2025). The software stack includes NVIDIA Jetpack 5.0, ROS2, Python 3.8, C++, and MATLAB/Simulink (Ramdhan et al., 26 Aug 2025).
The DT is built to provide three services: Data Monitoring, Computation Offloading, and Remote Management (Ramdhan et al., 26 Aug 2025). Data Monitoring supports real-time viewing of vehicle state, projected driving path, and detected object tracks, along with saving and reporting data. Computation Offloading moves ACC computation off the vehicle to the DT, where the DT determines the lead vehicle, computes desired speed, and sends that speed back for actuation. Remote Management supports remote enable/disable of ACC, remote desired-speed setting, and remote emergency braking (Ramdhan et al., 26 Aug 2025).
The most consequential architectural move in this study is the introduction of a Physical Twin Entity, explicitly described as not being defined in ISO 23247 and only loosely analogous to the OME (Ramdhan et al., 26 Aug 2025). Within this Physical Twin Entity, the authors place Point Cloud Clustering & Tracking—implemented through DBSCAN and a Kalman filter—as a Data Pre-Processing FE, and Actuation as an Actuation FE (Ramdhan et al., 26 Aug 2025). In the Digital Twin Entity, they map Visualization Pre-Processing to Presentation FE, Data Collection to Data Collecting FE, Report Generation to Reporting FE, and ACC to Controlling FE, while noting that Data Storage has no natural FE in ISO 23247 (Ramdhan et al., 26 Aug 2025). The User Interface FE is split into 3D Visualization and Control Panel, and a cross-system Data Translation component implements the Data Translation FE (Ramdhan et al., 26 Aug 2025).
The study frames its evaluation through eight requirements, including standardized internal communication, real-time collection of ego speed, steering angle, and surrounding objects, external data storage, UI monitoring, remote ACC management, compliance with selected ISO 15622 ACC functionality, latency of at most 100 ms, and clock synchronization accuracy of 100 ms (Ramdhan et al., 26 Aug 2025). It classifies the system, using the taxonomy from David et al., as “Fully Autonomous Digital Twin, with the Human-in-the-Loop.” The paper’s bottom-line position is that ISO 23247 is a credible and valuable baseline architecture, but only after substantial reinterpretation and extension for automotive deployment (Ramdhan et al., 26 Aug 2025).
6. Strengths, limitations, and relation to adjacent standards
The principal strength attributed to ISO 23247 is that it provides a useful architectural starting point. It offers guidance for organizing blocks of functionality, structures the system using entities and FEs, supports decomposition into understandable architectural responsibilities, and has a comfortable learning curve; one automotive prototype was developed by two graduate students starting from a course project (Ramdhan et al., 26 Aug 2025). In the manufacturing study, the standard is credited with helping define the scope and objectives of the DT, simulation model requirements, the generic reference architecture, and synchronization or information exchange between physical and digital systems (Cao et al., 20 Aug 2025). Both studies emphasize the standard’s generality, especially its independence from specific formats and protocols (Ramdhan et al., 26 Aug 2025).
The limitations are equally explicit. In the automotive case, the authors argue that the manufacturing bias of the OME concept is a poor fit for vehicles, which are resource-rich cyber-physical systems rather than merely observed manufacturing elements (Ramdhan et al., 26 Aug 2025). They identify insufficient deployment flexibility for FEs, inadequate support for safety-critical applications, no natural architectural placement for Data Storage, overly coarse user-interface abstraction, and insufficient treatment of timing, communication, and distributed control constraints (Ramdhan et al., 26 Aug 2025). The manufacturing study, by contrast, emphasizes partial synchronization, about one second communication delay, incomplete RFID integration, security concerns associated with remote control, and the need for a stronger IoT architecture if the system is scaled up (Cao et al., 20 Aug 2025).
Recent work also situates ISO 23247 relative to adjacent standards. ISO/IEC 30173:2023 (Digital twin — Concepts and terminology) is described as high-level and conceptual and as not defining a reference architecture, which makes ISO 23247 more directly actionable for system architecture (Ramdhan et al., 26 Aug 2025). In automotive engineering, AUTOSAR is identified as “the de facto automotive software architecture standard,” with software components defined hardware-agnostically; the automotive study suggests that ISO 23247 is weaker than AUTOSAR in deployment flexibility and should learn from AUTOSAR’s separation of function and deployment (Ramdhan et al., 26 Aug 2025). The same study treats ISO 15622 as the source of ACC functional expectations and ISO 26262 as the relevant automotive safety standard, concluding that ISO 23247 is useful for architecture but incomplete for domain-specific control and safety requirements (Ramdhan et al., 26 Aug 2025).
A broader pattern emerges from the reported adaptations. ISO 23247 has been used outside its original manufacturing scope in settings including automotive systems, and the paper notes prior adaptations in space debris detection, heterogeneous battery systems in EVs, and AI simulation (Ramdhan et al., 26 Aug 2025). This suggests that the standard functions less as a drop-in domain solution than as a base architecture requiring decomposition, reassignment, or extension of entities and FEs. The most concrete recommendations arising from these studies are to elevate the physical twin to a first-class entity where the physical asset is computationally capable, allow flexible and dynamic deployment of FEs, promote safety to a first-class concern through standards such as ISO 26262, and strengthen support for security, data management, and compatibility with existing domain standards (Ramdhan et al., 26 Aug 2025).
In this sense, ISO 23247 occupies a specific position in the DT standards landscape. It provides architectural scaffolding for defining OMEs, organizing data collection and control, structuring a DT core, and exposing user interfaces, while leaving implementation technologies open and leaving significant domain-specific concerns to adaptation layers (Cao et al., 20 Aug 2025, Ramdhan et al., 26 Aug 2025). Its reported value lies in standardizing the architectural conversation; its reported insufficiency lies in the fact that operational systems still depend on additional standards, middleware, deployment models, and domain-specific engineering constraints.