ISO 23247-1:2021 establishes the general principles of a digital twin framework for manufacturing, and the series now spans at least four published parts plus a composition guidance document (ISO 23247-6) [S1][S3][S9]. The standard partitions a twinning system into four layers, the lowest being the observable manufacturing elements, then a device communication entity, a digital twin entity, and user entities on top [S4].
Part 4 (ISO 23247-4:2021) carries the binding technical content: it specifies the information exchange between entities inside that reference architecture, including the data structures that let a digital twin stay synchronized with its physical counterpart [S3]. A NIST analysis of the series (Shao, Frechette, Srinivasan, 2023) is the most cited independent reading of how those parts fit together [S2].
What the Four Layers Actually Carry
Layer 1 is the physical shop floor: sensors, machines, robots, and parts that already exist and are not part of the standard itself [S4]. Layer 2 is the device communication entity, which aggregates state changes from those observable elements and pushes control programs back down when the twin demands an adjustment [S4].
Layer 3 holds the digital twin entity, the multi-dimensional model that reads the device communication stream and updates geometry, state, and parameters in near real time [S4]. Layer 4 is the user-entity tier, where legacy ERP and PLM sit alongside newer analytics, visualization, and optimization apps that consume the twin [S4]. The framework is explicitly derived from the IoT reference architecture in ISO 30141, customized for discrete and process manufacturing [S4].
Identity, Protocols, and the Data Pipeline
Each trackable manufacturing item gets a unique digital identity covering asset properties, performance metrics, and maintenance records, and that identity is what every layer reads and writes against [S5]. The proven live binding on real lines is OPC UA from the machine controller, captured into an MTConnect data stream by the device communication entity, then consumed by the twin to update drill coordinates, cut material from a wing model, or flag a tonnage excursion on a die casting machine [S4].
Anvil's 2025 overview lists the standardized protocol set that the framework expects: uniform-format data protocols, well-documented integration APIs, and automated validation rules acting as the quality gate before any state change reaches the user entities [S5]. For brownfield plants, this is the practical retrofit path: wrap existing PLCs in OPC UA, stream through MTConnect or a similar adapter, and let the twin layer speak ISO 23247-4 information models upward [S3][S4].
Selection Criteria: When ISO 23247 Fits vs When It Doesn't
ISO 23247 is built for asset-centric manufacturing where a physical item can carry a persistent identity and be observed continuously, which is the case on a CNC cell, a robot assembly line, or a tie-bar strain monitoring loop on a die casting machine. It is not built for purely transactional processes, batch chemistry without unit identity, or any line where the observable element cannot be tagged, in those cases a lighter-weight SCADA/MES stack is the correct tool and the four-layer overhead will not pay back [S4][S6].
Three decision gates separate a real fit from a slide-deck twin: (1) every physical item must have a unique ID and observable state; (2) the plant must already run or be willing to run OPC UA, MTConnect, or an equivalent device-comm layer; (3) there must be at least one user entity, analytics, optimization, or PLM-linked ECN, that can act on the twin's output [S3][S4]. Miss any of the three and the project collapses to a visualization layer with no authoritative state.
Comparison: ISO 23247 vs Ad-Hoc Digital Twin Builds
On a four-criterion matrix, ISO 23247 wins on interoperability and long-term maintainability, while ad-hoc builds win on time-to-first-demo and capex. The framework enforces a shared information model across vendors, which is exactly what an ad-hoc twin built on a single vendor's SDK cannot offer [S2][S3].
Wallner et al. (2023) flagged a concrete limitation: the framework handles product and process life cycle changes well, but resource life cycle changes (a robot swapped out, a cell retooled) are only partially covered, and the implementation has to add that logic itself [S6]. That is the single most common gap seen in 2023-2025 pilot reports.
Real Use Cases and the Numbers Reported
The University of Washington robot cell (Kenny, Stan, Cartman, Kyle) is the canonical demonstration: four ABB robots commanded in Rapid, status surfaced via OPC UA, captured in MTConnect, and mirrored in a digital twin that removes material from a virtual wing skin so NC adjustments can be approved visually [S4]. That same pattern translates directly to a digital thread vs digital twin decision on a 2026 plant floor, where the twin is the live state and the thread is the as-built lineage.
Anvil Labs' 2025 write-up reports up to 75% faster inspections and 30% better defect detection on digital-twin-enabled lines, framed as illustrative benefits rather than a controlled benchmark [S5]. A 2024 MDPI study (Kang et al.) couples the framework to edge computing, pushing the device-comm and partial twin logic to the plant edge to keep round-trip latency low [S8]. A 2025 arXiv implementation (Cao et al.) walks through a real-time production DT built on the same architecture, including the integration glue between OPC UA acquisition, the twin model, and downstream user entities [S7].
Limitations, Failure Modes, and Open Standards Work
Three failure modes show up repeatedly in 2024-2025 implementations. First, the resource life cycle gap already noted: swapping a robot or a CNC head is not a first-class operation in the base standard and has to be engineered per site [S6]. Second, the framework is intentionally transport-agnostic below the device-comm layer, which means OPC UA vs MTConnect vs proprietary bus choices are still a plant-level decision, and the standard does not pick a winner [S4]. Third, identity resolution across multi-vendor cells remains an integration tax, because ISO 23247 tells you what to identify, not which identifier registry to use.
ISO 23247-6 addresses one of these by formalizing digital twin composition, classifying types of composed twins, and giving step-by-step implementation guidance, which is the practical answer to teams that need to stitch a cell-level, line-level, and plant-level twin together [S9]. The published parts as of the 2026-10-08 research window are 23247-1, 23247-2, 23247-3, and 23247-4 (all 2021), with 23247-6 composition guidance added since, per the ISO catalog and the standards aggregator [S1][S3][S9].
Standards, Sourcing, and What to Verify Before You Specify
The binding reference document for a project proposal is ISO 23247-1:2021 for principles and ISO 23247-4:2021 for the information exchange requirements, with ISO 23247-6 used when a composed twin is in scope [S1][S3][S9]. The NIST analysis (Shao et al., 2023) is the most cited independent mapping of the parts to manufacturing use cases and is the right citation for an architecture review [S2].
Before any specification is signed off, three things should be checked against the actual ISO catalog page, not against secondary write-ups: the current edition status of each part, whether 23247-5 has been published in your procurement window, and whether your device-comm layer vendor has a conformance statement against 23247-4 information models [S1][S3]. The composition guidance in 23247-6 is the document to cite when the deliverable is a federated twin, and a practical implementation reference is the 2025 arXiv paper by Cao et al. for a worked production example [S7][S9]. For a plant-side decision matrix on whether a digital thread or a digital twin is the right 2026 investment, the engineering-economics comparison is laid out separately in our Digital Thread vs Digital Twin decision matrix.
Component reference pages worth checking: data logger, digital multimeter, and digital panel meter.