IoT, Digital Twin & PLM: The Complete 2026 Overview

Most industrial companies already own all three technologies in this guide, and most of them still cannot answer a simple question: which exact bill of materials, firmware build and CAD revision is the machine in front of me running right now? Engineering holds the answer in product lifecycle management (PLM), operations holds a different one in the historian, and the digital twin that was supposed to reconcile them quietly drifted out of date six weeks after go-live. This IoT digital twin PLM complete overview explains why that happens and what the fix looks like in 2026. The fix is a disciplined digital thread: PLM owns the as-designed definition, a twin runtime instantiates one model per serial number, and IoT telemetry keeps each twin honest. Field findings then flow back into PLM as engineering change requests. The vendor logos have shifted a lot in the past year, but the architecture has not.

What this covers: the working definition of each layer, the reference architecture, the integration standards that matter (ISO 23247, OPC UA, MQTT with Sparkplug B, the Asset Administration Shell), the 2026 vendor landscape including recent ownership changes, a realistic business case, failure modes, and a phased rollout plan.

Last updated November 2026.

Context and Background

Three disciplines grew up separately, and their histories explain most of today’s integration pain.

PLM began in the 1980s and 1990s as product data management: a vault for CAD files and a workflow engine for engineering changes. It grew into the system of record for the bill of materials (BOM), requirements, variants and revisions. Its native unit of time is the revision, measured in weeks or months, and its native unit of identity is the part number, not the individual unit.

Industrial IoT grew out of the operational technology (OT) world: programmable logic controllers (PLCs), SCADA, and historians. Its native unit of time is the sample, measured in milliseconds to seconds, and its native identity is the tag, a string like Line3.Press2.Hydraulic.Pressure. The tag knows nothing about which part revision the press was built to.

The digital twin is the newest of the three and the least standardised. The term covers everything from a 3D viewer with live gauges to a coupled physics model that predicts remaining useful life. That ambiguity is why the standards work matters. ISO 23247 (“Automation systems and integration – Digital twin framework for manufacturing”) is the main ISO series for digital twins in manufacturing; Parts 1 to 4 were published in 2021, and as of this writing Part 5 (digital thread for digital twin) is in the final stages of publication according to the ISO catalogue. We cover the series in depth in our digital twin standards comparison.

The convergence of the three is not a single product you can buy. It is an information architecture, and the hard part is identity: making the part number, the serial number, and the tag name refer to the same physical thing. The Industrial Digital Twin Association’s Asset Administration Shell (AAS) and the ISA-95 equipment hierarchy are the two most-used answers, and we will return to both.

Vendor structure has also moved. Siemens renamed its MindSphere IoT platform to Insights Hub and folded it into the Xcelerator portfolio. PTC completed the divestiture of its Kepware and ThingWorx businesses to the private equity firm TPG, a deal announced in November 2025 and reported as closed in early 2026 (ARC Advisory Group coverage). If your architecture diagram from 2023 shows Windchill and ThingWorx as one vendor’s closed loop, it is out of date. We map the current landscape in our PLM vendor landscape review.

Before the architecture, two vocabulary points that save arguments later. A digital model has no automatic data flow from the physical asset. A digital shadow receives data from the asset but sends nothing back. A digital twin has bidirectional flow, at least in principle. Most “twins” shipped today are shadows, and that is fine as long as you call them that. For a harder look at what real-time claims survive scrutiny, see our digital twin real-time connection fact check.

The Digital Thread Reference Architecture

The digital thread is a four-layer architecture: PLM as the source of truth for design intent, a twin runtime that instantiates that intent per serial number, an IoT layer that feeds it live data, and a feedback path that returns field findings to PLM as change requests. It works only when identity and effectivity are consistent across all four.

Figure 1: Reference architecture. PLM and MES supply the as-designed and as-built definition; the unified namespace supplies live telemetry; the twin runtime joins them and returns insights as change requests.

Figure 1 reads left to right and then loops. Requirements and application lifecycle management (ALM) feed PLM. PLM publishes the engineering BOM (eBOM), the manufacturing BOM (mBOM) and CAD geometry. The manufacturing execution system (MES) records what was actually built, which serial number received which lot of which component. Sensors and PLCs publish through an edge gateway into a unified namespace, and the twin runtime subscribes to both the build records and the telemetry. Its outputs, such as anomaly scores and remaining useful life estimates, become inputs to a change request that re-enters PLM.

