Digital Twin Architecture: A 2026 Guide for Industrial Systems

Most projects that call themselves a digital twin are a 3D viewer bolted to a dashboard. They look impressive in a demo and stop being useful the day the plant changes. The reason is architectural, not cosmetic: a real twin is a continuously reconciled model of an asset, with a defined synchronisation contract, a defined fidelity, and a defined path back to the physical world. Without those three, you have a picture of a machine, not a twin of it.

This matters in 2026 because the standards have finally caught up with the marketing. ISO 23247 gives manufacturing a reference architecture, DTDL and the Asset Administration Shell give you competing model vocabularies, and FMI gives you a portable way to ship physics. What has not caught up is the engineering discipline to combine them without building an expensive monument.

You will leave with a precise definition, a six-layer reference stack, a worked synchronisation budget, an honest look at platform limits and failure modes, and a staged way to scale from one machine to a plant.

What this covers: definition and taxonomy, the reference architecture, ISO 23247 and model languages, synchronisation and co-simulation, trade-offs and failure modes, and a practical rollout checklist.

Context and Background

The idea is older than the buzzword. Michael Grieves presented the concept of a virtual counterpart to a physical product at the University of Michigan around 2002, and the term “digital twin” came into circulation after NASA’s roadmap work on spacecraft simulation a decade later. Grieves and Vickers’ 2017 chapter, Digital Twin: Mitigating Unpredictable, Undesirable Emergent Behavior in Complex Systems, remains the most-cited framing: a physical product, a virtual product, and the data flow that connects them across the lifecycle. Everything since is an elaboration of those three parts.

The academic literature then fragmented the definition. A useful cleaning-up comes from Kritzinger and colleagues, whose integration levels distinguish a digital model (no automatic data flow), a digital shadow (data flows automatically from physical to digital only) and a digital twin (automatic flow in both directions). A 2024 formalisation by Barbie and Hasselbring on arXiv adds a digital twin prototype, where sensors and actuators are emulated so embedded software can be tested before hardware exists. That vocabulary is more useful than any vendor slide, because it tells you what a given system can actually do.

Industry practice sits on top of this. Operational technology (OT) data arrives through OPC UA, MQTT or legacy fieldbus gateways; it is moved by a broker or stream platform; it lands in a twin store plus a time-series store; and models consume it. The vendor landscape includes Microsoft’s Azure Digital Twins, Siemens’ Insights Hub, PTC ThingWorx, and open-source options such as Eclipse Ditto. Product status changes quickly, so verify the current lifecycle of any platform before you commit; the existing market commentary that a given product is “deprecated” or “mature” should be checked against vendor announcements, not blog posts, including this one.

What changed recently is standardisation. ISO 23247-1:2021 introduced the manufacturing framework, and the series has grown: the ISO catalogue lists Part 5, on the digital thread, as under publication with a June 2026 edition date. We cover the thread in our piece on the Asset Administration Shell architecture, which is the other major information-model route into the same space.

Finally, the economics have shifted. Compute for physics surrogates and ML inference is cheap enough that the binding constraint is no longer simulation speed. It is data quality, model governance and the operating discipline to keep a twin true for the ten or twenty years the asset lives. That is the theme of this guide.

What a Digital Twin Is, and What It Is Not

A digital twin is a persistent, synchronised model of a specific physical asset or process that is updated from the asset’s data over its lifetime, can be queried or simulated to predict behaviour, and, in the full form, can send validated decisions back to the physical side. The key word is specific: a twin represents one instance, not a product family.

Three neighbours get confused with it, and the distinctions are worth stating bluntly.

A 3D model is geometry. It does not change when the asset does. A simulation is a model run against assumed inputs; run it twice with the same inputs and you get the same outputs, and it has no relationship to the real machine unless you build one. A dashboard is a one-way display of telemetry; it has no model of what the numbers mean and no path back.

A twin has three components: the physical entity, the virtual model that includes state and behaviour, and the data link between them. Remove the link and you have a simulation. Remove the model and you have a dashboard. Remove the physical entity’s identity and you have a generic product model.

