ISO 23247 Digital Twin Framework for Manufacturing

1. What Is ISO 23247 Digital Twin Framework for Manufacturing?

The ISO 23247 Digital Twin Framework for Manufacturing is a standards-based architecture for connecting manufacturing assets and processes with their digital representations. It organizes the information, functions, and interfaces needed to keep a digital twin synchronized with the manufacturing element it represents. It is an operational and technology framework, not a software product or investment-prioritization matrix.

For manufacturers of industrial machinery, the practical question is specific: how should machine data, production orders, engineering definitions, and operational models work together to support decisions about scheduling, equipment availability, or process performance? ISO 23247 provides a structure for designing that connection rather than building another isolated dashboard.

2. Origin and Background

The framework was developed through the International Organization for Standardization, specifically Technical Committee 184, Automation systems and integration, Subcommittee 4, Industrial data. Its foundational Parts 1–4 were published in October 2021. ISO is the organization’s short name, not a letter-by-letter acronym; 23247 identifies the standards series.

The framework addresses inconsistent terminology and fragmented approaches to implementing manufacturing digital twins. The US National Institute of Standards and Technology contributed explanatory research and implementation scenarios, including machine health, scheduling and routing, and virtual commissioning. These helped translate the architecture into manufacturing applications.

The series subsequently expanded: Part 5, covering digital threads, was published in June 2026, and Part 6, covering digital twin composition, in July 2026. These extensions address lifecycle information and the combination of multiple twins.

3. How ISO 23247 Digital Twin Framework for Manufacturing Works

The starting point is an observable manufacturing element, or OME: something with an observable manufacturing presence or operation. Examples include equipment, material, processes, products, facilities, personnel, and supporting documentation. Its twin should be fit for its intended purpose, rather than an exhaustive replica of everything associated with it.

The standards series

The six published parts address complementary design questions. They are not sequential maturity levels.

• Part 1: Overview and general principles. Establishes terminology and framework requirements.
• Part 2: Reference architecture. Defines domains, entities, and functional responsibilities.
• Part 3: Digital representation of manufacturing elements. Defines basic information attributes for OMEs.
• Part 4: Information exchange. Specifies exchange requirements across proximity, access, service, and user networks.
• Part 5: Digital thread for digital twin. Connects manufacturing lifecycle information to twins.
• Part 6: Digital twin composition. Addresses connecting and combining multiple twins.

The reference architecture

Four domains distinguish the manufacturing context from the digital functions serving it. The following table translates their responsibilities into a machining-cell application. The observable manufacturing domain provides the physical context; it sits outside the digital twin framework boundary.

A cross-system entity provides shared functions such as data translation, data assurance, and security support. It is not a fifth physical domain. Synchronization can be event-based or time-based, with fidelity and update frequency determined by the application.

For suppliers of industrial automation, this separation is a useful contracting discipline: specify who provides device connectivity, who maintains the model, and who authorizes operational changes.

4. When to Use ISO 23247 Digital Twin Framework for Manufacturing

Use the framework when an operational decision depends on a maintained connection between manufacturing reality and a digital representation. NIST’s implementation scenarios demonstrate its relevance to machine health, production scheduling and routing, and virtual commissioning.

It is especially useful when several equipment vendors, software systems, or plants must contribute to the same solution. Relevant executive questions include:

• Can production be rerouted when a critical machine becomes unavailable?
• Which equipment-condition changes warrant maintenance intervention?
• How should a new cell’s control logic be tested before physical commissioning?
• Which interfaces and model components should be reusable across sites?

Start with asset identifiers, engineering configurations, operating-state histories, production orders, and the data required by the chosen decision. Involve manufacturing engineering, operations, maintenance, quality, plant controls, and information technology. Agree on acceptable data latency and model error before selecting technology.

It is a poor fit when a static layout study or ordinary process analysis answers the question adequately. It can also mislead when important operating states are unobserved or data quality is inadequate. Implementation effort depends on legacy-system access, integration complexity, and validation—not simply the time required to draw an architecture diagram.

5. How to Apply ISO 23247 Digital Twin Framework for Manufacturing: Step-by-Step

The following implementation sequence is a practical management adaptation, not an additional set of ISO requirements.

1. Clarify the operational decision.

   Define what will change: maintenance timing, routing, dispatching, or commissioning approval. Bound the plant, product family, equipment, and planning horizon. Establish a measurable baseline and name the executive accountable for the result.

2. Define the manufacturing elements.

   Identify the machines, processes, products, and supporting information required. Assign consistent identifiers and map relationships: which fixture supports which operation, which machine executes it, and which product revision applies.

3. Audit the required inputs.

   Separate static configuration from dynamic operating data. Check timestamps, units, missing observations, controller-state definitions, inspection records, and production-order references. Identify where manual entries require verification.

4. Construct the architecture and interface map.

   Map functions to device communication, twin, user, and cross-system entities. Document data ownership, exchange frequency, access rights, and failure behavior. A focused data integration strategy should resolve how controller events, production orders, and quality records connect.

5. Build and validate a bounded pilot.

   Begin with one decision and a manageable equipment scope. Compare outputs with observed performance under representative conditions. Verify implementation correctness, validate fitness for purpose, and quantify uncertainty before relying on recommendations.

6. Translate outputs into operating actions.

   Specify who reviews recommendations and how approved decisions return to production. Connect the twin to dispatching routines, maintenance work orders, or engineering approvals. Measure throughput, scrap, overtime, or commissioning rework—not dashboard usage alone.

