ISO 23247 digital twin framework: what the four parts ask for, in plain English

The ISO 23247 digital twin framework is a four-part international standard, published in 2021 by ISO/TC 184/SC 4, that gives manufacturers a common structure for building digital twins of what happens on the shop floor. It does not prescribe software, a vendor or a data format. It tells you how to scope a twin, which functional blocks it needs, which standards to use to describe the physical things it mirrors, and how information should flow between them (ISO 23247-1).

For machine builders and plants in Germany the framework is useful for one practical reason: when a customer, a funding body or an internal IT team asks what kind of digital twin you are building, ISO 23247 gives you vocabulary that everyone can check. This article explains each part, shows how it relates to the Asset Administration Shell, and ends with a short procedure you can use on a real project.

The ISO 23247 digital twin framework at a glance

NIST, which studied the framework while it was still a draft, describes its goal as a generic development framework that can be instantiated for case-specific implementations (NIST AMS 400-2). In other words: a template, not a product.

Part 1: what counts as a digital twin

Part 1 defines a digital twin in manufacturing as a fit-for-purpose digital representation of an observable manufacturing element, kept synchronised with it. An observable manufacturing element (OME) is anything with a physical presence or operation on the shop floor: personnel, equipment, material, process, facility, environment, product or supporting document.

The phrase fit for purpose matters most. A twin for predictive maintenance on a CNC spindle and a twin for virtual commissioning of a packaging line are different twins, with different models, data rates and accuracy. NIST lists typical manufacturing twins including real-time control, equipment health, scheduling, predictive maintenance and virtual commissioning twins, and notes that no single twin provides every solution for a system.

Part 2: the reference architecture

Part 2 splits a twin system into domains, each with functional entities. Belgian research centre Sirris summarises it as four layers, from the shop floor upwards (Sirris):

1. Observable manufacturing elements. The machines, materials and people. Officially outside the framework, because they already exist.
2. Data collection and device control. Collects state changes from the elements and can send control actions back to them.
3. Core entity. The twin itself: operation and management, applications and services such as simulation and analytics, and resource access and interchange.
4. User entity. People, MES, ERP, PLM or other twins that use the results.

A cross-system entity runs across all of them for data translation, data assurance and security. For a controls engineer the mapping is familiar: the PLC, drives and sensors sit in the data collection and device control domain; the simulation model sits in the core entity; the HMI, MES and maintenance system are users.

Part 3: describing the elements with existing standards

Part 3 identifies the elements that must be represented and gives examples of static and dynamic attributes. Crucially, it does not invent a new data model. No single standard covers every element type, so the framework points to existing ones and says an implementation shall select the most appropriate for its use case. The list includes ISO 10303 (STEP), IEC 62264 (ISA-95), IEC 62714 (AutomationML), ISO 13399, ECLASS, the Asset Administration Shell, OPC UA (IEC 62541), MTConnect, QIF (ISO 23952) and RDF.

Part 4: keeping the twin in sync

Part 4 names four networks: a user network between users and the core entity, a service network inside the core entity, an access network linking data collection to the core and user entities, and a proximity network between data collection and the shop floor elements. On a typical German machine the proximity network is PROFINET or EtherCAT, and the access network is OPC UA or MQTT on the plant Ethernet. Part 4 also describes example use cases and lists candidate technologies for each link.

Using ISO 23247 on a real project

Based on the NIST procedure, a practical sequence for a machine builder or plant looks like this:

1. State the purpose in one sentence. For example: test the PLC program of line 3 against a model before the retrofit shutdown.
2. List the observable manufacturing elements in scope and choose a representation for each: AAS submodels for assets, AutomationML or CAD for geometry, OPC UA for live data.
3. Define data collection and device control. Which signals, at what rate, and whether the twin may ever write back to the machine. For commissioning twins the answer is usually no.
4. Choose the core functions. Simulation, analytics, visualisation, or a combination.
5. Name the users and their interfaces. The commissioning engineer, the maintenance planner, the MES.
6. Write down security and data assurance for the links between domains, especially where plant data leaves the OT network.

That page of answers is a specification any supplier can quote against, and it stops a twin project from turning into an open-ended visualisation exercise. It also maps neatly to virtual commissioning, the most common first twin for machine builders.

Where Wartens fits

Wartens builds machine and line twins from CAD data at 1:1 scale and drives them with your real or simulated PLC program, so the twin runs the same control logic the plant will run. Twins can be structured for interoperability on request. See our digital twin and virtual commissioning service and the Germany market overview.

Next step: send us your use case in one sentence and a list of the machines in scope, and we will map it to the ISO 23247 entities and propose a first build. Contact us.