This gives a fast test for any proposed project. Ask four questions. What is the unit of identity: one pump, or all pumps? How does state arrive, and with what guaranteed maximum age? What decision does the model support that the raw data does not? And does anything flow back, and who approves it? If a vendor cannot answer the first two precisely, the product is a shadow at best.

The twin taxonomy: asset, process, system, organisation

Scale matters because the engineering changes at each rung.

An asset twin models one machine, such as a pump, a CNC lathe or a robot arm. It typically consumes tens of signals, supports condition monitoring and remaining-useful-life estimation, and lives as long as the asset.

A process twin composes several asset twins into a sequence such as a paint line, a batch reactor train or a lithography cell. Its value is in interactions: throughput, yield, energy and bottlenecks that no single machine owns.

A system twin covers a plant or a site. It adds material flow, logistics and shared utilities, and its main use is capacity planning and scenario analysis. The organisational twin pulls in demand, supplier and financial constraints. It is the rarest and the least standardised, and most claims of “enterprise twin” are really plant twins with a finance dashboard.

The practical rule is to prove value at the asset rung, then compose upward. Our digital twin maturity model post treats fidelity and return as a separate axis from scale, which is the right way to think about it: a plant twin can be low-fidelity and still useful, and an asset twin can be high-fidelity and still not pay back.

Figure 1: Scale (asset to organisation) and maturity (shadow to closed loop) are separate axes. Most value is captured at the asset and process rungs.

The figure maps the scale ladder against three maturity tiers. Notice that the dotted links connect lower maturity to smaller scale on purpose: you earn the right to automate a plant by first having an asset twin whose predictions you have measured and trusted.

The Reference Architecture: Six Layers from Sensor to Decision

A production digital twin stack has six layers: the physical asset, OT data acquisition, an event backbone, a twin state store, models and analytics, and an application layer. The defining feature is not the layers but the return path: commands travel back through a validator that enforces limits, freshness and approval before anything reaches a controller.

Figure 2: Six-layer digital twin architecture. The command path re-enters through the validator, never directly from analytics to the controller.

The diagram shows telemetry flowing up through acquisition, an edge gateway, and the event backbone into the state store, then into models, then into applications. The loop closes through operator approval and a command validator, back to the acquisition layer. The point to take from it is that the validator sits on the write path and is a separate component from the model that proposed the action.

Layers 1 and 2: asset and OT acquisition

The asset is instrumented by sensors and controlled by a PLC or drive. Acquisition is the first place architectures go wrong, because OT protocols were designed for deterministic control, not analytics.

OPC UA is the dominant interoperability layer in discrete manufacturing, with a typed address space, certificate-based security and companion specifications that standardise machine semantics. MQTT, especially with Sparkplug B, dominates where lightweight publish-subscribe and a unified namespace suit the design. Legacy Modbus and fieldbus equipment needs a gateway, and tools such as Apache PLC4X exist to bridge them. If you are choosing, our comparison of OPC UA, MQTT and Sparkplug B is a useful companion.

Two design rules matter here. First, stamp every sample with the source timestamp, taken as close to the sensor as possible, not the arrival time. Everything downstream, from staleness checks to state estimation, depends on it. Second, never let analytics talk to the control network directly. A demilitarised zone with a read-mostly data path is the minimum; writes go through the validator.

Layer 3: the event backbone

The broker decouples producers from consumers. One vibration stream can feed anomaly detection, a historian and a twin update without the sensor knowing. Kafka-style logs give replay and multi-consumer semantics, which matters when you need to recompute a model over last month’s data after fixing a bug. MQTT brokers give simpler operations and lower per-message overhead at the edge.

The trade-off is state. A log is a history; a twin needs current state. Teams that treat the log as the twin end up reconstructing state by replay on every query. Keep the log as the record and derive current state into a store that is indexed for lookup.

Layer 4: the twin state store

The store holds three kinds of information with different access patterns. Structure is the graph: this pump is in that line, which feeds that tank. State is the latest value of each property with its timestamp and quality. History is the time series. Putting all three in one engine is tempting and usually wrong.

