---
title: 'ISO 23247: Digital Twin Framework'
url: https://www.emergentmind.com/topics/iso-23247-standard
type: topic
---

# ISO 23247: Digital Twin Framework

Searching arXiv for recent 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 [2508.18662]. 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 [2508.18662][2508.14580].

## 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 [2508.14580]. 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 [2508.14580].

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** [2508.14580]. In a parallel formulation, the same structure appears as **Overview and general principles**, **Reference architecture**, **Digital representation of physical manufacturing elements**, and **Information exchange** [2508.18662]. 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 [2508.14580].

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 [2508.18662][2508.14580]. 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** [2508.18662]. 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** [2508.14580]. 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 [2508.18662]. 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 [2508.14580]. Under ISO 23247’s general principles, physical systems are defined as OMEs that need to be twinned [2508.14580].

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 [2508.18662]. 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** [2508.18662]. 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** [2508.14580].

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 [2508.18662]. 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 [2508.18662]. 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 [2508.14580]. 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 [2508.14580][2508.18662].

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 [2508.14580]. 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 [2508.18662].

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 [2508.14580]. 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** [2508.14580]. 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 [2508.18662].

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 [2508.14580]. 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** [2508.18662]. 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 [2508.14580]. 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 [2508.14580]. 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 [2508.14580]. 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 [2508.14580]. 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 [2508.14580]. 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 [2508.14580]. 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 [2508.14580].

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 [2508.14580]. 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 [2508.14580]. 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 [2508.14580].

## 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** [2508.18662]. 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** [2508.18662]. The software stack includes **NVIDIA Jetpack 5.0**, **ROS2**, **Python 3.8**, **C++**, and **MATLAB/Simulink** [2508.18662].

The DT is built to provide three services: **Data Monitoring**, **Computation Offloading**, and **Remote Management** [2508.18662]. 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 [2508.18662].

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 [2508.18662]. 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** [2508.18662]. 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 [2508.18662]. The **User Interface FE** is split into **3D Visualization** and **Control Panel**, and a cross-system **Data Translation** component implements the **Data Translation FE** [2508.18662].

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** [2508.18662]. 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 [2508.18662].

## 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 [2508.18662]. 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 [2508.14580]. Both studies emphasize the standard’s generality, especially its independence from specific formats and protocols [2508.18662].

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 [2508.18662]. 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 [2508.18662]. 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 [2508.14580].

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 [2508.18662]. 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 [2508.18662]. 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 [2508.18662].

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** [2508.18662]. 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 [2508.18662].

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 [2508.14580][2508.18662]. 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.

Source: https://www.emergentmind.com/topics/iso-23247-standard