7. Test alternative conditions.

   Challenge results with different product mixes, machine outages, tooling changes, missing sensor data, and demand scenarios. Identify when the model should warn users, suspend recommendations, or revert to established operating procedures.

8. Align stakeholders and scale selectively.

   Review the pilot with operators, engineers, planners, and system owners. Resolve disagreements about data and decision authority. Reuse architecture patterns across plants, but revalidate assumptions wherever equipment configurations or operating conditions differ.

6. Example: ISO 23247 Digital Twin Framework for Manufacturing in Action

Fictional example: Northbridge Motion manufactures industrial gearboxes. Its machining department misses assembly commitments despite apparently sufficient installed capacity. Management must decide whether to buy another machining center or improve routing and dispatching.

The team selects ISO 23247 to structure a synchronized representation of three machining centers, their operations, fixtures, and gearbox-housing orders. Controller events supply machine status; production records supply order priorities; engineering records identify approved routings and fixture requirements. The twin evaluates alternative schedules, while planners remain responsible for releasing changes.

The team explicitly assumes that routing alternatives are qualified and that observed cycle times remain valid within defined tooling and product configurations. It tests those assumptions against actual production and flags records with uncertain timestamps.

The analysis reveals that fixture availability and repeated changeovers—not aggregate machine hours—create the principal constraint. Management defers the machine purchase, introduces fixture reservations, and changes dispatching rules. It then compares actual queue times and assembly readiness with the baseline before approving expansion.

For the subsequent rollout, program management support coordinates controller access, planned shutdowns, vendor deliverables, operator training, and acceptance reviews. The architecture becomes an implementation plan rather than a presentation.

7. Strengths and Limitations

Strengths

The framework’s principal strength is architectural clarity: it supports context-specific implementations and the reuse of digital twin components.

• Clear responsibilities: Teams can separate connectivity, modeling, applications, and user interaction.
• Explicit interfaces: Equipment suppliers and software providers can discuss integration requirements using a shared structure.
• Purpose-driven scope: A maintenance twin need not contain every detail required by a commissioning twin.

Limitations

The framework does not eliminate interoperability problems or prove that a model is trustworthy. Legacy integration, data quality, scalability, and validation remain substantial implementation challenges. It also does not prescribe a universal data format or communication protocol.

• Architecture is not economics: Build a separate business case covering integration, model maintenance, and operating benefits.
• Models have boundaries: Do not extrapolate beyond validated materials, tooling, configurations, or process conditions.
• Control requires safeguards: Treat operational technology’s safety, reliability, and security requirements separately from analytical usefulness.

8. Common Pitfalls and How to Avoid Them

• Starting with visualization. A compelling factory image can distract from the decision. Define the operational question before specifying presentation features.
• Confusing machines with capacity. Include qualified routings, fixtures, changeovers, and operator constraints where relevant; machine availability alone is not the decision model.
• Ignoring identity and context. Require consistent asset, order, operation, and revision references before combining data streams.
• Equating connectivity with interoperability. Test whether exchanged information has consistent meaning, not merely whether messages arrive.
• Giving recommendations uncontrolled authority. Establish approval rules, permissible actions, and fallback procedures before enabling write-back.
• Stopping at the pilot. Assign owners for interface maintenance, model updates, validation, and benefits tracking before expansion.

9. How ISO 23247 Digital Twin Framework for Manufacturing Relates to Other Frameworks

Value stream mapping: identify the problem first

Value stream mapping examines material and information flows through current- and future-state maps. Use it before ISO 23247 to identify the operational problem worth solving. Prefer it alone when removing straightforward process waste does not require a synchronized model.

ISA-95: define enterprise and production interfaces

ISA-95 structures enterprise-control integration and manufacturing operations information. Use it alongside ISO 23247 to clarify production-order, resource, and execution information exchanged with existing systems. ISA-95 emphasizes enterprise-production integration; ISO 23247 emphasizes the twin architecture and its manufacturing representation.

Verification, validation, and uncertainty quantification: establish credibility

This discipline tests implementation correctness, suitability for intended use, and uncertainty in results. Apply it throughout development and operation, not only at final acceptance. In a plant, the practical question is whether the twin provides sufficiently trustworthy evidence for the specific decision—not whether its architecture looks complete.

10. Key Takeaways

• ISO 23247 structures manufacturing digital twins; it is not a software package.
• Start with an operational decision and define the elements required to support it.
• Specify responsibilities, information meaning, synchronization, and decision authority explicitly.
• Validate the model before using its outputs to change production.
• Evaluate economic value separately, and fund ongoing maintenance—not just initial deployment.

11. FAQs About ISO 23247 Digital Twin Framework for Manufacturing

Does ISO 23247 require a complete digital replica of the factory?

No. The representation should be fit for purpose. Begin with the equipment, processes, products, and information needed for the selected decision; expand only when additional scope adds useful capability.

Must a manufacturing digital twin update continuously?

Synchronization can be event-based or time-based. Specify update frequency according to the decision: a routing change and a fast equipment-control action have different information needs. Faster updates are not automatically more useful.

How does a digital thread differ from a digital twin?

A digital thread connects lifecycle information, such as design, planning, production, and testing records. A digital twin uses relevant information to maintain its manufacturing representation. Part 5 explains how the thread supports creating and maintaining twins.

Can smaller equipment manufacturers use the framework?

Yes. Keep the scope narrow: one recurring decision, a limited equipment set, and a documented interface map. Avoid enterprise-wide modeling initially. Establish reliable inputs and a maintainable operating routine before investing in broader functionality.