Graph platforms such as Azure Digital Twins hold structure and latest state, and they publish limits you should read before designing. The documented defaults include 2,000,000 twins and 20,000,000 relationships per instance, 50,000 incoming and 50,000 outgoing relationships per twin, a 32 KB limit on a single twin payload, and, critically, a non-adjustable ceiling of 10 create, update or delete operations per second on any single twin. We return to that last number below, because it shapes how you ingest.

History belongs in a time-series database or lakehouse, covered in our article on OPC UA historian to digital twin ingestion. Querying the graph for structure and the time-series store for trends, joined by the twin ID, is the pattern that scales.

Layer 5: models and analytics

This layer is where a twin earns its keep, and it contains four kinds of model. Physics models run as FMUs or native solvers. Statistical and ML models handle anomaly detection and remaining useful life. State estimators such as Kalman variants reconcile noisy sensors with a physical model. Optimisers choose setpoints or schedules.

Keep these stateless and event-driven where possible, so they scale horizontally. Keep their parameters versioned as first-class twin metadata. A prediction without the model version, calibration date and input window that produced it cannot be audited or reproduced.

Layer 6: applications and the command path

Applications include 3D scene views, time-series dashboards, work-order integration with maintenance and enterprise systems, and natural-language assistants that are increasingly layered on top. Our post on agentic digital twins covers that last pattern.

The write path deserves its own design. A proposed setpoint is checked against engineering limits, against the age of the state it was computed from, against interlock status and against a human approval policy. Only then is it signed and written. If any check fails the proposal is logged, not executed. This is the single most important safety feature of a closed-loop twin, and it is routinely missing from demos.

ISO 23247, DTDL and the Asset Administration Shell

Three families of specification matter for modelling and governance. They overlap, and the honest answer to “which one” depends on your ecosystem.

ISO 23247: the manufacturing framework

ISO 23247 is the international standard series for digital twin frameworks in manufacturing, developed by ISO/TC 184. The 2021 editions are Part 1 (overview and general principles), Part 2 (reference architecture), Part 3 (digital representation of observable manufacturing elements) and Part 4 (information exchange). The existing literature, including an earlier version of this post, sometimes mislabels Parts 3 and 4, so check the ISO catalogue entry for Part 1 and the sibling parts directly. Part 5 covers the digital thread and shows as under publication with a June 2026 edition date in the ISO catalogue. I could not verify the final status of the other later parts, so treat any claim about them as unverified until you check the catalogue.

The core idea is an observable manufacturing element (OME): the physical thing you want to twin, whether equipment, a work unit, a process, a material or a person. The reference architecture arranges four domains around it, shown below.

Figure 3: The four ISO 23247 domains. Data and control flow between adjacent domains; a cross-system entity provides shared services such as security and interoperability.

The observable manufacturing domain contains the OMEs. The data collection and device control domain holds the sensing, actuation and data-handling functions that touch the physical world. The digital twin domain, the core entity, hosts operation and management, application and service, and resource access and interchange functions. The user domain is where humans and other systems consume results. A cross-system entity supplies common services.

Why does this help in practice? Because it forces a conversation that most projects skip: which functions live where, who owns them, and what crosses each boundary. It also gives auditors and procurement a shared vocabulary. Treat it as a checklist for completeness, not as a product to buy. Platforms do not “embed ISO 23247” in any certifiable way that I could verify; claims that a given cloud service is conformant should be requested in writing.

For composition across several twins, see our piece on ISO 23247-6 composition, which explores integrated, unified and federated patterns.

DTDL: a graph-friendly model language

The Digital Twins Definition Language is a JSON-LD-based language for describing twin models, originated by Microsoft for Azure Digital Twins. Its elements are Interface, Property, Telemetry, Command, Relationship and Component. Versions 2 and 3 are the ones Azure Digital Twins supports, with v3 recommended; the public specification site also hosts a DTDL v4 specification which, per its change list, adds types such as byte, decimal, unsigned integers and uuid plus a scaledDecimal schema, allows self-referential complex schemas, raises nesting depth from 5 to 8 and inheritance depth from 10 to 12, and adds a nullable property for command payloads.