PLM: the as-designed and as-planned truth

PLM holds three things the rest of the stack depends on. First, the eBOM: every component as engineering specified it, with its requirements links. Second, the mBOM: the same product restructured for how a plant builds it, with routings, work centres and consumables. The eBOM-to-mBOM transformation is a classic place for data loss, which we dissect in our eBOM to mBOM guide. Third, geometry and behaviour models in NX, CATIA, Creo, SolidWorks or similar, versioned by the same change orders as the BOM.

The one PLM capability that decides whether a digital thread works is effectivity. Effectivity attaches a validity range, by serial number, date or lot, to each change. With it, a twin runtime can ask “what was the as-built structure of unit 4172 on 14 March?” and get one deterministic answer. Without it, the twin links to the latest revision of everything, so every engineering change silently rewrites the history of units already in the field. Teamcenter, Windchill, ENOVIA on 3DEXPERIENCE and Aras Innovator all support effectivity. The failure is almost never missing software; it is that nobody populated the ranges. Our guide to engineering change management and effectivity covers the mechanics.

The twin runtime: three models and one graph

A production twin is usually three things stacked together.

• A structural twin (the twin graph): a queryable representation of the asset, its components and their relationships. Common schemas are the Digital Twin Definition Language (DTDL) used by Azure Digital Twins, the AAS metamodel from IDTA, and vendor-specific models. The graph answers “what is this asset made of and what is it connected to”.
• A physics twin: a first-principles model, such as finite element analysis, computational fluid dynamics, or a 1D system model in Modelica or Simcenter. It extrapolates beyond observed conditions. See Modelica versus Simulink for physics-based twins.
• A data-driven twin: machine learning for anomaly detection and remaining useful life (RUL). It captures effects the physics model omits, but only inside the operating envelope it was trained on.

The twin’s job is to answer two cheap queries: what is the state of this asset now, and what will it do under scenario X. High-fidelity physics is expensive, so production systems often use reduced-order or surrogate models for the real-time path (reduced-order and surrogate models for real-time twins).

IoT: telemetry that is already organised

The IoT layer is where most programmes stumble, and the cause is nearly always the same: the twin is pointed at a flat historian and asked to work out which tag belongs to which asset. That mapping then lives in a spreadsheet, in someone’s head, or in brittle regular expressions.

The better pattern is a unified namespace (UNS): a single, hierarchical topic space on an MQTT broker where every value is published under a path that already reflects the ISA-95 hierarchy (Enterprise, Site, Area, Line, Cell, Device). Sparkplug B, the Eclipse Foundation specification layered on MQTT, adds a standard payload and birth/death state management so that consumers know whether a device is online. The twin runtime subscribes by path and asset identity rather than by guessing tag names. Our deep dives on unified namespace architecture and Sparkplug B versus plain MQTT topics go into topic design and broker clustering.

The feedback path: where the thread closes

A thread that only flows downhill is a report, not a loop. The closing path has three steps. The twin or an analyst detects a pattern, for example a bearing family wearing 30 percent faster in a hot climate than the design assumed. The finding is attached to the affected serial numbers and raised as an engineering change request (ECR). PLM routes the ECR through its normal approval workflow, and the resulting engineering change order (ECO) carries an effectivity range, so the fix applies to future builds and to a defined retrofit population.

Two design choices make this work. The first is that the twin must write back a reference, meaning serial numbers and evidence links, not a free-text complaint. The second is that someone owns the triage role: a field-finding queue that nobody reviews is worse than none, because it creates the illusion of a loop. Our detailed treatment lives in digital thread PLM architecture and implementation.

Identity and Data Flow: The Serial Number Problem

The single most useful mental model in this whole field is that a digital thread is an identity-resolution problem before it is a data-movement problem. Moving bytes is solved. Knowing that three records in three systems describe the same physical unit is not.

Figure 2: The identity chain. Design intent becomes an eBOM and mBOM, the build produces an as-built record for one serial number, and the twin instance joins that record with firmware, configuration and telemetry. Findings return as change requests.

