When a manufacturer tells us they want to explore a digital twin, the thing they actually have in mind often turns out to be a dashboard that shows equipment status on a 3D screen. The opposite happens too. Some plants already collect equipment data through IoT and display it on a monitor, so they describe themselves as already running a digital twin. Neither view is entirely wrong, but the gap between the two is an order of magnitude in investment and, in terms of the operating structure required, almost a different conversation altogether. This article works through what a digital twin actually means for a factory, how it differs from plain visualization, what it costs to implement, and where a Japanese-affiliated plant in Thailand should realistically begin in 2026.
What Is a Digital Twin
In a single sentence, a digital twin is a mechanism that continuously mirrors the state of real equipment, processes, or products into a digital space, and feeds what you try out on that mirror back to the physical side. The two words that carry the weight are “continuously” and “feeds back.” Anything missing either of them is hard to call a digital twin.
The international standards language lands in almost the same place. ISO 23247, the international standard for digital twins in manufacturing, functionally defines a digital twin as a model that describes the current state of products, processes, and resources, and it assumes a state in which the physical elements and their digital representations stay synchronized. In other words, being about the current state, and being synchronized, are the requirements.
The Difference from a Visualization Dashboard Is the Direction of Time
The equipment monitoring dashboards commonly used on factory floors deal fundamentally with the past and the present. Is this machine running right now? How many units have we produced today? How many minor stoppages occurred over the last week? Every one of those is a record of something that has already happened.
What a digital twin adds is a forward-facing time axis. Given the current state of the equipment and the current order book, how many hours would we save if we changed the changeover sequence like this? If we take one machine in this process offline, when does downstream inventory run dry? If we keep running under these conditions, how far will bearing degradation progress? Being able to test things that have not happened yet, without stopping the real line, is where the value of a digital twin sits.
It follows that whether the screen is 3D or not is beside the point. You can have a 3D factory model spinning on a monitor, but if all it shows is present values, that is a visually elaborate dashboard. Conversely, a plain 2D set of tables and charts that lets you change conditions inside the model and compute what happens next is much closer to meeting the definition.
The Difference from BIM Is Whether It Moves
Some plants already hold BIM or 3D CAD models built for building design or equipment layout studies. It is tempting to conclude that having a 3D model means you are halfway to a digital twin, but this distinction needs to be drawn carefully.
BIM and 3D CAD models are, as a rule, static geometry captured at design time. Beam positions, pipe routing, equipment dimensions and installation coordinates. These barely change once the plant is built. A digital twin, by contrast, deals with the state that shifts moment to moment inside that geometry. Which operating mode is this machine in right now? How many workpieces are sitting on this conveyor line at this instant? How much power is this air conditioning unit drawing?
BIM is an extremely useful starting point, because it spares you the effort of building 3D geometry from scratch. But having BIM only means the vessel exists. The real-time data poured into that vessel, and the logic that uses that data to compute what comes next, still have to be built separately. Confusing the two is how a cost estimate ends up at a fraction of the real number.
The Difference from a One-Off Simulation Is Whether Synchronization Continues
The other easily confused item is the production simulation run during line commissioning. Plenty of plants have experience building a model in simulation software to study a new line layout or verify takt time.
The difference here is whether the model is built once and abandoned. A commissioning simulation is assembled from the design values available at that moment, and its job ends when verification is complete. If part of the line is modified six months later, the model is not updated. Over time the model and the physical plant drift apart, and eventually nobody refers to it any more.
A digital twin is a mechanism that refuses to allow that drift. When the physical asset changes, the model follows. Operating data keeps flowing in, and the model’s parameters are corrected against reality. That continued synchronization is the decisive line between a one-off simulation and a digital twin, and it is also exactly why operating costs keep accruing.
Three Questions for a Self-Diagnosis
Whether what your company is considering is a digital twin or a sophisticated visualization can usually be settled with three questions.
- Does the model follow changes in the physical asset automatically, or does a person update it by hand?
- Can you test conditions on that model that you have not actually executed, and predict the outcome?
- Is there a path for feeding the resulting answer back into shop floor instructions or equipment settings?
Answer yes to all three and you have a digital twin. Yes to only the first is real-time visualization. Yes to only the second is offline simulation. And frankly, for a great many factories, the first one alone already pays for itself. We come back to that judgment later in this article.
Why Factory Digital Twins Are Drawing Attention in 2026
The term digital twin has been around for more than a decade. Two developments explain why it has suddenly become a realistic subject for evaluation in 2026, one on the market side and one on the standards side.
Market Growth Is at an Outlier Level
According to the Digital Twin in Manufacturing Market Report 2026 published by Research and Markets, the manufacturing digital twin market stood at 28.91 billion US dollars in 2025, is expanding to 47.24 billion US dollars in 2026, and is forecast to reach 328.29 billion US dollars by 2030. The compound annual growth rate is put at 62.4 percent.
You cannot plug those figures directly into your own investment case, but directionally they suggest two things. First, the range of software and services on offer is about to expand rapidly, which makes it likely that pricing becomes relatively more reasonable. Second, and conversely, this is still an early phase in which products get replaced and vendors get consolidated. The practical reading is that it is worth designing your implementation so as to avoid long-term lock-in.
ISO 23247 Has Given Everyone a Common Language
Technically, the more important development is standardization. ISO 23247 is the international standard for a digital twin framework for manufacturing, and it defines a general-purpose reference architecture that does not depend on any particular vendor’s product. NIST in the United States has also published an analysis of the series.
The structure breaks down as follows.
| Part | Content | What it means in practice |
|---|---|---|
| Part 1 | Overview | Aligns terminology and scope |
| Part 2 | Reference architecture | A map of which functional blocks you need |
| Part 3 | Digital representation of manufacturing elements | How to describe equipment and processes |
| Part 4 | Information exchange and communication protocols | How to connect to existing equipment |
| Part 5 | Digital thread for digital twins | Linking data across the lifecycle |
| Part 6 | Digital twin composition | How to combine multiple twins |
Part 5 and Part 6 are additions published by ISO in 2026. Part 5 covers the digital thread, that is, how data is linked across the stages of the product lifecycle. It responds to the problem that leaving design information, production results, and post-shipment operating data sitting in separate silos cuts the value of a digital twin in half.
Part 6, on digital twin composition, is closer still to practical work. It organizes the ways multiple digital twins can be combined into three approaches, integrated, unified, and federated. Translated into factory reality, this means the design choices around how you bundle machine-level twins into a line-level twin, and how you bundle site-level twins into a company-wide one, can now be discussed in standardized language. We covered the multi-site angle separately in how to unify production management across multiple sites and compare KPIs in 2026, and where digital twins span several sites, the Part 6 classification gives that discussion its foundation.
The practical effect of having a standard is unglamorous but substantial. When you compare vendor proposals, you can ask all of them the same question with the same yardstick, namely which parts of ISO 23247 their architecture addresses. The familiar situation where every proposal is formatted differently and none of them can be compared side by side improves at least somewhat.
Understanding the Technical Structure in Three Layers
To read a digital twin quotation or proposal properly, it helps to split the whole thing into three layers. Which of these three layers a proposal actually covers changes both the cost and the difficulty completely.
Layer 1 – Data Collection
At the bottom sits the layer that draws state information out of the physical asset. Signals from PLCs and CNCs, retrofitted vibration and current sensors, temperature and humidity sensors, image sensors, and the actual production records held in a production management system or MES. All of these are inputs.
The practical problem plants run into here is that existing equipment spans many different vintages. Machines installed in recent years have communication interfaces. A twenty-year veteran has no port to pull a signal from. In that case you have to decide whether to substitute a retrofit sensor, infer state from the power waveform, or simply leave that machine outside the scope of the twin.
More troublesome still is the case where data can be collected but its meaning is inconsistent. Take the same field labeled “units produced.” Machine A’s counter does not distinguish good units from defects, while machine B’s counter only counts good units after inspection. Feed that into a single model and the model will go on quietly producing wrong answers.
Layer 2 – 3D Model and Simulation
In the middle sits the layer that receives the collected data and reproduces reality. 3D geometry models, logical process models, and physics computation models all live here.
What determines the cost of this layer is the fidelity you require. Is it enough to know equipment placement and running state? Do you need to reproduce workpiece flow and buffer accumulation? Or do you need to compute physical phenomena such as heat, fluid behavior, and stress? Each step up in fidelity sharply increases both the effort to build the model and the compute resources it needs.
The common failure in practice is aiming for high fidelity from day one. The thinking goes, if we are doing this at all, let us go all the way to physics. The result is a model that takes more than a year to build, by which time the shop floor has lost interest. Fidelity should be worked backwards from the objective. If all you want is to optimize changeover sequencing, physics simulation is unnecessary.
Layer 3 – AI and Decision Making
At the top sits the layer that turns model output into decisions. Automatically testing large numbers of conditions to find the optimum, detecting early signs of abnormality, and combining demand forecasts to rebuild a plan all belong here.
This layer overlaps with the territory of automated production planning. In fact, some AI-based production planning systems embed digital twin style simulation as a way to validate a candidate plan before it is executed. We laid out how that works in what production planning AI is, with implementation results, costs, and rollout steps for Thai factories. In that setup, the primary purpose is producing the plan, and simulation is the means of validating it.
The digital twin discussed in this article is the opposite configuration, where the simulation platform itself is the primary purpose. The functionality can look identical while the scale of investment and the breadth of application differ. If planning accuracy is your only issue, adopting a planning system with built-in simulation may well be faster and cheaper than building a full-scale digital twin.
Your Next Move Depends on Which Layer Is Weakest
The biggest benefit of thinking in three layers is that it lets you identify which layer your own weakness sits in. A plant with a weak data collection layer that jumps straight to Layer 3 AI optimization cannot trust the output, because it cannot trust the input. Conversely, a plant whose data collection layer is already in good shape will find investment in Layers 2 and 3 comparatively light.
What Implementation Costs
Before getting into numbers, one caveat. The figures below are general cost ranges aggregated from overseas vendor materials and analyst cost guides. As far as our research went, no primary published data exists for digital twin implementation pricing specific to Thailand. Treat the numbers as a sense of the market to hold in your head while reading a proposal, not as something that will match an actual Thai quotation. Labor cost levels and the share of locally sourced work will move the real figure up or down.
The Four Cost Components
Digital twin costs break down into four broad components.
| Cost component | Typical range | Nature |
|---|---|---|
| Platform license | 50,000 to 300,000 US dollars per year | Recurring |
| Data integration and middleware | 30,000 to 200,000 US dollars | Initial |
| 3D model and simulation build | 40,000 to 400,000 US dollars | Initial |
| Cloud and compute resources | 10,000 to 150,000 US dollars per year | Recurring |
The platform license is the annual cost of using an enterprise digital twin foundation such as Siemens, PTC, or Microsoft Azure Digital Twins. The wide band on data integration exists because it is entirely governed by the vintage of your existing equipment and how consistent its communication specifications are. The band on 3D model construction is wider still because the fidelity differences described above map straight onto it.
These four components look like an independent stack, but in reality they influence one another. The easiest one to miss is that raising the fidelity of the 3D model and simulation layer drives up the compute resources you need along with it. The moment you choose a high-precision model, you raise not only the initial cost but the annual cloud bill. Cutting the platform license, on the other hand, barely reduces the data integration effort at all. Establish which parts of the total move when you cut which layer, while you are still at the proposal stage.
Total Cost by Scale
Combining those components, total cost by scale sorts out roughly as follows.
Stage 1 is a twin at the level of a single machine. If you narrow the scope to one specific asset, say a key machining center or a compressor, and handle only its behavior and degradation prediction, there are cases where this can be built for under 100,000 US dollars. Because the scope is narrow, the data integration surface is limited too, and the 3D model covers only one machine. As a first step, this stage is the realistic one.
Stage 2 is a twin at the level of a single line or a single plant. For a target of one line or one facility at moderate complexity, the generally cited ranges are 500,000 to 2 million US dollars in initial cost and 100,000 to 400,000 US dollars per year in operating cost. The reason this is an order of magnitude above Stage 1 is the increased data integration effort from covering more equipment, plus the complexity of modeling the interactions between machines.
Stage 3 is deploying a platform as an enterprise foundation. Here multiple sites or multiple lines sit on a shared foundation, the platform license moves toward the upper end of the range given above, and implementation cost for each site is layered on top. The total swings so widely with scope that quoting a single range for it means very little.
Entity-Based Pricing as a Mental Model
A useful reference for understanding the cost structure is the entity-tier pricing used by AWS IoT TwinMaker. Tiers are divided by the number of components managed inside the digital twin, with Tier 1 covering 1 to 1,000 entities and Tier 4 covering 10,001 to 20,000 entities.
What this pricing model reveals is that digital twin cost is not determined by floor area or machine count, but by the number of elements you model. The Tier 1 band corresponds to a pilot or a small site. Put the other way round, the moment you try to model every element in an entire factory, entity counts balloon and the cost tier jumps with them.
Knowing this structure lets you see scope narrowing not as a trick for keeping the bill down, but as a rational response to how the costs are actually built.
Costs That Rarely Appear in a Quote
Some costs are frequently absent from the number in a proposal and bite later.
- Model maintenance. Every line modification or equipment replacement generates effort to update the model. Neglect it and the model drifts from the physical plant, wasting the investment.
- Network infrastructure upgrades. Continuous data transmission from sensors can put the existing factory network under strain.
- Internal operator headcount. Someone has to keep verifying that the model is still valid.
- Data quality remediation effort. As discussed below, this tends to account for a larger share of the total than expected.
Where Thailand and ASEAN Stand Today
The Major Industrial Groups Are Already Moving
The most prominent confirmed digital twin development in Thailand is the MOU that Toyota Motor Corporation signed on 20 December 2023 with Charoen Pokphand Group (CP), True Leasing (TLS), Siam Cement Group (SCG), and Commercial Japan Partnership Technologies (CJPT).
The collaboration is aimed at accelerating carbon neutrality efforts in Thailand, and within it the parties explicitly set out a direction of using the retail and logistics data held by CP and SCG together with Toyota’s digital twin technology to optimize the flow of people, goods, and energy.
This needs to be understood precisely. It is not a digital twin case study covering the production line of a single factory. It is a cross-industry initiative targeting wide-area logistics and energy flows. Citing it as an example of Toyota running a production line digital twin in Thailand would be incorrect.
Even so, the fact it demonstrates matters. Thailand’s leading industrial groups and a Japanese manufacturer with operations in Thailand have reached the point of signing a concrete collaboration agreement around digital twin technology. In Thailand, in other words, the digital twin is no longer a future research topic. It has become the subject of large-scale investment decisions.
AI Adoption Is Rising but the Foundation Still Has Gaps
At the same time, Thailand’s digital foundation has a clear weak point overall. The AWS-commissioned study Unlocking Thailand’s AI Potential 2026 found that 43 percent of Thai companies use AI on an ongoing basis, up from 32 percent the previous year. More than ten points of growth in a single year is not a small movement.
Yet at the same time, according to Bangkok Post reporting, roughly 65 percent of manufacturing organizations in Thailand cite concerns about data quality and a lack of infrastructure as barriers to adopting AI and advanced analytics.
These two figures come from surveys with different scopes. The 43 percent covers Thai companies generally, while the 65 percent covers manufacturing organizations. Read side by side even so, the broad picture emerges. Companies are steadily starting to use AI. But on the data quality and infrastructure underneath it, roughly two in three manufacturing organizations report a problem.
Poor Data Quality Is Fatal for a Digital Twin
It is worth digging a little further into why this concern about data quality is so decisive specifically when evaluating a digital twin.
With an ordinary visualization dashboard, some missing data or a slightly skewed value does limited damage. A human looking at the chart notices that a given day looks odd, checks with the shop floor, and corrects it. Human common sense functions as a filter.
With a digital twin, that filter does not operate. A digital twin takes incoming data as its premise, reproduces reality on that basis, and computes the future on top of the reproduction. If the input contains a systematic error, that error is absorbed into the reproduction model and propagates straight through to the predictions derived from it. Worse, the output is presented in forms such as an optimized changeover sequence or a failure probability three weeks out, which makes it hard for a human to spot the error by intuition.
Worse still, a digital twin’s answers arrive looking persuasive. A simulation result gliding smoothly across a 3D screen is easier to believe than a number in Excel. You end up in a situation where a wrong conclusion built on wrong inputs travels down to the shop floor carrying more conviction than it deserves.
For that reason, when a Thai plant evaluates a digital twin, the first job is not building a model. It is taking stock of the data. Which data comes from which machine, under which definition, at which frequency, and with what rate of missing values? Projects that skip this check almost invariably stall partway through model construction. The 65 percent figure describes barriers to AI and advanced analytics in general, but among those applications a digital twin is one of the most sensitive to data quality. It is reasonable to assume that a fair number of plants in Thailand should build this verification work into their plan.
What to Check Before You Start and Where Projects Fail
Failure Pattern 1 – Building the Model Without a Data Foundation
This is the most common failure. Because a 3D model looks impressive at the proposal stage, model construction tends to run ahead of everything else. But as described in the previous section, a digital twin’s accuracy never exceeds the quality of its input data.
The countermeasure is simple. Place an assessment of the current state of the data collection layer as an independent phase before model construction. Then build the time needed to close the gaps and definition mismatches it uncovers into the project plan from the outset. A plan that does not allow for that period will almost certainly slip.
Failure Pattern 2 – Targeting the Whole Factory at Once
The instinct to cover the entire plant since you are doing this anyway is, viewed through the cost structure, the most expensive choice available. As noted in the discussion of entity pricing, cost jumps as the number of modeled elements grows. On top of that, the broader the scope, the greater the variation in data quality, and something will jam somewhere.
The realistic approach is to start with one bottleneck process, or one machine whose failure has an outsized impact. This mirrors the thinking we set out in how to run an IoT PoC in 2026 by defining the exit criteria before you start, and the point about defining exit criteria before you begin applies equally to digital twins. What has to happen before you roll out to the next machine, and conversely what failure to meet triggers a withdrawal, should be written down on paper before work starts.
Failure Pattern 3 – Leaving System Integration Until Later
A digital twin does not function in isolation. Only when it receives plan information from the production management system, actuals from the MES, and state from the equipment can it produce a meaningful reproduction.
Yet this integration work tends to be treated lightly in proposals. If you see a quotation that dispatches it with a single line reading “API integration with existing systems,” always ask how many person-months that one line represents. Connecting control-side OT to information-side IT has its own particular difficulties, and their structure is essentially the three walls covered in what OT and IT convergence means in 2026, the three walls that block integration in factories, and how to work through them. Network segregation policy, constraints in equipment vendors’ maintenance contracts, and the division of responsibility between the shop floor and the IT department. Where digital twin projects stall is usually not inside the model, but right here in the integration.
Failure Pattern 4 – Deploying Without Naming an Owner
A digital twin is not a deliverable you build and then finish with. When the line changes, the model has to change too. Deploy without deciding who does that updating and, a year later, the model no longer matches the physical plant and nobody looks at it.
The complication here is continuity of personnel at a site in Thailand. Once the person who understands the structure of the model is gone through transfer or resignation, updates stop. The countermeasure is to document the model construction process, and, where the work is outsourced, to use a contract structure that keeps the update procedures in your own hands.
Failure Pattern 5 – Not Deciding How to Measure the Effect
The benefit of a digital twin does not show up as clearly as the benefit of a visualization tool. Suppose the result is a three point rise in equipment utilization. Separating out whether that came from the digital twin or simply from a change in order mix is not straightforward.
You need to fix the baseline figures for the comparison period before you deploy. On top of that, it is important to narrow the metrics you track to one or two. Choose metrics tied directly to what you are using the twin for, such as changeover time, response time to plan changes, or the number of unplanned stoppages.
Pre-Start Checklist
- Have you narrowed the target down to a single machine or process?
- Have you verified the missing-data rate and the definitions of the data available from that target?
- Have you confirmed the integration method with the existing production management system, with an effort estimate attached?
- Have you decided who is responsible for updating the model?
- Have you set the effect metrics and the comparison period?
- Have you put the withdrawal criteria in writing?
How to Judge Whether Your Plant Needs a Digital Twin
Some readers will have got this far and felt that this may be too heavy for their operation. That instinct is quite likely correct. For many factories, upgrading equipment monitoring gives a better return on investment. Here is a way to frame the decision.
| Situation | Upgraded monitoring is enough | A digital twin is worth considering |
|---|---|---|
| Core problem | You cannot see the current state | You can see it but cannot choose a response |
| Production type | Few variants, stable processes | High mix with frequent changeovers |
| Equipment interdependence | Processes run independently | Heavy interference between processes |
| Decision frequency | Daily or weekly is sufficient | Conditions change by the hour |
| Cost of trying things | You can try it on the real machine | Trying it on the real machine is costly |
| Data status | Still being put in place | Several years of records accumulated |
The more rows that fall on the right side, the higher the value of evaluating a digital twin. There is one exceptionally heavy condition, however. If the bottom row, data status, falls on the left, then even with everything else on the right, building the data foundation comes first.
With that premise established, the order of investment decisions sorts out as follows.
| Stage | What you do | What to judge on |
|---|---|---|
| Stage 1 | Put data collection and visualization in place | Is it being captured without gaps? |
| Stage 2 | Build a pilot on one target | Do predictions match actuals? |
| Stage 3 | Roll out to similar equipment | Does build effort come down? |
| Stage 4 | Extend to a whole line or site | Can the operating structure sustain it? |
Working through these four stages without skipping any turns out to be the cheapest route overall. The transition decision from Stage 1 to Stage 2 matters most. If the result there is that predictions do not match actuals, the cause is almost always on the data side rather than in the model. In that case the right call is to go back to Stage 1 rather than to elaborate the model further.
Fit and Misfit by Industry and Production Type
As a general rule, digital twins deliver most readily in production types where dependencies between processes are complex and the effect of changing conditions is hard to predict. High-mix low-volume lines with frequent changeovers, plant-type continuous production where upstream and downstream conditions influence each other, and assembly processes where transport and inventory accumulation drive overall throughput all qualify.
Conversely, on a line that steadily runs a single product, the range of conditions worth testing in simulation is narrow to begin with, which makes it hard to generate a return that justifies the investment. In that case a small twin focused on predictive maintenance for individual machines is the more rational choice.
Considerations Specific to a Thai Site
Evaluating this at a site in Thailand raises a few additional points.
The first is the division of roles with headquarters. If the Japanese parent already has a digital twin foundation, connecting to that foundation may hold the total cost down compared with building something independently in Thailand. The federated configuration defined in ISO 23247 Part 6 is precisely the concept intended for this kind of twin-to-twin linkage across sites.
The second is the local operating structure. The problem of who owns model updates, described above, gets more severe the smaller the site. If you cannot staff a dedicated person, starting from a single-machine twin with a low update frequency is more realistic.
The third is checking what support schemes apply. Various incentive programs exist for capital investment and digital investment, but eligibility and conditions differ by scheme and by case. This article does not attempt to rule on individual programs, so we recommend confirming directly with the relevant authorities or your advisors early in the investment planning process.
Frequently Asked Questions
What is the difference between a digital twin and IoT?
IoT refers to the mechanism for acquiring data from equipment and transmitting it, while a digital twin refers to the mechanism that uses that data to build a digital mirror of reality and compute the future on top of it. In terms of the relationship, IoT is the foundation a digital twin sits on. A plant that has deployed only IoT has, in the three-layer terms used in this article, only Layer 1. So rather than an either-or choice between IoT and a digital twin, the practical way to think about it is to get IoT in order first and then add a digital twin on top if it is needed.
Can a small or mid-sized factory implement one?
Yes, if you narrow the scope. A configuration limited to a single machine whose failure has a large impact, rather than the whole plant, can in some cases be built for under 100,000 US dollars. Once the scope spans multiple machines, as with a bottleneck process, the cost rises accordingly. What matters is not your size but whether you can narrow the target. Conversely, even a small operation that widens the target to the entire factory will see both cost and difficulty jump. We recommend starting with one machine, confirming the effect, and then expanding.
How much does a digital twin cost?
It varies enormously with scope. As general overseas ranges, a configuration limited to a single machine runs under 100,000 US dollars, and a single line or single facility at moderate complexity is put at 500,000 to 2 million US dollars initially plus 100,000 to 400,000 US dollars per year to operate. The breakdown is 50,000 to 300,000 US dollars per year for the platform license, 30,000 to 200,000 US dollars for data integration, 40,000 to 400,000 US dollars for 3D model and simulation construction, and 10,000 to 150,000 US dollars per year for cloud costs. Note that no published pricing data specific to Thailand was found, so use these purely as a sense of the market.
We already visualize with IoT, so should we move on to a digital twin?
Whether to move on can be judged from the nature of your problem. If the problem is that you cannot see the current state, widening the accuracy and coverage of your visualization gives the better return. If, on the other hand, you have reached the stage where you can see the current state but cannot judge which of several possible responses is best, that is the problem domain a digital twin answers. As a rule of thumb, if the phrase “we will not know until we try it” keeps coming up from the shop floor, and trying it on the real machine is expensive, the evaluation is worth doing.
Do we need to comply with ISO 23247?
It is not the kind of standard you get certified against, so there is no obligation to demonstrate compliance. Its practical value is as a common yardstick during vendor selection. When you receive a proposal, you can ask in standardized terms which functional blocks of the reference architecture the vendor covers, which communication protocols they conform to, and which composition type they assume for future linkage with other twins. The more vendors you are comparing, the more this common language is worth.
Summary
A digital twin is a mechanism that continuously mirrors the state of physical assets in digital form and feeds what you test on that mirror back into reality. It differs from a visualization dashboard in handling a forward-facing time axis, from BIM in handling dynamic state, and from a one-off simulation in that synchronization continues.
As of 2026 the market is in the middle of rapid expansion, and with Part 5 and Part 6 added to the ISO 23247 international standard, discussions about configurations spanning multiple sites can now be held in standardized language. In Thailand, major industrial groups are already moving on collaborations that include digital twins.
At the same time, the reality that much of Thai manufacturing cites data quality and infrastructure as barriers cannot be ignored. A digital twin cannot produce accuracy beyond the quality of its input data, and because its errors come out looking persuasive, the health of the data foundation is questioned even more sharply than it is with a visualization tool.
The realistic path, therefore, is a staged one. Confirm that the data collection layer is in place, start with a pilot narrowed to one machine or one process, verify that predictions match actuals, and only then roll out. A plan that targets the entire factory at once is the most expensive choice on both cost structure and difficulty.
Determining whether your problem is that you cannot see, or that you cannot choose a response, is the first fork in the road. If it is the former, there are things to do before a digital twin.
Whether you should deploy a digital twin, or whether you need to build the data foundation first, is largely a question that cannot be answered without actually looking at your equipment configuration and the data you are currently capturing. TOMAS TECH builds production management systems and equipment data collection for Japanese-affiliated plants in Thailand, and we are happy to talk at the exploratory stage, before any direction has been settled. Starting from working out together how much data your current equipment can yield, and how far that gets you, is perfectly fine, so if anything here raised a question, please contact us here.
References
- Digital Twin in Manufacturing Market Report 2026 – researchandmarkets.com
- Analysis of the New ISO 23247 Series of Standards on Digital Twin Framework for Manufacturing – NIST
- ISO 23247 Digital Twin Framework for Manufacturing overview – ap238.org
- ISO 23247-5 Digital thread – ISO
- ISO 23247-6 Digital twin composition – ISO
- MOU on carbon neutrality collaboration in Thailand between Toyota, CP, TLS, SCG and CJPT – Toyota Asia
- Unlocking Thailand’s AI Potential 2026 – AWS-commissioned study
- Data quality concerns a barrier to adoption of AI – Bangkok Post