The service documentation contains details that surprise people. Azure Digital Twins supports a subset of the language: commands are not supported, and writable and multiplicity constraints are not enforced. Components can nest only one level. A v2 interface cannot extend a v3 interface. So a model that passes the DTDL parser may still not behave as written on the platform. The practical lesson is to validate against the target service, not only the spec.

A fragment illustrates the style of a v3 interface for a pump:

{
  "@context": "dtmi:dtdl:context;3",
  "@id": "dtmi:example:plant:Pump;1",
  "@type": "Interface",
  "displayName": "Centrifugal pump",
  "contents": [
    { "@type": "Property", "name": "serialNumber", "schema": "string" },
    { "@type": "Telemetry", "name": "dischargePressure", "schema": "double" },
    { "@type": "Telemetry", "name": "vibrationRms", "schema": "double" },
    { "@type": "Component", "name": "motor", "schema": "dtmi:example:plant:Motor;1" },
    { "@type": "Relationship", "name": "feeds", "target": "dtmi:example:plant:Tank;1" }
  ]
}

Note the version suffix in the identifier. Interfaces are immutable once published in a model store, so evolving a model means publishing Pump;2 and migrating twins, which is a governance task as much as a technical one. DTDL’s governance is also worth checking before you commit: the repository sits under the Azure GitHub organisation, and claims about a foundation transfer should be verified rather than assumed. I could not confirm one this run.

The Asset Administration Shell

The AAS, defined by the Industrial Digital Twin Association (IDTA) and aligned with IEC 63278, takes a different tack. Rather than a graph of typed interfaces, it standardises a container per asset, with submodels for each aspect such as nameplate, technical data and carbon footprint, and semantic identifiers that point to dictionaries such as IEC CDD or ECLASS. It is strong where regulation drives interoperability, notably in the Digital Product Passport work. We cover it in Asset Administration Shell architecture and the submodel details elsewhere on this site.

A fair comparison: DTDL is stronger as a runtime graph schema inside one platform, the AAS is stronger as an exchange format between organisations, and both can coexist with an adapter. Choose by where your pain is. If it is modelling a single plant for analytics, DTDL or a custom graph is simpler. If it is passing machine data to customers and suppliers, the AAS wins.

Synchronisation, State Estimation and Co-Simulation

The architecture above is static. The hard engineering is in the dynamics: how fresh is the twin, how do you know, and what happens when the model and the sensors disagree.

The synchronisation budget, with worked numbers

Define twin staleness as the age of the newest data the model used, measured against the physical clock. It is the sum of delays along the path: sensor sampling interval, gateway batching, network transit, broker queueing, store write, and model scheduling.

Take an illustrative asset: a pump skid with 40 signals sampled at 1 Hz, gateway batching of 1 second, 50 ms network, 100 ms broker, 200 ms store write and a model that runs on each change. Worst-case staleness is roughly sampling 1.0 s plus batching 1.0 s plus 0.35 s of transport and write, or about 2.35 seconds. That is fine for condition monitoring, where the decision horizon is hours. It is useless for a closed control loop with a 100 ms cycle, which must stay at the PLC and use the twin only for supervisory setpoints.

Now throughput. Suppose a plant has 500 such machines, each with 40 signals at 1 Hz and about 100 bytes per sample on the wire. That is 20,000 samples per second, about 2 MB/s raw, or roughly 170 GB per day before compression. Neither number is alarming for a modern broker and time-series store. The surprise is at the graph store. If you wrote every sample as a twin property update, you would try 40 writes per second to each machine twin against a documented non-adjustable limit of 10 operations per second per twin, and you would see HTTP 429 throttling.