Consider unit serial 4172 of a pump product. PLM knows the part number and the revision effective on its build date. MES knows the lot numbers of the impeller and seal, the torque values recorded at assembly, and the test-bench results. The controller knows its firmware build and parameter set. The historian knows the vibration spectrum. A twin that holds only one of these cannot answer questions that matter, such as “is this unit’s vibration signature unusual given its seal lot?”

Three kinds of BOM state need to coexist, and conflating them is a common mistake:

State	Source	Question it answers	Typical drift risk
As-designed	PLM eBOM	What did engineering intend?	Low; versioned by ECO
As-planned	PLM mBOM, routings	How should the plant build it?	Medium; plant-specific variants
As-built	MES, quality records	What was actually assembled?	High if serial capture is manual
As-maintained	CMMS, service records	What is it now after repairs?	Highest; field swaps often undocumented

The table shows why many twin projects stall at the third and fourth rows. The first two live in PLM and are tidy. The last two live in systems with human data entry, and a field technician swapping a pump head with whatever was on the van will not update the twin.

Effectivity as a query, not a field

It helps to think of effectivity as a query the twin runs, not a metadata field it reads. The query is: given serial S and date D, resolve the product structure. A PLM that supports serial-effective changes returns the structure as built; one that supports only date effectivity requires a join with a production calendar; one that supports neither forces you to reconstruct history from change records. The practical test during vendor evaluation is to ask for a demonstration of exactly this query on a product with at least five released changes.

Identifiers that survive system boundaries

Pick the identifier scheme early, because retrofitting it costs far more than designing it. A workable convention has three parts: a stable asset ID (the serial number or a global individual asset identifier), a type ID (the product model and variant), and a revision-resolved structure ID (derived, not stored). The AAS specification formalises the first two with a globally unique globalAssetId and a type-level versus instance-level distinction. Our explainer on Asset Administration Shell submodels shows how a Digital Nameplate and a Technical Data submodel carry that identity, and the AAS reference architecture shows how shells register and discover each other.

On the 3D side, identity also matters for geometry. Full CAD is far too heavy to stream into a twin viewer, so teams use lightweight derivatives such as glTF, JT or 3MF. The risk is that a derivative loses its link to the PLM part number. We compare the options in lightweight CAD formats for digital twins.

Integration Standards That Matter in 2026

Four families of standards do most of the integration work: ISO 23247 for the twin framework, OPC UA and its companion specifications for machine semantics, MQTT with Sparkplug B for transport and state, and the Asset Administration Shell for asset-level description. They are complementary, and most failed programmes picked one and expected it to do the others’ jobs.

Figure 3: Data path from plant floor to twin. OPC UA servers and protocol gateways feed an edge broker, which bridges to an enterprise unified namespace consumed by the time series store, twin graph and MES. PLM master data enriches the twin graph.

ISO 23247: a vocabulary and a reference model

ISO 23247 is a multi-part series. Part 1 gives an overview and general principles, Part 2 the reference architecture, Part 3 the digital representation of observable manufacturing elements, and Part 4 information exchange. Its central abstractions are the observable manufacturing element (OME), the physical thing being mirrored, and the digital twin entity, with functional sub-entities for data collection, device control and operations management. Part 5, on the digital thread for digital twins, is listed as under publication at the time of writing, so treat any detail you read about it as subject to change. We analyse it in ISO 23247-5 digital thread reference architecture and the composition question in ISO 23247-6 on composing twins.

What ISO 23247 does not do is prescribe a protocol, a vendor or a data model. That is a deliberate choice, and it means the standard’s value is mostly organisational: it gives engineering, IT and operations a shared noun list. Use it to write the architecture decision record that maps your systems to its entities, then move on.

OPC UA and companion specifications

OPC UA (IEC 62541) is the dominant protocol for exposing machine data with semantics. The protocol defines how to browse and read nodes; companion specifications define what the nodes mean for a machine class. The Robotics companion (OPC 40010) from the OPC Foundation and VDMA, the Machinery building blocks, and domain specs such as those for machine tools via umati are examples. The OPC Foundation’s reference site indexes the published specifications.

Companion specs matter for twins because they make equipment composable. If three robot brands expose joints and programs through the same information model, one twin template covers all three. Without them, every integration is bespoke. Read more in OPC UA companion specifications for robotics and machinery, and check the security posture in OPC UA security certificates and trust lists.

MQTT, Sparkplug B and where OPC UA fits

