ISO 23247 is the international standard series that defines a digital twin framework for manufacturing. It sets out the principles, a reference architecture, how to describe the physical things being twinned and how information is exchanged. It is deliberately technology-neutral: it does not mandate a protocol or a software platform, but gives buyers and suppliers a common structure for specifying and reviewing a twin.
The first four parts were published in 2021 under ISO technical committee TC 184/SC 4, starting with ISO 23247-1 on overview and general principles. A fifth part on the digital thread followed in 2026. NIST, which contributes to the work, notes that the lack of common standards is a major barrier for small and medium-sized manufacturers trying to build trustworthy twins, which is exactly the gap ISO 23247 addresses.
The parts of ISO 23247 at a glance
| Part | Title (short) | What it gives you |
|---|---|---|
| ISO 23247-1 | Overview and general principles | Terms, scope and requirements for a manufacturing twin |
| ISO 23247-2 | Reference architecture | Functional entities and how they relate |
| ISO 23247-3 | Digital representation of manufacturing elements | Basic information attributes for the things being twinned |
| ISO 23247-4 | Information exchange | Technical requirements for exchanging data between entities |
| ISO 23247-5 (2026) | Digital thread for digital twin | Data flow and traceability across the lifecycle |
Observable manufacturing elements
The central idea is the observable manufacturing element (OME): anything on the shop floor that can be observed and represented. The standard's scope covers personnel, equipment, materials, manufacturing processes, facilities, the environment, products and supporting documents. A twin of a machining cell might include the machine tool, its fixtures, the work-in-progress parts, the NC program and the operator's qualifications.
Thinking in OMEs forces a useful discipline early in a project: list exactly which elements you will twin, what attributes of each you need, and where those attributes come from. Most failed twin projects skipped this step and discovered halfway through that half the data did not exist.
The reference architecture in practical terms
Part 2 describes the twin in layers, commonly summarised as four domains:
- The OME domain: the real machines, people, materials and products.
- Data collection and device control: sensors, PLCs, edge devices and the interfaces that read from and write to the OMEs.
- The core digital twin: the models, synchronisation, simulation, analytics and services.
- The user domain: the applications people use, such as dashboards, 3D viewers, planning tools and ERP or MES links.
For a project manager this maps neatly onto work packages and suppliers. It makes clear, for example, that the PLC integrator owns a different layer from the analytics vendor, and that someone must own the interfaces between them.
Demonstration of Three ISO 23247 Digital Twin Use Cases
STEP Tools, Inc.
This video is hosted on YouTube. Playing it loads content from Google, which may set cookies.
Watch on YouTubeInformation exchange: which protocols?
ISO 23247 does not prescribe formats or protocols. It points implementers to existing standards so they can choose what suits the use case: OPC UA for controller and machine data, MTConnect for machine tools, ISO 10303 (STEP) for product geometry, and IEC 62264 (ISA-95) for the link to business systems. In Germany, the Asset Administration Shell is often used to package asset information in a standard structure.
What implementations look like
Published implementations are growing. An August 2025 paper on arXiv describes a real-time ISO 23247 twin of a lab-scale drone factory that links the physical system, simulation software and a VR interface through an IoT platform, with the aim of better operator assistance. NIST is also proposing further parts on verification, validation and uncertainty quantification, so that users can judge how far to trust a twin's outputs.
How to use ISO 23247 in your own project
- Use Part 1 terminology in your requirements so every supplier means the same thing by 'twin', 'OME' and 'synchronisation'.
- List your OMEs and their attributes using Part 3 as a checklist; mark where each attribute will come from.
- Draw your architecture in the four domains of Part 2 and assign an owner to every box and interface.
- Specify interfaces with existing standards, as Part 4 suggests, rather than custom APIs.
- Plan the digital thread: how design, production and service data link over time, in line with Part 5.
- Define how you will validate the twin against reality before decisions depend on it.
A practical tip: keep the OME list and the architecture drawing as living documents. When a new machine, sensor or software system is added, update them first. Twins decay quietly when the plant changes and the model does not, and these two documents are the cheapest way to notice.
Is compliance worth asking for?
There is no certification scheme for ISO 23247 conformance today, so 'compliant' claims need checking. Asking a supplier to structure their proposal against the four domains and your OME list is more useful than a compliance statement. It quickly reveals who has thought about data sources and who is selling a 3D viewer.
How Wartens builds twins
Our iUNI team builds twins from CAD at 1:1 scale, connected to live sensor data and integrated with SCADA, PLC and ERP, for planning, training, monitoring and virtual commissioning. We structure twins for interoperability on request, and because we are controls engineers we start from the data the PLCs actually hold. See our digital twins service, compare digital twin vs simulation, or discuss your project.