The fix is a standard one: write state to the twin at a rate that matches the decision, not the sample rate. Batch the 40 signals into one patch per second, or per change beyond a deadband, and send the full-rate stream to the time-series store only. A 1 Hz batched patch is 1 operation per second per twin, well inside the limit, and the other 39 are free. Deadbanding on slowly varying signals can cut the graph write rate by an order of magnitude with no loss of decision quality. These numbers are my illustration, not a benchmark; measure your own signal rates before sizing.

Reconciling desired and reported state

For the write path, borrow the pattern from device-twin systems: keep desired and reported state separate. The application sets desired; the gateway applies it, reads back the value, and writes reported. The twin is “converged” only when they match within tolerance and the reported value is fresh.

Figure 4: A closed-loop update. Every command is validated against limits and state age, and confirmed by a read-back before the twin is marked converged.

The sequence shows the full round trip: a timestamped sample is batched into the store, a change event triggers the model, the model proposes a setpoint, a validator checks limits and data age, a signed command goes through the gateway, and the confirmed value reconciles desired against reported. Failure at any step leaves the twin in an explicit unconverged state rather than a silently wrong one.

Two failure patterns recur. Lost acknowledgements leave the twin believing a setpoint was applied when it was not; the read-back fixes this. Command storms occur when a model oscillates; rate-limit proposals and require a minimum dwell time between changes.

State estimation: when sensors and models disagree

Sensors are noisy, drift and fail. A physical model is smooth but wrong in ways you cannot see. A state estimator fuses them. A Kalman filter does this optimally for linear systems with Gaussian noise; the extended and unscented variants handle mild nonlinearity; particle filters and ensemble methods handle the rest at greater compute cost. Our article on Kalman, particle and ensemble filters for twin synchronisation goes deeper.

The architectural point is that the estimator’s innovation, the difference between predicted and measured values, is a free health signal. A persistently large innovation means a sensor has failed or the model has drifted. Surface it as a first-class twin property, because it tells you how much to trust the twin right now.

FMI co-simulation for physics-accurate what-ifs

The Functional Mock-up Interface, maintained by the Modelica Association, is the portable way to package a simulation model as a Functional Mock-up Unit (FMU): an archive containing a model description XML and the implementation. FMI 3.0 was released in 2022, and 3.0.2 followed as a maintenance release with clarifications and bug fixes but no new features, per the FMI project announcement. FMUs built to 3.0.2 are valid under 3.0 and 3.0.1, and the reverse also holds.

FMI defines two interface types. Model Exchange exposes the equations and lets your solver integrate them. Co-Simulation ships the model with its own solver, and a master algorithm exchanges inputs and outputs at communication steps. For twins, co-simulation is the usual choice because tools from different vendors bring their own solvers.

The master algorithm matters more than people expect. With a fixed communication step, a naive Gauss-Seidel scheme introduces a one-step delay between coupled FMUs, which can destabilise tightly coupled systems such as an electrical machine and its thermal model. Smaller steps reduce error but cost real time. Iterative schemes and rollback, available when FMUs support state save and restore, tighten accuracy at greater cost. Choose the step from the fastest dynamics you must resolve, then test the energy balance of the coupled system as a sanity check.

A concrete example: a drive, a motor and a winding thermal model. Electrical dynamics are in the millisecond range; winding temperature changes over minutes. Running everything at 1 ms wastes compute. Multi-rate co-simulation, with the electrical FMU stepping at 1 ms and the thermal FMU at 1 s, captures both, provided the coupling variables are interpolated sensibly. For model tooling choices, see Modelica versus Simulink for physics-based twins.

Two operational concerns bite in production. Licensing and IP: exporting an FMU from a commercial tool may be restricted by licence, and FMUs contain compiled binaries per platform, so a Windows FMU will not run in a Linux container. Validation: a co-simulation that runs is not a co-simulation that is right. Compare it against measured data over operating envelopes that the model was not calibrated on, and publish the error bounds.

Fidelity, surrogates and uncertainty

Full-physics models are often too slow to run per-event. Reduced-order and surrogate models trade accuracy for speed: proper orthogonal decomposition, physics-informed neural networks and Gaussian processes can run in milliseconds after expensive offline training. The cost is a validity domain. A surrogate trained on normal operation extrapolates badly into faults, which is exactly where you need it. Our post on reduced-order and surrogate models covers the methods.