OPC UA and MQTT are often presented as rivals, but they solve different layers. OPC UA excels at rich, self-describing, machine-level models and client-server interaction at the cell. MQTT excels at lightweight publish-subscribe fan-out across sites. A common 2026 pattern is OPC UA inside the cell, an edge gateway that maps selected nodes to a Sparkplug B topic tree, and an enterprise MQTT broker cluster above. OPC UA PubSub over MQTT and the newer field-level work are alternatives; the trade-offs are laid out in OPC UA versus MQTT Sparkplug B and OPC UA PubSub over MQTT versus UADP. If you need a refresher on the broker itself, start with our MQTT protocol guide.

Two operational details are routinely underestimated. First, time. Correlating a vibration spike with a PLC event requires synchronised clocks, and the differences between NTP and IEEE 1588 PTP are material at millisecond scales (time synchronisation for industrial IoT). Second, offline behaviour. Plants lose uplinks, and a gateway that drops data during an outage creates holes the twin cannot fill (store-and-forward at the edge).

The Asset Administration Shell

The AAS, specified by the Industrial Digital Twin Association (IDTA) and aligned with IEC 63278, is a standard container for asset information: a shell that references submodels, each describing one aspect (nameplate, technical data, documentation, operational data). Its strength is supply-chain interchange. A supplier ships a shell with the component, and the integrator ingests it without reading a PDF. It is less a runtime than a description format, so it complements rather than replaces a twin platform. See the IDTA content hub for current submodel templates and our BaSyx tutorial for a hands-on implementation.

The ALM-PLM-MES backbone

Three enterprise systems frame the engineering-to-execution chain. ALM tools (Polarion, Codebeamer, Jama, DOORS) own requirements and software. PLM owns mechanical, electrical and overall structure. MES owns execution. Requirements flow from ALM to PLM, PLM releases the build definition to MES, MES reports as-built data back, and the twin reconciles intent against reality. The requirements side is covered in requirements management in PLM, and the execution side in digital twin and MES reference architecture.

The 2026 Vendor and Platform Landscape

Vendor positioning shifts faster than architecture, so this section is a snapshot, and you should verify current packaging before purchase. The comparison below describes categories of capability, not a ranking.

Stack	PLM	IoT and twin layer	Notable 2026 context
Siemens Xcelerator	Teamcenter (including Teamcenter X, SaaS)	Insights Hub (formerly MindSphere), Simcenter for simulation	MindSphere renamed Insights Hub
PTC	Windchill	ThingWorx now owned by TPG, not PTC	PTC divested Kepware and ThingWorx; closed loop now needs a partnership model
Dassault Systemes	ENOVIA on 3DEXPERIENCE	DELMIA, “virtual twin” positioning	Single-platform approach
Aras	Innovator	Bring your own IoT layer	Flexible data model, common in mid-market
Hyperscaler-led	Any PLM	AWS IoT TwinMaker and SiteWise, Azure Digital Twins	Consumption pricing, DIY integration

Three observations follow. First, single-vendor suites reduce integration work at the price of lock-in, and the PTC divestiture is a reminder that “single vendor” is not permanent. If your closed loop depends on a vendor pair, write the interface contract so that either side can be swapped. Second, hyperscaler twin services give you a graph and an ingestion path but not the PLM semantics, so effectivity and BOM logic still have to be built or integrated. Third, open standards (AAS, OPC UA, MQTT) are your insurance against both. A fuller comparison of the PLM side, including SaaS migration trade-offs, is in Teamcenter X versus 3DEXPERIENCE versus Windchill, and the AI-assisted direction of travel in AI-native PLM.

A last practical note: do not choose the twin platform first. Choose the identity scheme, then the namespace design, then the PLM integration, and only then the runtime. Teams that reverse this order spend a year migrating tag names.

The Business Case: What the Numbers Can and Cannot Tell You

Programmes that close the loop between PLM, twin and IoT report gains in four places: shorter new product introduction (NPI) cycles, lower unplanned downtime, lower warranty cost, and higher throughput. Vendor case studies commonly quote ranges such as 20 to 50 percent NPI compression, 30 to 50 percent downtime reduction, 15 to 25 percent warranty reduction and 10 to 25 percent throughput gain. Treat these as marketing-grade, unverified ranges. They come from selected reference customers, they are rarely audited, and the baselines are seldom disclosed. We could not trace them to an independent, peer-reviewed study for this update.

