Digital twin development is one of the few engineering disciplines where the demo is trivially easy and the delivery is genuinely hard. Anyone can spin a 3D model of a pump in a browser and pipe a temperature reading into a label above it. That takes an afternoon. Keeping that model faithful to a real pump, in a real plant, through six firmware revisions, two sensor replacements and a change of maintenance contractor — that takes a programme, and it is the part almost nobody scopes properly.
The gap between those two things explains most of the disappointment in this market. The Digital Twin Consortium settled on a definition in December 2020 that is unusually precise for an industry body: a digital twin is “an integrated data-driven virtual representation of real-world entities and processes, with synchronized interaction at a specified frequency and fidelity.” Read that last clause again. Frequency and fidelity are not implementation details you discover later. They are the two numbers that decide your architecture, your cloud bill and whether the thing is useful at all.
This guide walks through what a twin actually is, how one works layer by layer, what the platforms cost at published list prices, which standards are worth adopting, and a step-by-step route to building one. It is written for the person who has to sign off a digital twin development budget and then live with the result. If you want the market-level view of where this technology is heading for smaller UK operators, our companion piece on digital twins in 2027 covers the adoption side; this article is about the engineering.
Table of contents
- What a Digital Twin Actually Is, and Why the Definition Matters
- How a Digital Twin Works: The Five Layers Underneath It
- Digital Twin Development Is a Data Problem Wearing a 3D Costume
- The Digital Twin Development Stack: Platforms, Prices and Trade-offs
- Standards That Make Digital Twin Development Survivable
- How to Build One: A Six-Step Digital Twin Development Roadmap
- Fidelity and Frequency: The Two Dials That Set Your Digital Twin Development Budget
- What Digital Twin Development Actually Costs
- The Market Context Behind Your Digital Twin Development Business Case
- Where Digital Twin Development Projects Fail
- Build vs Buy in Digital Twin Development
- Governance, Security and the Gemini Principles
- A 90-Day Digital Twin Development Plan
- Frequently Asked Questions About Digital Twin Development
- Where to Start
- References and Further Reading
What a Digital Twin Actually Is, and Why the Definition Matters
Definitions usually do not earn their place in a technical article. This one does, because the loose version of the term is what gets projects funded on the wrong premise and then quietly cancelled eighteen months later.
The digital twin development definition that survives an engineer
ISO is even blunter than the Consortium. ISO 23247-1 defines a manufacturing digital twin as a “fit for purpose digital representation of an observable manufacturing element with synchronization between the element and its digital representation.” Two load-bearing phrases: fit for purpose and synchronization. A representation that is not synchronised is a model. A model that is not fit for a stated purpose is a hobby.
Every serious digital twin development effort therefore starts by naming the observable element, naming the purpose, and naming the synchronisation contract between them. If you cannot write those three things on one side of paper, you are not ready to build.
Three things a digital twin is not
It is not a 3D model. A CAD assembly is geometry with no live state. It is not a simulation. A finite element run is a model executed against assumed inputs, not against this asset’s inputs, right now. And it is not a dashboard. A dashboard reports what a sensor said; a twin infers what the asset is doing, including the quantities you never instrumented.
Those distinctions matter commercially, because all three of those artefacts are far cheaper than a twin and each of them is the right answer to a large number of problems. A good digital twin development partner will tell you when you need the cheaper thing.
| Artefact | Live data | Predicts | Typical build |
|---|---|---|---|
| 3D/CAD model | No | No | Days |
| Operational dashboard | Yes | No | Weeks |
| Offline simulation | No | Yes | Weeks to months |
| Digital shadow (one-way sync) | Yes | Limited | Months |
| Digital twin (two-way sync) | Yes | Yes | Months to years |
Shadow first, twin second
The row worth staring at is the digital shadow: a one-way synchronised representation that reflects the asset but cannot act on it. Most organisations should build the shadow, run it for two quarters, prove the model tracks reality, and only then close the loop. Treating the shadow as a deliberate first release rather than a failed twin is the single cheapest risk reduction available in digital twin development.
How a Digital Twin Works: The Five Layers Underneath It
Underneath every twin, however it is marketed, sit the same five layers. Knowing which layer a vendor is actually selling you is most of due diligence.
Layer 1: the physical asset and its instrumentation
Everything begins with what you can observe. Sensors, PLC tags, SCADA historians, vision systems, meters, RFID reads, and manual inspection records are the raw signal. The uncomfortable truth is that most brownfield sites are instrumented for alarms, not for modelling — you have thresholds and trips, not continuous, timestamped, calibrated series.
An honest instrumentation audit almost always produces a capital line nobody put in the digital twin development budget. Budget for it before the software conversation starts, and see our IoT solutions and Internet of Things pages for what that retrofit typically involves.
Layer 2: connectivity and the data pipeline
Signals then have to travel, usually over OPC UA, MQTT or a vendor gateway, into an ingestion service and onward into storage. This is where latency budgets, buffering during network loss, time synchronisation across devices, and unit normalisation all get decided.
Two failure modes dominate here. The first is clock skew: two devices disagreeing about when an event happened by more than your control loop can tolerate. The second is silent gap-filling, where a pipeline interpolates missing readings and the model downstream cannot tell measurement from invention.
Layer 3: the model — physics, data-driven or hybrid
The model is the twin’s brain and comes in three flavours. Physics-based models encode known equations and generalise well to conditions you have never seen. Data-driven models learn from history, need far less domain knowledge, and fail unpredictably outside their training envelope. Hybrid models use physics for structure and machine learning for the residual, and are what most mature deployments converge on.
Choosing wrongly here is the most expensive single mistake in digital twin development. A purely data-driven twin of a machine that has never failed has no failure data to learn from, which is precisely the case on the assets you care most about.
Layer 4: synchronisation, the layer everyone underestimates
Synchronisation is the contract that makes the whole thing a twin rather than a picture. It specifies how often state is refreshed, how stale a value may be before it is discarded, what happens when the asset and the model disagree, and who wins.
Getting this wrong is not a performance problem, it is a correctness problem, and it is the part of digital twin development most often left implicit. A twin quietly serving fifteen-minute-old state to a decision that assumes real time is worse than no twin, because it is trusted.
Layer 5: the application layer, where value is realised
The top layer is what people actually buy: predictive maintenance, throughput optimisation, energy modelling, operator training, scenario testing, and remote diagnostics. It is also, invariably, the thinnest layer in terms of effort. The visual front end that impresses the board is typically under a tenth of the work in serious digital twin development, which is why the demo is so misleading a guide to the delivery.
Digital Twin Development Is a Data Problem Wearing a 3D Costume
If there is one idea to take from this article, it is this one. The rendering is the cheapest part. The data is the project.
Why visualisation-first digital twin development stalls
A visualisation-first programme optimises for the wrong thing early. Money goes into scene authoring, asset dressing and camera work, all of which produce something demonstrable in six weeks. Then the team turns to the data layer and discovers that half the tags are unlabelled, the historian retains ninety days, three lines share a single ambiguous asset ID, and nobody can say which sensor was recalibrated in March.
At that point the visual work has to be redone against a corrected asset model, and the programme has spent its credibility. Sequencing digital twin development so that the data model is proven before the scene is authored costs nothing extra and removes the most common cause of a stalled second phase.
The data layer test every digital twin development plan must pass
Before approving any digital twin development build, ask for four things in writing: a canonical asset register with stable identifiers, a tag dictionary with units and calibration dates, a retention policy long enough to cover at least one full seasonal cycle, and a named owner for each source system. If any of the four is missing, that is your first sprint, not a prerequisite you can wave through.
This is unglamorous work and it is where a good data management and analytics capability earns its fee. It is also reusable — the asset model you build here serves reporting, predictive analytics and compliance long after the twin ships.
The Digital Twin Development Stack: Platforms, Prices and Trade-offs
The platform market has settled into three broad camps: hyperscaler twin services, simulation and visualisation engines, and vertical specialists. Published list prices are the honest starting point for any digital twin development budget, so here they are.
Azure Digital Twins: consumption pricing, three meters
Microsoft bills Azure Digital Twins on three dimensions — operations, messages and query units — with no upfront commitment. In East US the published rates are $2.50 per million operations, $1.00 per million messages and $0.50 per million query units. Messages are metered in 0.5 KB increments, so a 1.5 KB payload counts as three.
UK-hosted workloads pay a regional premium of exactly 25% on all three meters. That is a real number to carry into a digital twin development business case, because data residency is rarely negotiable for industrial customers.
| Azure Digital Twins meter | East US, per million | UK South, per million | UK premium |
|---|---|---|---|
| Operations | $2.50 | $3.12 | +25% |
| Messages | $1.00 | $1.25 | +25% |
| Query units | $0.50 | $0.625 | +25% |
AWS IoT TwinMaker: entities, API calls and queries
Amazon prices differently, and the difference shapes design. Under the standard plan, AWS IoT TwinMaker charges $1.50 per million unified data access API calls, $0.05 per entity per month, and $0.50 per 10,000 queries executed. New customers get up to 50 million data access API calls per month for the first twelve months, and since 15 July 2025 new accounts also receive up to $200 in AWS free tier credits applicable to eligible services.
The per-entity charge is the one to model carefully in any digital twin development estimate. At $0.05 per entity per month, a twin with 40,000 modelled entities costs $2,000 a month before a single query runs, so entity granularity becomes an architectural decision with a direct price tag attached.
NVIDIA Omniverse: the price just went to zero
The most consequential pricing change in this space happened quietly. As of May 2026, NVIDIA Omniverse is free for both development and production use, confirmed in a short note posted to the NVIDIA developer forums on 1 July 2026. Previously, production deployment required an NVIDIA AI Enterprise subscription at $4,500 per GPU per year, $22,500 per GPU perpetual, or $1 per GPU-hour on cloud marketplaces.
That removes a five-figure annual barrier from photoreal, physically accurate twin visualisation. Enterprise-grade support is still a paid subscription, but the software licence is no longer a reason to abandon a digital twin development proposal at the budget stage.
| Platform | Pricing model | Published entry rate | Best suited to |
|---|---|---|---|
| Azure Digital Twins | Three consumption meters | $1.00 per million messages (East US) | Graph-modelled estates, Azure-native shops |
| AWS IoT TwinMaker | Entities plus API calls plus queries | $0.05 per entity per month | Federating existing AWS data sources |
| NVIDIA Omniverse | Free licence, paid support optional | $0 as of May 2026 | Photoreal, physics-accurate visualisation |
| Engineering simulation suites | Named-user or token licences | Quotation only | High-fidelity physics on critical assets |
| Open-source stack | No licence cost | $0 plus engineering | Teams with strong platform capability |
Open-source digital twin development is real, and it is not free
A credible twin can be assembled from open components: an MQTT broker, a time-series database, a graph store for the asset model, a physics or ML runtime, and a web renderer. Licence cost is zero. Engineering cost is not, and neither is the ongoing burden of owning that stack, which is why this route to digital twin development suits organisations that already run a mature DevOps practice and fails everyone else.
Standards That Make Digital Twin Development Survivable
Standards are usually where an article like this loses the reader. Stay for this section, because adopting two of them will materially reduce what digital twin development costs you to maintain in year three.
ISO 23247 and the reference architecture
ISO 23247, Automation systems and integration — Digital twin framework for manufacturing, was published in 2021 in four parts: overview and general principles, reference architecture, digital representation of manufacturing elements, and information exchange. NIST has published its own analysis of the series, which is the most readable entry point.
The reference architecture is the useful bit. It gives you named subsystems — data collection, device control, digital twin core, and user entities — so that a digital twin development team and a plant engineering team can argue about the right thing.
Part 5 and Part 6 landed in 2026
The series grew this year. ISO 23247-5 specifies the digital thread, covering how twins are created, connected, managed and maintained across the product life cycle. ISO 23247-6 addresses digital twin composition and names three patterns: integrated, unified and federated.
Composition is the question every second-phase digital twin development programme hits. Once you have a twin of a pump and a twin of a line, how do they combine? Having a standard vocabulary for that decision is worth more than it sounds, and it arrived precisely as the market started building composite twins.
The Asset Administration Shell and IEC 63278
In the European industrial world the dominant model is the Asset Administration Shell, standardised as IEC 63278-1:2023, which defines the structure of a standardised digital representation of an asset. The Industrial Digital Twin Association maintains the detailed metamodel specification and a growing library of submodels for specific asset types.
If your twin has to exchange information with suppliers’ equipment, the Asset Administration Shell is the interoperability layer that makes it possible without a bilateral integration per vendor.
DTDL, and why the ontology is a governance artefact
Azure Digital Twins models are written in the Digital Twins Definition Language, a JSON-LD dialect describing types, properties, telemetry, components and relationships. Whatever platform your digital twin development lands on, you will end up with an ontology, and that ontology is a governance artefact rather than a technical one.
Version it, review changes the way you review database migrations, and give it an owner. An unversioned ontology is how a twin ends up with four incompatible definitions of “downtime” and a reporting argument nobody can settle.
| Standard or spec | Scope | Status | Adopt when |
|---|---|---|---|
| ISO 23247-1 to -4 | Manufacturing twin framework and reference architecture | Published 2021 | Any manufacturing twin |
| ISO 23247-5 | Digital thread across the life cycle | Published 2026 | Twin must span design to service |
| ISO 23247-6 | Composition: integrated, unified, federated | Published 2026 | More than one twin in the estate |
| IEC 63278-1 | Asset Administration Shell structure | Published 2023 | Cross-vendor equipment data exchange |
| DTDL | Ontology language for Azure Digital Twins | Vendor specification | Building on Azure |
| Gemini Principles | Values framework for built-environment twins | Published 2018 | Infrastructure and public assets |
How to Build One: A Six-Step Digital Twin Development Roadmap
This is the practical core. Six steps, in this order, with a named output at each one. Skipping a step does not save time; it moves the cost to a later phase where it is larger.
Step 1: write down the decision the twin exists to support
Not the use case — the decision. “Predictive maintenance” is a use case. “Whether to pull pump P-114 into the Tuesday window or run it to the planned September outage” is a decision, and it tells you exactly what the twin must predict, how far ahead, and with what confidence.
Every successful digital twin development programme we have seen starts here, and most failed ones started with a platform selection instead. The output of this step is one page naming the decision, the decision-maker, the current basis for that decision, and the improvement that would justify the build.
Step 2: fix the fidelity and frequency in writing
Return to the Consortium definition: synchronised at a specified frequency and fidelity. Specify them. Does the model need to track to 1% or 10%? Does state refresh every second, every minute, or every shift? What is the maximum acceptable staleness before a value must not be used?
These three numbers drive more of your cost than any other decision in digital twin development, and they are far easier to argue about now than after the architecture is built around the wrong assumption.
Step 3: audit the data you actually have
Run the four-part data layer test from earlier against every source system. Produce a gap list separated into “instrument it”, “fix the metadata”, and “we will infer it”. Anything in the third bucket needs a stated method and an error bound, not a hope.
Expect this stage of digital twin development to take four to six weeks on a brownfield site and to produce at least one genuinely unwelcome finding. That is the step working correctly.
Step 4: build and validate the model before the visuals
Build the model against historical data and hold back a period the model has never seen. Score it against that hold-out. If it cannot reproduce a known past event — a failure, a quality excursion, an energy spike — it will not predict the next one. Iterate on the model, not on the render.
Where the physics is well understood, digital twin development should start physics-first and add a learned residual. Our ML model development page covers how that residual is trained and, more importantly, how it is monitored afterwards.
Step 5: close the loop, or say plainly that you have not
Now decide whether the twin recommends or acts. A recommending twin needs an operator interface and an override log. An acting twin needs a safety case, a fallback mode, and a clear boundary around what it may change. Many teams train a reinforcement learning controller against the twin in simulation long before it is allowed near the real process, which is exactly the right order.
Whatever you choose, document it. The dangerous state is a twin that everyone assumes is closed-loop and which actually requires a human who left the business in March.
Step 6: validate continuously, because the asset changes
Assets drift. Bearings wear, control logic gets tuned, feedstock changes, a line is rebalanced. A twin validated once is accurate for a season, no longer. Build revalidation into the digital twin development operating model from day one: a scheduled comparison of predicted against actual, a drift threshold, and a named person whose job it is to retrain when the threshold trips.
| Step | Named output | Typical duration | Who owns it |
|---|---|---|---|
| 1. Name the decision | One-page decision brief | 1 to 2 weeks | Operations lead |
| 2. Fix fidelity and frequency | Synchronisation contract | 1 week | Solution architect |
| 3. Audit the data | Gap list and asset register | 4 to 6 weeks | Data engineering |
| 4. Build and validate the model | Hold-out validation report | 6 to 12 weeks | Modelling team |
| 5. Decide the control boundary | Safety case and override log | 2 to 4 weeks | Engineering and safety |
| 6. Continuous revalidation | Drift policy and owner | Ongoing | Named twin owner |
Fidelity and Frequency: The Two Dials That Set Your Digital Twin Development Budget
These two numbers deserve their own section because almost every runaway cloud bill in digital twin development traces back to one of them being set by default rather than by argument.
Frequency is a digital twin development cost multiplier, not a feature
Take a plausible estate: 500 assets, 20 signals each. At one reading per minute that is 500 × 20 × 60 × 24 × 30 = 432 million messages a month. At UK South list pricing of $1.25 per million, the messages meter alone comes to $540 a month.
Now raise the rate. One reading every ten seconds multiplies that by six: 2.59 billion messages, $3,240 a month. One reading per second multiplies it by sixty: 25.9 billion messages, $32,400 a month — nearly $389,000 a year on a single meter, for a change most stakeholders would wave through as a detail. One dial can move a digital twin development budget by more than the entire build.
Sample at the rate of the physics, not the rate of the sensor
The discipline is simple: sample at the rate the physical process changes, not the rate the sensor is capable of. A building’s thermal mass does not need per-second telemetry. A vibration signature on a high-speed spindle does. Mixed-rate architectures — fast local processing with aggregated state promoted to the cloud twin — are the standard answer, and they routinely cut the platform bill by an order of magnitude.
Fidelity should be argued down, not up
Fidelity has the same dynamic. Every increment costs compute, calibration effort and validation time, and the honest question is always what decision changes at the higher fidelity. If the answer is “none”, you have found budget. Good digital twin development is largely the practice of defending the lowest fidelity that still supports the decision from step one.
What Digital Twin Development Actually Costs
Published platform rates are the easy part of a digital twin development estimate. The rest is people, and the four lines below are the ones that get left out of first-draft business cases.
The four digital twin development cost lines nobody quotes for
First, instrumentation retrofit: sensors, gateways, installation windows and the production time lost to fitting them. Second, data remediation: cleaning tags, reconciling asset IDs, backfilling history. Third, validation: the hold-out testing and the revalidation cadence. Fourth, the twin owner — a permanent role, not a project role, because an unowned twin decays within a year.
None of these appear on a platform pricing page, and together they usually exceed the platform spend by a wide margin over five years.
A worked five-year digital twin development example
Assume a mid-sized manufacturer, one production line, the 500-asset estate above at one-minute sampling. Take a year-one build of $280,000 broken into discovery $25,000, data engineering $90,000, modelling $75,000, integration $60,000 and visualisation $30,000. Add cloud and platform running costs of $90,000 a year, covering ingestion, storage, compute and the twin service itself. Then add $110,000 a year from year two for run, enhancement and revalidation.
Over five years that totals $1,170,000. It is a real number for a real programme, and it is the number a serious digital twin development proposal should put in front of a board rather than a licence figure that represents a fraction of the truth.
| Cost line | Year 1 | Years 2 to 5, each | Five-year total |
|---|---|---|---|
| Build: discovery, data, modelling, integration, UI | $280,000 | — | $280,000 |
| Cloud and platform running costs | $90,000 | $90,000 | $450,000 |
| Run, enhancement and revalidation | — | $110,000 | $440,000 |
| Total | $370,000 | $200,000 | $1,170,000 |
Does it pay back?
Avoided downtime alone rarely closes that gap. On a line where an unplanned stop costs $50,000 a day, preventing two days a year returns $100,000 annually, or $500,000 over five years — well short of $1.17 million. The twins that pay back stack several returns: downtime, throughput, yield, energy, and deferred capital from running existing assets longer.
That is why step one matters so much. A twin built to support one decision has one return line and usually fails the business case; a twin built on a shared asset model can support several, and the second and third use cases are dramatically cheaper than the first.
The Market Context Behind Your Digital Twin Development Business Case
Boards ask whether this is a real market or a cycle. The honest answer is that it is real, growing fast, and forecast with a spread wide enough to be worth understanding.
Analyst forecasts agree on direction, not on magnitude
For 2026 the published estimates range from roughly $31.83 billion (Research Nester) to $49.5 billion (Grand View Research), with Fortune Business Insights at $33.97 billion, Precedence Research at $38.26 billion, Straits Research at $39.12 billion, The Business Research Company at $39.75 billion and Mordor Intelligence at $49.2 billion. Growth rates cluster between 31% and 39% a year.
A 55% spread between the lowest and highest estimate for the same year tells you the category boundary is contested — some houses count only twin-specific software, others count the surrounding stack. Use the direction, not the decimal places.
Adoption is past the experimental phase
IoT Analytics found that 29% of global manufacturing companies had fully or partially implemented a twin strategy, up from 20% in 2020, while the share not even contemplating one collapsed from 33.6% to 9%. Gartner expects more than 40% of large companies globally to be using twins in revenue-focused projects by 2027.
The Capgemini Research Institute, surveying over 1,000 organisations, reported around 15% improvement in key sales and operational metrics, gains upwards of 25% in system performance, and an average 16% improvement in sustainability metrics among adopters, with implementations set to grow 36% on average over five years.
Composition is the next phase
Both the standards bodies and the analysts are pointing the same way. ISO published a composition standard in 2026, Gartner names composite twins as the largest opportunity in the category, and 61% of companies that have implemented twins have already connected at least one pair together. Design your asset model on the assumption that this twin will one day be a component of a larger one.
Where Digital Twin Development Projects Fail
Failure rates quoted in this market vary wildly and most trace back to a single unsourced slide. Rather than repeat them, here are four digital twin development failure modes we can describe mechanically, because each has a specific and preventable cause.
Failure 1: no decision owner
The twin is commissioned by a technology function and delivered to an operations function that never asked for it. Nobody’s targets move when the twin is right, so nobody changes behaviour when it speaks. Prevented by step one, and by nothing else.
Failure 2: the pilot asset was the easy one
Teams pilot on the newest, best-instrumented, most-documented asset because it will succeed. It does succeed, and the result generalises to nothing. Pilot on a representative asset — ideally the second-worst instrumented one you intend to cover — and the estimate for the rollout will actually mean something.
Failure 3: model drift with no revalidation
The model was accurate at handover and nobody checked again. Twelve months later it is confidently wrong, and the first person to notice is the one whose decision it broke. Prevented by step six: a drift threshold, a schedule, and a name against it.
Failure 4: the data contract was never written
The twin depends on a field in someone else’s system. That team refactors, the field changes meaning, and no contract existed to stop them. Every cross-system dependency in a digital twin development programme needs an explicit, versioned data contract with a change-notice obligation.
| Failure mode | Symptom | Preventive control |
|---|---|---|
| No decision owner | Twin is admired, never used | One-page decision brief signed by operations |
| Unrepresentative pilot asset | Rollout costs 4x the pilot | Pilot a deliberately average asset |
| Model drift | Accuracy decays silently after handover | Drift threshold, schedule and named owner |
| Missing data contract | Upstream change breaks the twin | Versioned contract plus change notice |
| Visualisation-first sequencing | Scene rebuilt after data model corrected | Prove the asset model before authoring scenes |
Build vs Buy in Digital Twin Development
The binary framing is unhelpful in digital twin development, as it is in most platform decisions. The useful split is by layer.
What to buy in digital twin development
Buy the commodity layers: ingestion, time-series storage, the graph or entity store, the renderer, and the physics engine. These are mature, competitively priced, and rebuilding any of them is a decision to spend a year arriving where you could have started. NVIDIA’s move to a free Omniverse licence has made the visualisation layer, in particular, indefensible to build.
What to build
Build the model of your process and the ontology of your estate. Those encode how your business actually works and no vendor default will express them. This is the part of digital twin development that is genuinely yours, and it is also the part that keeps its value if you change platform later.
The seam is the digital twin development project
The work that determines success is neither the bought layer nor the built layer but the seam between them: the contracts, the identifier mapping, the update semantics, the failure behaviour. Budget for the seam explicitly. Teams that treat integration as a residual line item are the ones that discover in month seven that their digital twin development schedule was fiction.
Governance, Security and the Gemini Principles
A twin is a complete, machine-readable description of how your operation works. That is exactly as sensitive as it sounds, so digital twin development deserves governance proportionate to that value.
The Gemini Principles as a digital twin development checklist
Published in December 2018 by the Centre for Digital Built Britain, the Gemini Principles set out nine values for built-environment twins across three groups: purpose (public good, value creation, insight), trust (security, openness, quality) and function (federation, curation, evolution). CDBB itself closed in September 2022, but the document remains the most usable governance checklist in the field and travels well beyond infrastructure.
Run any proposed digital twin development against all nine before build. The questions it forces — who does this serve, is it secure, can it federate, who curates it, how does it evolve — are precisely the ones that go unasked in a vendor-led process.
Security: a twin is a blueprint of your operation
Treat the twin as crown-jewel data. It reveals capacity, bottlenecks, maintenance windows and control logic in one place, and if it is closed-loop it is also a path into operational technology. That means segmentation between IT and OT, strict least privilege on write operations, an immutable audit log of every commanded change, and a tested answer to what the asset does when the twin is unavailable.
Our IT security page covers the segmentation model, and the same discipline you would apply to any digital transformation programme applies here with the volume turned up.
A 90-Day Digital Twin Development Plan
If you want to start without committing to a multi-year programme, this is a defensible first quarter. It produces a validated model, a costed rollout estimate, and a genuine go or no-go — not a demo.
| Window | Focus | Deliverable at the end |
|---|---|---|
| Days 1 to 15 | Name the decision, pick a representative asset | Decision brief and synchronisation contract |
| Days 16 to 45 | Data audit, asset register, tag dictionary | Gap list with costed remediation |
| Days 46 to 75 | Build the model, score against a hold-out period | Validation report with error bounds |
| Days 76 to 90 | Shadow deployment and rollout estimate | Running shadow plus five-year cost model |
What “no-go” should look like
A quarter that ends in a decision not to proceed is a good outcome, not a failure, provided it ends with the asset register, the tag dictionary and the validated understanding of what your data can and cannot support. Those artefacts pay for themselves in reporting and compliance whether or not the twin is ever built.
Frequently Asked Questions About Digital Twin Development
How long does digital twin development take?
A first production-grade twin of a single asset class typically takes six to twelve months from decision brief to validated shadow deployment, with the data work dominating. Subsequent asset classes on the same model are dramatically faster, often six to ten weeks, which is why the second twin is where the return usually appears.
Do we need IoT sensors in place before we start?
Not entirely, but you need enough observability to validate the model. Many digital twin development programmes start with what the historian already holds, identify the specific gaps that block the target decision, and retrofit only those. That is far cheaper than a blanket instrumentation project and it produces a defensible sensor shortlist.
Can a smaller manufacturer justify digital twin development?
Sometimes, provided the scope is a single high-value decision rather than a site-wide twin. The cost floor has fallen — Omniverse is now free, cloud twin services bill by consumption with no minimum, and open components cover most of the stack. The floor that has not fallen is the data work, which is why smaller operators do best starting with a shadow of one critical asset.
What team does digital twin development need?
At minimum: a domain engineer who understands the asset, a data engineer who owns the pipeline, a modeller comfortable with both physics and machine learning, and a named twin owner in the business. The visualisation specialist most teams hire first is genuinely the last of the five you need.
How is a twin different from simulations we already run?
Your existing simulation runs against assumed inputs to answer a design question. A twin runs against this asset’s live inputs to answer an operating question. If you already have validated simulation models, you are further along than most — the remaining work is the synchronisation layer, not the physics.
What happens if we pick the wrong platform?
Less than you fear, if you built the ontology and the model as your own assets rather than as platform configuration. Portability in digital twin development comes from owning the semantic layer, which is the strongest practical argument for the build-vs-buy split described above.
Where to Start
If you are weighing this up, do not start with a platform trial. Start with one page naming a decision, a specified frequency and fidelity, and an honest look at whether your data can support either. That page costs a fortnight and it is the single best predictor of whether the digital twin development programme that follows succeeds.
When you are ready to scope the build, our team works on exactly this seam between operational data and useful software — see our custom software development capability, or get in touch to talk through the first ninety days.
References and Further Reading
Digital Twin Consortium: Definition of a Digital Twin
ISO 23247-1:2021 Digital twin framework for manufacturing, Part 1
ISO 23247-5:2026 Digital thread for digital twin
ISO 23247-6:2026 Digital twin composition
NIST: An Analysis of the New ISO 23247 Series of Standards
IEC 63278-1:2023 Asset Administration Shell for industrial applications
IDTA: Specification of the Asset Administration Shell, Part 1 Metamodel
Microsoft: Azure Digital Twins pricing
Microsoft Learn: Query Units in Azure Digital Twins
Amazon Web Services: AWS IoT TwinMaker pricing
Centre for Digital Built Britain: The Gemini Principles
Capgemini Research Institute: Digital Twins, Adding Intelligence to the Real World
IoT Analytics: Digital twin market, analysing growth and emerging trends
Grand View Research: Digital Twin Market Size and Share Report
Precedence Research: Digital Twin Market Size
Engineering Automotive Digital Twins on Standardized Architectures: A Case Study