Whatever the model, report uncertainty. A prediction of “remaining life 41 days” invites misuse; “41 days, 80 percent interval 28 to 55” invites a maintenance decision. The verification, validation and uncertainty quantification discipline is covered in our VVUQ guide.

Platform Choices and Build-versus-Buy

Platform decisions are where most budgets are spent, so a few principles help more than a scorecard that will be stale in six months.

Pick the state store by your query pattern. If you traverse relationships often, such as “all assets downstream of this valve”, a graph engine pays off. If you mostly look up an asset by ID and read its latest values, a document or key-value store is cheaper and faster. Azure Digital Twins is a managed graph with DTDL models, a REST API, event routing, and a query language; its documented ceilings are generous for a single plant but not unlimited, and some are fixed. Eclipse Ditto is an open-source framework for managing device twins with a things API, policies and connectivity to MQTT, AMQP and Kafka, suited to teams who want to self-host. Vendor suites from Siemens and PTC bundle connectivity, modelling and applications and trade openness for integration.

Be sceptical of list prices and monthly cost claims in vendor comparisons. Costs depend on message volume, query units and retention, and I have not verified a current price for any platform in this guide. Build a cost model from your own signal counts, as in the worked example above, and price it against the vendor calculator.

A pragmatic decision rule:

If your situation is	Lean toward	Watch out for
Microsoft estate, graph queries, one or few plants	Azure Digital Twins or similar managed graph	Per-twin write limit, subset of DTDL
Need self-hosting, edge or air-gapped	Eclipse Ditto or a custom store	You own scaling, upgrades and security
Heavy Siemens or PTC automation base	The vendor suite	Proprietary model, exit cost
Exchange of data across companies	AAS-based interface	Tooling maturity, submodel governance
Research or one-off simulation	A custom stack, Modelica, FMI	Maintenance burden when the author leaves

Whatever you choose, keep the model definition outside the platform in source control and generate platform artefacts from it. That is the single best hedge against lock-in, and it is cheap to do on day one and painful on day 500. Our TwinOps lifecycle post treats this as a continuous-delivery problem.

Trade-offs, Gotchas, and What Goes Wrong

The twin that nobody maintains. A twin is a living system. When a sensor is replaced, a line is reconfigured or a PLC program changes, the twin silently diverges. The cheapest control is to attach a drift metric (the estimator innovation above) to each twin and alert on it. Without that, the failure mode is a slow loss of trust: operators stop looking, and the project is quietly declared a pilot.

Fidelity inflation. Teams build a high-fidelity model before they know the decision it supports. A good twin starts from a decision, such as “schedule a bearing replacement within a window”, and works backwards to the minimum model and data. High fidelity costs calibration data, compute and maintenance; it pays only where the decision is sensitive to it.

Time and clock errors. Mixed clocks across PLCs, gateways and brokers break correlation. A 300 ms skew between two sensors can invert apparent cause and effect in a fast process. Use network time synchronisation, or Precision Time Protocol where you need sub-millisecond alignment, and record both source and ingest times.

Semantic mismatch. Two vendors can both expose a “temperature” with different units, positions and meanings. Without a shared semantic layer (OPC UA companion specifications, AAS semantic IDs, or an ontology), integrations succeed syntactically and fail analytically. Units deserve their own care; see our post on AAS units and IEC 61360.

Security on the write path. A bidirectional twin widens the attack surface into OT. Use certificate-based authentication for OPC UA, segment networks, require signed commands, and log all proposals and decisions. Assume the cloud side will be compromised eventually and make sure it still cannot command hardware outside a hard envelope enforced locally.

Data gravity and cost. Shipping every raw sample to a cloud twin is the default, and it is expensive in egress, storage and attention. Do feature extraction at the edge and ship summaries unless you need the raw stream for model training.