A more honest way to build the case is to model one lever at a time from your own baselines. For a predictive-maintenance lever, the arithmetic is simple and checkable. Illustrative example, with invented round numbers: a plant has 40 critical assets, each with an average of 1.5 unplanned stoppages per year, costing 25,000 currency units per event in lost output and repair. Baseline loss is 40 x 1.5 x 25,000 = 1.5 million per year. If a twin-driven programme prevents 20 percent of events, savings are 300,000 per year, before subtracting instrumentation, licences and analyst time. That number is modest, believable, and falsifiable, which makes it more useful than a 50 percent headline.

For the design-side lever, the model changes. The value of the feedback loop is the cost of a defect found after launch versus before. Defects traced to a field failure mode that a twin surfaced early convert a recall-scale event into an ECO. That value is real but lumpy and hard to forecast; sponsors should accept it as an option value rather than a line-item saving.

On cost, we have no independently verified benchmark for total programme spend, and published figures vary widely with scope. Cost buckets are predictable even when totals are not: platform licences or consumption fees, integration labour, sensors and edge hardware, and change management. In practice, integration labour and data cleanup dominate more often than licences. Hyperscaler stacks shift cost from upfront licences to run-rate consumption, which helps when capital is constrained and scope is still unclear. A maturity-based framing for sequencing investments is in the digital twin maturity model and ROI framework.

The compounding effect matters more than any single metric. When each product generation inherits the measured failure modes of the last, design assumptions are replaced with data. That advantage accrues slowly and is invisible in a first-year ROI sheet, which is why programmes sold only on year-one savings tend to lose sponsorship in year two.

Deeper Walk-Through: A Pump Fleet from Order to Field Finding

A concrete scenario ties the layers together. Imagine a manufacturer of industrial pumps with three variants, shipping about 2,000 units a year. The aim is a twin per unit that predicts seal wear and feeds the next design revision.

Step 1: Define the asset type in PLM. The pump’s eBOM lists the seal assembly as a sub-assembly with two released seal revisions, A and B. Revision B became effective at serial 3100 after a materials change. The ECO is recorded with a serial range, not just a date.

Step 2: Release to MES. The mBOM and routing go to the plant’s MES. At assembly, the station scans the seal lot barcode and the serial number, writing both to an as-built record. This scan is the cheapest, highest-value data capture in the whole programme.

Step 3: Publish telemetry into the namespace. The pump controller exposes vibration RMS, bearing temperature and motor current over OPC UA. An edge gateway publishes selected values under a path like acme/plant2/line4/testcell/pump-4172/vibration/rms, with Sparkplug B birth messages declaring metric definitions. Because the path embeds the asset ID, no lookup table is needed.

Step 4: Instantiate the twin. On the first birth message from pump-4172, a small service queries PLM and MES for that serial: type, variant, seal revision, lot. It creates a twin instance in the graph, attaching the as-built structure. The identity chain from Figure 2 is now live.

Step 5: Run the model. A data-driven model scores vibration trends against a population of the same variant and seal revision. Because the model is conditioned on revision, a shift in revision B units is visible as a cohort effect rather than noise.

Step 6: Raise the finding. After 14 months, analysis shows that revision B units operating above a stated temperature show earlier seal degradation. This finding is illustrative, constructed for this walk-through, not a measured result. The system opens an ECR in PLM referencing the 61 affected serial numbers and the evidence plots. Engineering approves a seal change as revision C, effective from a future serial, plus a service bulletin for the installed base.

The scenario shows why each layer is necessary. Without PLM effectivity, the cohort could not be defined. Without MES serial capture, the lot would be unknown. Without the namespace, the telemetry would not be attributable. Without the feedback path, the insight would end in a slide deck. Each is individually modest; their combination is the thread.

Failure modes visible in this scenario

Walk the scenario with an adversarial eye and the weak points emerge. If the scanner at Step 2 is bypassed during a rush order, the as-built record is missing and the unit’s twin falls back to the design BOM, silently. If the gateway restarts and republishes a stale birth certificate, the twin may flip a unit to the wrong variant. If the model at Step 5 was trained mostly on revision A, it may mis-score revision B for months before anyone notices. These are not exotic; they are the normal ways a thread breaks, and each has a mitigation: a hard gate that refuses to release a serial without a scan, a consistency check between declared and queried variant, and monitoring of model drift by cohort. For the uncertainty side, see verification, validation and uncertainty quantification for digital twins, and for keeping the twin’s state aligned with reality see state estimation with Kalman and particle filters.

