Digital twin software
Start with the decision, data and model you already have. Compare eight active platforms by documented boundary, build a requirements shortlist, then give every supplier the same eight evidence tests.
Build a requirements shortlist
This rule-based map compares stated requirements with the documented platform types below. It does not measure vendor performance or select a market-wide winner.
Eight platform boundaries to verify
Unknowns stay visible. A listed capability is documentation evidence, not observed accuracy, uptime, savings or deployment success.
| Platform | Type and data | Prerequisite | Verification |
|---|---|---|---|
| Cognite Data FusionCognite | Industrial data foundation Contextualises industrial time series, engineering models and documents for applications and twins. | A data team must connect and contextualise source systems; this is not a turnkey asset model. Data-rich industrial assets and processes | Documented APIs and SDKs; connector support must be checked against the buyer's exact systems. Official sourcesCognite Data Fusion documentation |
| Velotic ProficyVelotic (formerly GE Vernova) | Manufacturing operations stack HMI/SCADA, MES, industrial data management and analytics portfolio. | Confirm the exact Proficy modules, connectors and licences in the proposed architecture. Discrete, process and hybrid manufacturing | Not confirmed in the reviewed sources; request the current API and connector matrix. |
| Velotic ThingWorx and KepwareVelotic (formerly PTC) | Industrial IoT application platform Industrial connectivity plus an application platform for connected operations. | Verify the current post-divestiture product boundary and every required protocol in the RFI. Connected equipment and industrial applications | Kepware is the connectivity layer; the current post-divestiture integration contract must be confirmed. Official sourcesVelotic company and portfolio |
| Siemens Insights HubSiemens | Industrial IoT service Connects industrial assets to cloud and edge applications through the Insights Hub ecosystem. | Map the plant's connectivity, tenancy, data-volume and edge requirements before selecting a package. Industrial equipment and Siemens-connected operations | Developer APIs are documented; exact device and protocol support belongs in the pilot record. |
| Bentley iTwinBentley Systems | Engineering and lifecycle twin Combines engineering, reality and operational data around infrastructure and industrial assets. | An engineering-model or reality-data pipeline is normally the starting point. Infrastructure and complex engineered assets | Bentley documents iTwin APIs; test import, change tracking and export with the buyer's real model. |
| Ansys Twin BuilderAnsys, part of Synopsys | Physics-based twin builder Builds system-level, reduced-order and hybrid twins from simulation models and operating data. | A suitable physics or system model and modelling expertise are required for the reviewed route. Equipment and systems where physics models are available | The product page documents model and deployment workflows; verify the exact FMI/FMU path for the planned version. Official sourcesAnsys Twin Builder |
| Azure Digital TwinsMicrosoft | Twin graph platform Models connected environments as a graph using DTDL and Azure APIs. | A development team must define models, ingestion and applications; this is not a packaged plant twin. Custom connected environments on Azure | DTDL models plus documented REST APIs and SDKs. |
| AWS IoT TwinMakerAmazon Web Services | Cloud twin application service Builds twin applications from existing data sources and visual models without creating another data store. | An AWS architecture and application work are required; confirm region, service and data-access costs. Custom industrial and building twin applications on AWS | AWS documents connectors and unified data-access APIs; test every required source and export path. |
A requirements map, not a leaderboard
Eight tests for one real-asset pilot
Write your acceptance criterion before the supplier runs the test. The worksheet intentionally leaves limits blank because update rate, latency, tolerance and operator time depend on the plant and decision.
1. Data ingestion
Connect one approved real source and record tag discovery, timestamp handling, units and update behaviour.
Keep: Source configuration, sample export, gaps, unit mapping and buyer-defined acceptance criterion.
2. Model creation
Build the smallest useful model of one real asset or process using the buyer's own data or engineering model.
Keep: Model version, source files, mapping decisions, build effort and buyer-defined state tolerance.
3. Known-event replay
Replay one permitted historical operating event and one clean comparison period.
Keep: Frozen input window, expected observation, actual output, unresolved differences and adjudicator.
4. System integration
Exchange one agreed asset or work-context record with the target CMMS, historian, ERP or data platform.
Keep: Field map, direction, timestamps, failed records, retries and exported transaction log.
5. Edge and network boundary
Run the planned edge or gateway route inside the approved network boundary.
Keep: Ports, components, buffering behaviour, measured latency range and buyer-defined limit.
6. Export and portability
Request a complete export of the pilot's models, data, configuration and audit history.
Keep: Formats, API endpoints, omissions, licence constraints and re-import result.
7. Operator decision
Give a named role one representative decision using only the pilot interface and approved instructions.
Keep: Task, completion record, questions, corrections and buyer-defined usability criterion.
8. Quoted scope
Reconcile the architecture and pilot usage against an itemised supplier quote.
Keep: Licences, connectors, storage, data volume, environments, support, services and excluded costs.
Inzonex Engineering Learning
Learn to scope a digital-twin pilot
Learning outcomes
- Distinguish data-foundation, IoT, engineering-lifecycle, physics and cloud twin platforms by prerequisites.
- Separate a source-backed product field from an unverified procurement assumption.
- Write a reproducible pilot record with buyer-defined acceptance criteria.
Worked example
A process plant has a historian, mixed controls and no physics model. It needs one operating view for a heat exchanger. Select monitor, industrial historian, cloud plus edge and no physics model. The map surfaces data and IoT foundations, while the pilot tests whether the real tag, timestamp, unit and export boundary works. It does not declare that the first result is the best product.
Exercise 1: change the starting asset
Switch the requirement to an infrastructure asset with an existing CAD/BIM model. Record which platform type moves into the shortlist and which model-import evidence you would keep.
Answer
An engineering-lifecycle platform should move up because the existing design model is now a prerequisite match. Keep the imported model version, rejected objects, mapping decisions and a complete export.
Exercise 2: challenge an unknown
Find a table field that says it must be confirmed. Turn that sentence into a vendor question and name the file or log that would answer it.
Answer
For Proficy APIs, request the current API and connector matrix for the quoted modules, then keep the document version and a transaction log from the integration test.
Keep adjacent questions on their canonical pages
Digital-twin guide explains the concept and maturity levels. Digital twin vs simulation owns the definition comparison. The glossary gives the short answer. The manufacturing report owns adoption and market evidence.
Questions buyers ask
What is the best digital twin software for a factory?
There is no universal winner. Start with the decision, existing data and models, deployment boundary and required export. The selector maps those requirements to documented platform types; the pilot worksheet then tests the shortlist on one real asset.
Do I need a physics model for a digital twin?
Only for a physics-based route such as the Twin Builder workflow reviewed here. Data-platform, IoT and lifecycle twins can start from connected operating or engineering data, but still require a defined model and decision.
Is digital twin software the same as simulation software?
No. A simulation can run offline without a live physical counterpart. A digital twin maintains a connection to a specific asset or process. The linked comparison page owns the detailed definition.
How should a digital twin pilot be evaluated?
Freeze one asset, one decision, permitted inputs and buyer-written acceptance criteria. Keep ingestion, model, event, integration, network, export, operator and quoted-scope evidence so another reviewer can reproduce the decision.
Methodology, citation and reuse
Eight active digital-twin platforms reviewed from official product, developer or transaction sources. This is a requirements map, not a performance ranking. Product boundaries change: Velotic now brings together Proficy, ThingWorx and Kepware. Confirm the exact edition, region, connectors, hosting and licence in the supplier response.
Cite this page for the source-linked requirements matrix or reuse the original CSV, worksheet and chart under CC BY 4.0 with attribution to Inzonex. Vendor documentation and trademarks retain their own rights. Inzonex has no listed-vendor affiliation.
Suggested citation: Inzonex (2026), Digital twin software: requirements map and pilot worksheet, 29 August 2026, inzonex.co.uk/ai/category/digital-twin.