Over-promised closed loops. Autonomy should be earned. Begin with advisory mode, where the twin recommends and a human acts, record the acceptance rate and the outcomes, and promote to supervised automation only when the recommendations have been right often enough to justify it. If you cannot measure “right”, you are not ready to close the loop.

Single-vendor model lock-in. DTDL is an open specification published openly on GitHub, and AAS is a published standard, but the tooling and runtime you build on can still lock you in. Keep models portable, as above.

Practical Recommendations

Start from a decision, not a technology. Write one sentence of the form “We will use the twin to decide X, at cadence Y, with accuracy Z”, and let that drive the architecture. If you cannot write it, you are buying a demo.

Build at the asset rung first. One well-instrumented asset type, with a state estimator, an uncertainty-aware prediction and a measured outcome, teaches you more than a plant-wide model, and it gives you the numbers that justify the next rung.

Separate the three stores: graph for structure and latest state, time series for history, object storage for models and files. Join them by a stable twin identifier that you control, not by a vendor’s generated ID.

Make the contract explicit. For every twin property, document the unit, the source, the maximum permitted age, the quality flag and the owner. This turns “is the twin right?” into a testable question.

Use ISO 23247’s domain model as a completeness checklist, DTDL or AAS for the model language that matches your ecosystem, and FMI for portable physics.

Checklist:

[ ] Decision, cadence and accuracy target written down
[ ] Source timestamps captured at the gateway, clocks synchronised
[ ] Graph writes batched to stay well under per-twin limits
[ ] Desired and reported state kept separate, with read-back
[ ] Command validator enforcing limits, state age and approval
[ ] Model definitions in source control, platform artefacts generated
[ ] Drift and innovation metrics alerting per twin
[ ] Uncertainty reported with every prediction
[ ] Advisory mode run and scored before any closed loop
[ ] Vendor lifecycle and pricing verified in writing

Frequently Asked Questions

What is the difference between a digital twin and a simulation?

A simulation is a model run on assumed inputs, usually offline, with no persistent link to a specific asset. A digital twin is bound to one physical instance, is updated from that instance’s data over its lifetime, and can be queried or simulated at any time. Many twins contain simulations, but a simulation alone is not a twin because it lacks the identity and the synchronised data link.

What is ISO 23247 and do I have to comply with it?

ISO 23247 is a series of standards for digital twin frameworks in manufacturing. Part 1 gives the overview and principles and Part 2 the reference architecture, built around observable manufacturing elements and four domains. It is voluntary. Most teams use it as a design and procurement vocabulary rather than a certification target, so ask vendors for specific conformance statements instead of assuming them.

Should I use DTDL or the Asset Administration Shell?

Use DTDL when you want a typed graph schema inside a platform such as Azure Digital Twins, mainly for analytics within one organisation. Use the AAS when you must exchange standardised asset data between companies, particularly under regulatory pressure such as digital product passports. They can coexist through an adapter, and keeping your model in source control makes switching or bridging far less painful.

How real-time does a digital twin need to be?

It depends on the decision, not the technology. Condition monitoring and maintenance planning tolerate seconds to minutes of staleness. Supervisory optimisation might need a second or so. Fast control loops of tens of milliseconds must remain in the PLC; the twin sets supervisory targets rather than closing that loop. Define a maximum permitted data age per property and enforce it in the validator.

How much does a digital twin cost to build and run?

I have not verified a general figure, and published numbers vary widely by scope. Costs come from instrumentation, integration labour, model calibration, cloud usage and ongoing maintenance. Cloud usage depends on message volume, query units and retention. Build a bottom-up model from your signal counts and write rates, then price it with the vendor calculator. Expect integration and upkeep to outweigh platform fees.

Can a digital twin control equipment, or only monitor it?

It can do both, but control should be earned in stages. Start with monitoring, then advisory recommendations scored against outcomes, then supervised automation where a human approves changes, and only then limited closed-loop action inside hard limits enforced locally. Every command should pass a validator that checks limits, data freshness and approval, and should be confirmed by a read-back from the asset.

Digital Twin: The 2026 Architecture Guide for Industrial Systems