Capacity and sizing, in order of magnitude

Rough sizing helps you avoid both over-building and under-building. Suppose 2,000 units in the field, each publishing 20 metrics once per second. That is 40,000 messages per second sustained, or roughly 3.5 billion per day, if every sample is forwarded unmodified. A single modern MQTT broker node can handle that order of throughput on paper, but the storage bill is the real constraint, which is why edge aggregation matters. Publishing 10-second aggregates (mean, min, max) for most metrics and full-rate data only on event triggers cuts volume by roughly an order of magnitude. Compression schemes designed for time series, such as those described in time series compression with Gorilla-style encoding, reduce storage further. These are back-of-envelope figures from simple arithmetic, not benchmarks; always load-test your own broker and database with your own payloads.

Trade-offs, Gotchas, and What Goes Wrong

The most common failure is not technical. It is organisational ownership. PLM belongs to engineering, the historian to operations, the cloud platform to IT, and the twin to nobody. A programme without a named owner for the identity scheme will accumulate three incompatible ones. Appoint an architecture owner with authority across all three groups before writing code.

Twin drift is the second. A twin is a model, and models decay as the asset changes. Firmware updates, field repairs, and ECOs alter the real asset; if the twin is not updated through the same events, it diverges. Design the twin to be rebuilt from authoritative sources on a schedule rather than hand-patched. Treat any manually edited twin attribute as a defect.

Over-modelling is the third. Teams reach for high-fidelity physics when a simple threshold on a well-chosen signal would have caught the fault. Before building a coupled simulation, ask whether a statistical process control chart on the same signal would meet the need (SPC for streaming IIoT). A twin is a means, not a deliverable. If you are deciding between a twin and a plain simulation, digital twin versus simulation lays out the test.

Security and compliance are routinely deferred and then retrofitted at high cost. A twin that joins design data with live operational data concentrates sensitive intellectual property and a path into OT networks. Certificate management, network segmentation and firmware provenance all need design-time attention. Regulatory regimes are also tightening; the EU Cyber Resilience Act, for example, creates obligations around software bills of materials for connected products (Cyber Resilience Act and SBOM), and regulated sectors such as medical devices and aerospace require traceability that PLM-backed twins can help satisfy. This is not legal advice; confirm obligations with counsel.

Legacy equipment is the fourth gotcha. Most plants run machines that predate OPC UA. Retrofitting through Modbus gateways works but produces thin, untyped data that lacks the companion-spec semantics discussed earlier. Budget for a semantic mapping layer (brownfield Modbus to unified namespace).

Data migration is the fifth. Legacy PLM data is often inconsistent: duplicate part numbers, missing effectivity, free-text change reasons. Cleaning it is unglamorous and unavoidable; see PLM data migration strategy.

Finally, a contrarian view, offered as opinion: many organisations should build fewer twins than they think. A twin earns its cost where assets are expensive, failures are costly, and variants are numerous enough that population-level learning pays off. For low-value, high-volume parts, a quality-control process and a good PLM may be all the thread you need.

Practical Recommendations

Start from the question, not the platform. Pick one product line and one decision a twin could improve, for example scheduling seal replacement or validating a design change against field loads. Then work backwards to the minimum data needed.

Figure 4: A four-phase rollout with a gate at the end of each of the first three phases. Do not start the next phase until the gate is met.

Phase 1, instrument and observe (roughly months 0 to 6). Choose one product line. Stand up an MQTT broker with a Sparkplug B unified namespace, bridge existing OPC UA servers, and land the data in a time series store. Define one twin schema for the lead asset class. Gate: clean, correctly attributed telemetry for every unit on that line.

Phase 2, a twin per serial number (roughly months 6 to 12). Push as-built BOM and revision data from PLM and MES into the twin runtime, keyed by serial. Add one model that produces a useful prediction and connect its output to the maintenance work-order system. Gate: one prediction in production with a measured effect on downtime or quality.

Phase 3, close the loop (roughly months 12 to 24). Build the path from twin findings to ECRs in PLM, and define who approves conversion of a field finding into a change. Gate: at least one released ECO whose evidence came from twin data.

Phase 4, scale. Reuse the blueprint on a second product line. Expect the identity scheme and namespace design to transfer; expect the models to need retraining. The timelines here are planning heuristics from typical programme shapes, not guarantees, and larger organisations will take longer.

A short checklist before you commit funding:

• A named owner for the cross-system identity scheme exists.
• Your PLM can resolve product structure by serial number, and you have seen it do so on real data.
• Serial and lot capture at assembly is enforced, not optional.
• Telemetry is published under a path that embeds the asset ID and follows the ISA-95 hierarchy.
• Every twin attribute has a documented authoritative source; none are hand-edited.
• You have a written interface contract for each vendor-to-vendor link, so any one can be replaced.
• The first use case has a baseline number you measured yourself.
• Security review covers certificates, segmentation and IP exposure of combined design and operational data.

If the answer to several of these is no, spend the next quarter fixing them. It is cheaper than discovering them mid-integration.

Frequently Asked Questions

What is the digital thread?

The digital thread is the connected chain of data linking a product’s engineering definition in PLM, its manufacturing record, its runtime model and its field telemetry across the lifecycle. It is “unbroken” when data flows in both directions: PLM down into the twin, telemetry into the twin, and field findings back up into PLM as change requests. In practice it requires effectivity-controlled PLM, consistent asset identifiers, and a namespace that publishes telemetry in a form the twin can attribute to a specific serial number.

Is a digital twin the same as IoT?

No. IoT is the acquisition layer: sensors, gateways and protocols such as MQTT and OPC UA that move telemetry off an asset. A digital twin is the model layer that consumes that telemetry, combines it with structural and behavioural models, and exposes state, predictions and what-if analysis. IoT without a twin is a stream of numbers; a twin without IoT is a static simulation. Most useful systems need both, plus PLM context to know what the asset is.

Do I need PLM to build a digital twin?

Not for a proof of concept on a single asset, where IoT, a historian and a model are enough. You need PLM once you have multiple variants, revisions and serial numbers, because you must answer which BOM, firmware and CAD revision a specific unit runs. Regulated products add another driver, since traceability expectations in sectors such as medical devices and aerospace are easier to meet with PLM. The break-even is a judgement call, not a fixed asset count.

Which PLM works best with digital twins?

No single platform wins on every criterion. Siemens Teamcenter pairs with Insights Hub and Simcenter; PTC Windchill is strong on configuration management but its ThingWorx IoT product moved to TPG; Dassault 3DEXPERIENCE offers a single-platform approach; Aras Innovator suits teams wanting a flexible model with a separate IoT layer. Choose based on existing CAD investment, regulatory needs and appetite for lock-in, and insist on demonstrating serial-level effectivity queries before signing.

What is ISO 23247?

ISO 23247 is the ISO series titled “Automation systems and integration – Digital twin framework for manufacturing”. Parts 1 to 4 (overview, reference architecture, digital representation of observable manufacturing elements, and information exchange) were published in 2021. Part 5 covers the digital thread and was in final publication stages at the time of writing. It defines the observable manufacturing element and the digital twin entity, and gives a shared vocabulary without mandating a vendor, protocol or data model.

How long does an IoT, digital twin and PLM programme take to pay back?

There is no reliable universal figure. Vendor case studies quote payback in roughly one to three years, but these are unaudited reference customers. The realistic approach is to model one lever from your own baselines, such as avoided unplanned downtime on a defined set of critical assets, and test it in a bounded first phase. Programmes scoped to one product line with a measurable anchor use case reach credible evidence much sooner than enterprise-wide efforts.

Further Reading

• What is IoT? The complete technical guide: the foundation for the instrumentation layer.
• MQTT protocol complete technical guide: broker behaviour, QoS and sessions.
• Digital thread PLM architecture and implementation: the deeper treatment of the thread.
• Unified namespace architecture for industrial IoT: topic design and governance.
• Digital twin standards: ISO 23247, ISO/IEC 30173 and DTC: standards landscape.
• PLM vendor landscape 2026: how the major platforms compare.
• External: the ISO 23247 series page, the OPC Foundation specification index, and the IDTA Asset Administration Shell content hub.

Last updated November 2026.

By Riju — about