Factory IoT Implementation Guide 2026: 5 Cost Layers and How to Start

“The line clearly stops. But the utilisation figure in the monthly report never moves off 87%.” For most Japanese-owned plants in Thailand and the wider ASEAN region, that specific discomfort is what starts a factory IoT implementation project. Daily production reports are handwritten. The stoppage reason column says “equipment trouble” and nothing else. Head office keeps asking what the equipment utilisation number is actually based on. Then the quotes arrive, spanning an order of magnitude, and nobody can explain what is being bought at each price point. This guide walks through the concrete routes for pulling operating data out of machines you already own, a five-layer breakdown of the cost, and the Thailand-specific cost assumptions you need before you build a business case.

Why factory IoT implementation really stalls: getting data out of legacy machines

Most IoT evaluations begin with “which cloud platform?” and “which dashboard product?”. That is almost never where the project actually stops. It stops at the moment someone tries to read a register from the PLC on an injection moulding machine installed twenty years ago and discovers there is no communication option fitted at all. Or the moment the wireless survey shows no usable signal at the far end of the shop floor.

A factory IoT stack has four tiers, from the bottom up: the measurement layer (getting the data), the transport layer (moving it), the storage layer (keeping it), and the application layer (seeing it and deciding with it). Almost everything written about industrial IoT concerns the top two tiers — screens and platforms. But in an existing plant, where legacy machines make up the overwhelming majority of the asset base, failed investment happens almost without exception at the very bottom and at the very top: in the measurement layer and in the application layer.

Data collection detached from decision-making is the core failure mode

A Japanese analysis of IoT data platform build costs and failure factors lists four recurring failure patterns: data collection becomes detached from decision-making; shop-floor operators are not involved; the wireless site survey is skipped; and security design is deferred to later (source: GXO). Three of those four have nothing whatsoever to do with which cloud or which dashboard you pick. In other words, they are failures that no amount of diligence in product selection will prevent.

The first one — detachment from decision-making — is the deepest problem. You can get a utilisation chart onto the plant manager’s PC, but if nobody has decided who looks at that chart, at what time, and what they change as a result, no one will open it three months later. Turn it around: if you have already agreed that the morning meeting starts by reviewing “yesterday’s top three machines by downtime, with reasons”, the list of data points you actually need narrows down by itself, and the investment gets smaller.

So the order of thinking is “how to capture” then “how to use”

This guide follows that order. The first half breaks down how to capture operating data from existing machines into five concrete routes. The second half covers how to tie that data to specific decisions by specific people, using OEE, minor stoppage analysis, and downtime cause analysis. At the centre sit the five-layer cost breakdown and the Thailand-specific assumptions. If you also need to position this against the layer above — MES and production management — we cover that separately in our guide to choosing a production management system and MES for a Thai plant, which is worth reading alongside this one when you are dividing responsibilities between systems.

Five routes to capture equipment data from legacy machines: the practical retrofit options

Retrofit IoT — collecting data from machines you are not replacing — breaks down into five routes. The practical trick is not to standardise on one. Even inside a single plant, the right route differs machine by machine, and deciding up front that “every machine will be done the same way” is what drives cost and schedule risk.

Route 1: Read directly from the PLC

This route gives the richest data and the least predictable engineering effort. The internal registers of the PLC controlling a machine already hold essentially everything you want: running/stopped state, alarm numbers, cycle time, production counters, setpoints. If a communication option is fitted, an IoT gateway can read those registers over an industrial protocol such as Modbus TCP, PROFINET, or EtherNet/IP.

Three cautions apply. First, knowing which address holds which value requires reading the ladder program, and on OEM-built equipment the program is often undisclosed or password-protected. Second, additional communication load affects the control scan cycle, so a badly designed polling interval can affect machine behaviour. Third, it may touch the equipment maker’s warranty conditions, so confirm before you connect.

The workable approach is three rules: read-only (never write), a polling interval of one second or longer, and evaluate the impact on one machine before scaling. Where this route is available, automatic classification of minor stoppages — discussed later — comes within reach immediately.

Route 2: Tap the signal tower (stack light)

Most existing machines already carry a green/amber/red stack light. Add a non-contact optical sensor or a voltage detector to that wiring and you get the three states — running, attention, stopped — without touching the machine itself.

The strength of this route is that it is dramatically faster and cheaper than the alternatives, and it is unlikely to affect any equipment warranty. The weakness is granularity: you know the red lamp came on, but not why. So Route 2 is designed as a pair with manual entry of a stoppage reason code, covered below. Let the system capture stoppage start and end times mechanically and precisely, and let a person select only the reason. Even that combination lifts downtime accounting to a level that handwritten daily reports cannot approach.

For high-mix low-volume assembly lines, or plants with many general-purpose and manual machines that have no PLC at all, adopting Route 2 across the board first and then deepening only the machines that prove valuable with Route 1 is the most cost-effective sequencing.

Route 3: Add external sensors

Sensors clamped, stuck, or placed on the outside of the machine. The common combinations:

• Current sensors (split-core CT clamps): clamp around the main feed or a motor line and infer running, idling, and stopped states from the current waveform. The significant advantage is that you launch energy monitoring and equipment monitoring on the same hardware
• Vibration and temperature sensors: mounted on motors, pumps, fans, and gearboxes to track degradation trends. The entry point to predictive maintenance
• Proximity and photoelectric sensors: placed at the discharge chute or over a conveyor to count units produced, good and bad
• Air pressure and flow sensors: measure compressed air consumption and leaks, which feeds directly into energy intensity improvement

The appeal of this route is that it works regardless of the machine’s generation, maker, or country of origin. Current still flows through a machine from the 1970s, so a current sensor will always tell you something. The weakness is that what you obtain is an inference from a physical signal, which means threshold tuning requires a real measurement period on site. Where the current draw stops being “cutting” and becomes “idling” can only be settled by logging one to two weeks of data per machine. Leave that period out of the project schedule and the schedule will slip. Every time.

Route 4: Take signals indirectly from the control panel, relays, and auxiliary contacts

This sits between Routes 1 and 2. Contact signals from auxiliary relays, solenoid valves, limit switches, and emergency stop circuits inside the control cabinet are branched into an isolated input module. The strength is that you get signals with unambiguous meaning — “mould clamp complete”, “part removal complete”, “safety door open” — in exactly the quantity you need, without decoding the ladder program.

In Thai plants, wiring added at each successive equipment upgrade tends to have accumulated inside the cabinet, and drawings often no longer match the physical installation. If you choose this route, budget the effort on the assumption that you will survey the cabinet with your local electrical staff and update the drawings as you go. Seen positively, this is a good opportunity to take stock of what is actually inside your control panels.

Route 5: Human entry (design manual input in from the start)

“Manual entry, in an IoT project?” — yes, and it is indispensable in practice. Stoppage reasons, defect categories, changeover start and end, material lot, operator. No physical sensor will ever produce these.

What matters is treating manual entry as a design object rather than a compromise. Concretely, split the responsibility like this:

• Timestamps, quantities, state changes → captured by machine. Never ask a person to type these. Accuracy collapses the moment you do
• Reasons, categories, judgements → selected by a person. Never ask them to type these either. Have them pick from 10 to 20 pre-defined codes

Tablet or andon terminal screens should assume Thai-language labels, keep the number of buttons small, and be designed so any entry completes within three seconds. Compromise here and operators will simply press the top code every time, and the data becomes worthless.

Quick comparison of the five routes

In real plants, the most cost-effective combination is: use Route 2 to capture downtime across every machine, deepen only the bottleneck machines with Route 1 or 4, add Route 3 on the power-consuming assets you want to meter, and give the whole thing meaning with Route 5.

PLC data collection and protocol design: OPC UA, MQTT, Sparkplug B and the IoT gateway

Once you know how you are capturing data, the next question is how you move it. Getting the 2026 baseline architecture right materially reduces the risk of having to rebuild everything in five years.

MQTT moves data; OPC UA defines what it means

Comparisons of industrial IoT protocols consistently frame MQTT and OPC UA as complementary rather than competing, because they do different jobs. MQTT is a lightweight publish/subscribe transport that is good at getting data across unreliable links. OPC UA is good at attaching an information model to data — which machine this value belongs to, what quantity it represents, what unit it is in.

The practical 2026 baseline is a three-part arrangement: OPC UA for semantics on the plant floor, MQTT for transport to the cloud, and Sparkplug B as the bridge between them (sources: HiveMQ, FlowFuse). Sparkplug B layers a topic namespace convention, data type definitions, and device birth/death monitoring on top of MQTT. That is what prevents the classic accident where data arrives over MQTT and the receiving side cannot tell what any of it means.

Convert legacy PLCs that do not speak OPC UA at an edge gateway

The majority of PLCs in an existing plant do not support OPC UA. The standard answer is to place an edge gateway supporting Modbus, PROFINET, EtherNet/IP and similar next to the equipment — an Edge of Network node, in Sparkplug terminology — and convert to OPC UA form there before sending upstream. The idea is not to make the old PLC new. It is to put one translation box next to the old PLC.

The payoff shows up as investment protection. When you eventually replace a machine, the only thing that changes is the wiring between the gateway and the machine. Everything above the gateway — data platform, dashboards, reports, alerts — is reused untouched. Skip the gateway and connect machines straight to the cloud, and every single machine replacement triggers cloud-side rework.

Use a Unified Namespace to erase the difference between old and new machines

One step further in design maturity is establishing a Unified Namespace: fix the hierarchy of plant, line, machine, and signal first, then route all data along that address structure.

With that in place, a new machine that speaks OPC UA natively and a legacy machine coaxed into speaking through add-on sensors and a Modbus gateway appear to the analytics layer with identical topic structure, data types, units, and timestamp precision (source: iFactory). From the shop floor, one is a current-generation machine and the other is thirty years old. From the dashboard and the OEE calculation logic, they are handled the same way. That is the key to retrofit work that does not end up as a stopgap.

Do not skip the wireless site survey

The third failure pattern — skipping the wireless site survey — is on the list because it genuinely happens all the time. A factory building is a difficult radio environment: metal machines, metal racking, metal partitions, water piping, inverters, welders. Wi-Fi that works perfectly in the office routinely drops packets only while the press is running.

The countermeasure is simple. Run a site survey before design, and measure both while equipment is running and while it is stopped. Then make sure the gateway has a local buffer that stores data during a link outage and forwards it on recovery. Those two measures alone prevent the credibility collapse of “we can’t calculate utilisation for the days when data went missing”. On segment separation and asset management when you connect the OT network to the IT side, we go into detail in our guide to OT security for factories.

Breaking factory IoT cost into five layers: the industrial IoT cost structure by scale

There is no single number that answers “what does factory IoT implementation cost”. But if you understand the cost layer by layer, and what you are paying for in each layer, you become able to judge the reasonableness of a quotation yourself. The figures below come from Japanese domestic market data for 2026, broken into five layers.

All amounts in this section are Japan domestic market rates, quoted as a reference structure only. In Thailand the mix changes: local engineering labour costs less, imported hardware carries duty and freight, and multilingual work in Japanese, Thai, and English adds effort. So do not transplant the numbers. Read them for the ratio between layers and the list of line items. Because exchange rates move, this article performs no currency conversion at all.

Layer 1: Sensors and signal extraction (JPY 0.4–1.5 million)

This is the physical realisation of Routes 1 to 4 above. The breakdown is sensors themselves at JPY 0.1–0.5 million, installation and wiring at JPY 0.2–0.8 million, and commissioning tests at JPY 0.1–0.2 million (source: GXO).

The ratio worth noticing is that installation and wiring cost more than the sensors. This is the single most important thing to understand about factory IoT cost structure, and it explains why “we found cheap sensors, so this should be cheap” never works out. On existing equipment, panel work, cable routing, and scheduling around production windows all land in the labour line. Conversely, doing several machines in one wiring campaign clearly reduces the per-machine cost of this layer.

Layer 2: Gateway and network (JPY 0.1–0.5 million)

An industrial IoT gateway runs JPY 0.05–0.3 million, with communication setup at JPY 0.05–0.2 million (source: GXO). Layers 1 and 2 combined — the “sensors plus gateway” bundle — therefore come to JPY 0.5–2 million.

This is the smallest layer by value, and as noted above, the layer that determines your future rebuild cost. Choose cheap consumer-grade hardware here and the problems surface in the operating phase: units failing within months in factory heat, dust, and vibration; no automatic recovery after a link drop; no firmware updates. This is not the layer to economise on.

Layer 3: Data platform, cloud or on-premise (JPY 2–8 million plus monthly fees)

The initial build breaks down as platform design and construction at JPY 0.5–2 million, data ingestion development at JPY 0.5–2 million, anomaly detection logic at JPY 0.5–2 million, security design at JPY 0.3–1 million, and testing plus documentation at JPY 0.2–1 million. On top of that sits a monthly service fee of JPY 10,000–100,000 (source: GXO).

This is the largest single block of the initial investment. The realistic way to compress it is to drop “anomaly detection logic” out of the first phase entirely. Build a reliable factual record first — running, stopped, units produced — and start on anomaly detection and early-warning diagnostics only after six to twelve months of operating data has accumulated. That one decision cuts a meaningful slice off the initial investment and produces better logic besides. Paying up front for anomaly detection with no training data is simply out of sequence.

Layer 4: Screen and alert development (JPY 1–5 million)

Dashboard development breaks down as UI/UX design at JPY 0.2–0.8 million, screen development at JPY 0.5–2.5 million, reporting features at JPY 0.2–0.8 million, access control at JPY 0.1–0.4 million, and multi-device support at JPY 0.1–0.5 million (source: GXO).

The classic way this layer balloons is turning every request from every department into a screen. One for the plant manager, one for the production manager, one for quality, one for maintenance, one for the executive team, one for head office — and the screen count passes twenty without anyone noticing. As covered later, the practical optimum is to limit yourself to screens for a small number of defined roles.

Layer 5: Operations — master data, stoppage reason codes, floor training — kept as annual running cost

And then the layer that is most overlooked and most decisive for whether the project succeeds. Layer 5 covers building and maintaining equipment masters, item masters, and standard cycle times; designing and revising the stoppage reason code taxonomy; training operators and supervisors; daily data accuracy checks; and updating configuration whenever a machine is added or the layout changes.

One point of accounting and decision-making hygiene matters enormously here. Keep Layer 5 out of the initial investment figure and manage it separately as annual running cost. The reason is to avoid double counting. The substance of Layer 5 is your own internal labour. If you add it into the initial investment figure and then also subtract it as annual running cost in the ROI calculation, you have counted the same cost twice. So: the “initial investment” column of your cost sheet contains Layers 1 through 4 only, and Layer 5 goes in the “annual running cost” column together with the external monthly service fee (JPY 10,000–100,000 per month, i.e. JPY 120,000–1.2 million per year).

For the internal labour amount itself, there is no published market data, so this article gives no figure. Calculate it from your own hourly rate multiplied by expected hours. As a sense of effort, the launch period typically consumes 30–50% of one person’s time on master data and reason code revision, settling to a few days per month once stable.

Total initial investment and models by scale

Summing Layers 1 through 4 gives an initial investment range of JPY 3.5–15 million (0.5–2 plus 2–8 plus 1–5). Three model cases by scale have been published (source: GXO).

It is worth doing that division yourself. Five machines at JPY 3 million is JPY 600,000 per machine. Thirty machines at JPY 11 million is roughly JPY 366,700 per machine. The machine count rises sixfold while the investment rises only about 3.7-fold, so the per-machine figure falls by around 39%. The reason is that Layers 3 and 4 are shared infrastructure and barely scale with machine count. The practical conclusion is clear: once you have decided to build the platform, narrowing the scope too far makes each machine more expensive, not less. That said — and as covered below — the first phase should be deliberately narrow so you can learn from it. So the optimum is to design the platform for your eventual full machine count while connecting machines in stages.

Note that the whole-plant figure of approximately JPY 20 million sits above the top of the JPY 3.5–15 million range. That is not a contradiction. The range assumes the common case of a line-level or partial deployment; taking on a whole plant at once stacks up Layers 1 and 4 and pushes the total above the range. When comparing quotations, always confirm what deployment scope a given range assumes.

What small deployments cost

If the scope is “one line only” or “just temperature and humidity in the warehouse”, the figures drop to roughly a tenth of those numbers. Published market data suggests JPY 0.3–0.8 million for temperature and humidity monitoring, JPY 0.8–2 million for equipment monitoring with alerting, and monthly fees from a few thousand to a few tens of thousands of yen (sources: is-prime, OPTiM). That price band is achievable by using an off-the-shelf cloud service and giving up on screen customisation.

The deciding question is whether you intend to roll out further. If it genuinely ends at one line, an off-the-shelf service is enough. If you plan to extend to the whole plant within three years, at least the Layer 2 gateway and the data structure should be chosen with that future in mind.

Implementation steps and timeline: 8–12 months and the four failure patterns

A factory IoT implementation is generally scoped as five steps over 8 to 12 months (source: GXO), broken down as follows.

1. Requirements definition: 2–4 weeks — decide which decisions you want to improve, and work backwards to the data points needed
2. PoC: 1–2 months — capture real data from 1–3 machines, and measure both accuracy and engineering effort
3. Design and development: 2–4 months — build the data platform and the screens
4. Rollout and training: 1–2 months — extend to the target machines, train operators and supervisors
5. Stabilisation: 3 months or more — raise data accuracy and embed the operating rules

Step 5 is the one most often cut, and on the shop floor it is where the real work happens. A stoppage reason code taxonomy is always awkward on the first design pass; it takes two or three revisions before operators can reliably select the right code. Treat Step 5 as slack time and delete it, and operations begin with data accuracy still poor — which leads to the worst possible ending: “the numbers aren’t trustworthy, so nobody looks at them.”

The four failure patterns and specific countermeasures

1. Data collection detached from decision-making. Countermeasure: during requirements definition, write on a single page who looks at what, when, and what they decide. For example: “the production supervisor reviews the previous day’s top three machines by downtime at 08:00 each morning and sets that day’s maintenance priorities.” Any data point for which you cannot write that sentence is a legitimate candidate for exclusion from the first phase.

2. Shop-floor operators not involved. Countermeasure: have operators themselves participate in designing the stoppage reason codes. A taxonomy written by management always diverges from the vocabulary and the felt reality of the floor. At a Thai site, the most effective single move is to delegate the Thai-language terminology to your Thai line leaders.

3. Wireless site survey skipped. Countermeasure: as above — survey with equipment running, and insist on a local buffer in the gateway.

4. Security design deferred. Countermeasure: keep security design as a visible line item when you quote Layer 3 (JPY 0.3–1 million is included in that breakdown). The cost of redoing network segmentation after the fact substantially exceeds the cost of designing it in at the start.

Production visibility and OEE: connecting the data to specific decisions

Now the second half — how to use the data. The first task for a plant that has just gained the ability to collect operating records is to agree on metric definitions.

The word “utilisation” is being used for three different things inside your company

In many plants, one word covers three distinct measures:

• Availability: the share of loading time during which the machine was actually running (shows stoppage loss)
• Performance: the share of running time during which output matched the theoretical cycle time (shows speed loss and minor stoppages)
• Quality: the share of units produced that were good (shows defect loss)

Multiply the three together and you have OEE, overall equipment effectiveness.

OEE = Availability × Performance × Quality

Simply sharing that formula across the organisation changes the quality of reporting. “Utilisation is 87%” means something completely different depending on whether it refers to availability alone or to OEE. Take a machine with availability of 95%, performance of 85%, and quality of 97%: its OEE is 0.95 × 0.85 × 0.97 = approximately 78%. All three components look “reasonably good”, yet overall effectiveness is below 80%. That is the single strongest argument for using OEE — it makes visible the multiplicative effect of losses that no single metric reveals.

Who watches which metric

Once metrics are defined, assign them. This mapping works in practice.

What this table means is that you build four different views from the same data. Which also means that, in principle, you need nothing beyond these four. As a practical brake on Layer 4 cost inflation, we recommend fixing these four tiers — floor, supervisor, plant manager, executive — before any screen design starts.

What actually increases when utilisation goes up

Raising equipment utilisation is not an end in itself. Pushed to its conclusion, higher utilisation buys you exactly two things: more output from the same machines (capacity gain) or the same output in less time (less overtime and fewer weekend shifts). Which one you get is determined by whether the plant is order-constrained or capacity-constrained.

That distinction feeds straight into the investment case. If you have headroom in demand and anything extra you make will sell, additional running time converts directly into additional contribution margin. If demand is flat, the benefit only takes the form of reduced overtime and fewer operating days, and the monetary value is much smaller. We return to this in the ROI section. Note also that on the capacity-constrained side, revisiting the plan itself is often effective — our comparison and selection guide for production schedulers (APS) is a useful companion here.

Minor stoppage (chokotei) visibility and downtime cause analysis: designing andon and dashboards

What surprises plants most after implementing an equipment monitoring system is almost always the true picture of minor stoppages.

Why minor stoppages never appear in the daily report

A minor stoppage — *chokotei* in Japanese, a short stop of tens of seconds to a few minutes — by its nature never gets written down. The operator clears the jam, presses reset, and goes back to production. It is far too routine to register as “trouble”. As a result it never appears in reported downtime, while accumulating dozens of times a day. A two-minute stop occurring thirty times a day is 60 minutes; across 20 operating days that is 20 hours a month. Those 20 hours appear in no report anywhere.

What minor stoppage analysis requires is timestamp recording that does not depend on human memory. Any of the routes described earlier will do it to the second: Route 1 (PLC alarm and run signals), Route 2 (stack light state changes), or Route 3 (a dip in the current waveform, or a stalled production count). Route 3’s test in particular — “the counter has not incremented even though the theoretical cycle time has elapsed” — is a highly portable method that detects minor stoppages even on machines with no signals to read.

Stoppage reason code design determines the quality of your downtime cause analysis

Once stoppage times are captured automatically, the next step is attaching reasons. This is where machine downtime tracking either becomes useful analysis or stays noise. Four design principles:

1. Keep the count to 10–20. Nobody selects correctly from a list of 50 codes
2. No more than two levels (6–8 major categories × 2–4 sub-categories). A third level lengthens entry time and the floor disengages
3. Monitor the share of “Other”. If “Other” exceeds 15%, the taxonomy is wrong and it is time to revise
4. Never merge items whose owner differs. Rolling “waiting for material” (a purchasing and production control issue) and “mould fault” (a maintenance issue) into a single “changeover related” code means nobody can act on the analysis

With a taxonomy that respects those four principles, a Pareto chart of downtime — bars sorted from largest to smallest — tells you immediately what to work on tomorrow. Ignore them and what you get is a chart saying “equipment trouble: 62%”, which says nothing at all.

Separate andon from dashboards by audience and time horizon

In designing real-time factory monitoring displays, the important discipline is not confusing andon with dashboards.

An andon exists to move people right now. It is a large display or indicator visible from above the line or from the aisle, with a deliberately minimal amount of information: which machine is stopped at this moment, and nothing else. The requirement is instant comprehension through colour and position. The moment you pack in numbers and charts, it has failed as an andon. The test is whether it can be read from five metres away in three seconds.

A dashboard exists to see trends and decide what comes next. Its time horizon is yesterday, last week, last month, and the leading elements are Pareto charts, trend lines, and machine-by-machine comparison. This is something you look at on a PC in the meeting room or the office.

Between the two, place alerts. These are active, threshold-based notifications: “if any single machine is stopped for more than 15 minutes, notify the supervisor’s phone”; “if the Other code is selected more than 20 times in a day, notify the administrator”. The one thing to watch in alert design is that an alert that fires too often gets ignored. Set the initial thresholds deliberately high, then increase sensitivity gradually as you observe operations.

The mechanism that makes production visibility stick

Whether a plant is still using its monitoring system three months later is determined by its meeting structure, not by technology. Plants where it has genuinely stuck share a fixed routine like this:

• Morning meeting (10 minutes): review yesterday’s top three by downtime and the share of “Other” together
• Weekly (30 minutes): check progress on countermeasures against the number one item on the Pareto chart, and set the next number one
• Monthly: report the OEE trend and the additional running time gained through improvement, converted into money

With those three forums in place, the data is being watched. Install the system without creating the forums and failure pattern 1 — detachment from decision-making — occurs exactly as described. When you move on to automating the equipment side, reading our guide to how to approach factory automation alongside this one makes the sequencing between measurement and automation easier to sort out.

How to think about ROI: calculate your own cost per hour of downtime

What an investment decision needs is your own numbers, not an industry average. This section positions the published international data properly, then gives you the formulas to calculate your own.

Do not transplant international averages

Data on the cost of unplanned downtime for 2026 reports an average of approximately USD 260,000 per hour in industrial manufacturing. The same material also shows how enormous the spread is: USD 10,000–50,000 per hour in discrete (assembly) manufacturing, and up to USD 2.3 million per hour in automotive plants (sources: ReliaMag, Manufacturing Lead Generation).

Line those three figures up and the nature of the USD 260,000 average becomes clear. The average is pulled hard upward by the enormous losses of automotive and continuous-process industries. The realistic band for discrete manufacturing — where most Japanese-owned ASEAN plants sit — is USD 10,000–50,000 per hour, and often toward the bottom of it. Copy USD 260,000 into your capital request and you risk overstating the benefit by an order of magnitude.

The same caution applies to the other widely cited figures: that IoT-based predictive maintenance reportedly reduces unplanned downtime by 35–50% and improves OEE by 20–25%; that plants with mature condition monitoring reportedly cut unexpected failures by 70–75%; and that IoT sensor deployment reportedly costs USD 2,000–8,000 per asset against preventable failures of USD 50,000–500,000, with ROI in 12–24 months. All of these are aggregations and estimates from vendors and industry media (sources: ReliaMag, L2L). They are useful for direction of travel. As the basis for a capital request, they need to be replaced with your own measurements.

The formula for your own cost per hour of downtime

Calculate the loss from one hour of stoppage as the sum of three components.

Cost per hour of downtime = (1) lost contribution margin + (2) fixed costs that continue during the stoppage + (3) additional recovery costs

(1) Lost contribution margin = good units produced per hour × contribution margin per unit (selling price − variable cost)
(2) Fixed costs = people assigned to that line × hourly labour cost + electricity still consumed while stopped + hourly depreciation of the equipment
(3) Additional costs = overtime premium to catch up, expedited or air freight, scrapped work in progress, damage to moulds and jigs

One important caveat. Component (1) can only be counted when the extra output will actually sell. Where orders are capped, recovering stoppage time only produces the (2) saving of “no overtime that day”. Adding (1) unconditionally overstates the benefit. In a capital request, the honest — and in practice more approvable — approach is to present two figures side by side: the benefit assuming demand is secured, and the benefit if demand does not grow.

Avoid double counting in the payback calculation

Calculate payback period as follows.

Payback period = initial investment (total of Layers 1–4) ÷ (annual benefit − annual running cost (Layer 5))

The key is subtracting annual running cost in the denominator. And as established above, do not add Layer 5 into the initial investment in the numerator and then also subtract it in the denominator. That is double counting the same cost. Remember it as: Layer 5 appears on the denominator side only.

For reference, the published model case shows “5 machines, initial investment approximately JPY 3 million, assumed annual avoided loss of JPY 1.5 million, payback 2 years” (JPY 3 million ÷ JPY 1.5 million = 2 years). That is a simple payback calculation that does not subtract annual running cost. Follow the formula above and subtract running cost, and the payback period comes out longer than that. For your own capital request, stating the figure after running cost is deducted saves you from being told later that the benefits never materialised.

What changes when you use Thai labour rates

Put Thai market rates into component (2) and you reach a different conclusion from the one head office in Japan would reach. As of July 2026, Thailand’s minimum wage is still not unified nationally; it is set by province at THB 337–400 per day (national average approximately THB 374 per day). THB 400 applies in Bangkok, Phuket, Chonburi, Rayong, Chachoengsao, and Koh Samui. THB 337 applies in Narathiwat, Pattani, and Yala. Chiang Mai is split by district: THB 380 in the Mueang area, THB 357 elsewhere. Notification No. 14, effective 1 July 2026, kept these levels unchanged (sources: EmployerRecords, Employsome).

These are daily rates, not hourly rates. Misread that and your hourly labour cost estimate is wrong by an order of magnitude. Converting crudely on an eight-hour day: 337 ÷ 8 ≈ THB 42 per hour, 400 ÷ 8 = THB 50 per hour, and the average 374 ÷ 8 ≈ THB 47 per hour. Actual labour cost is higher, because employer social security contributions, overtime premiums, allowances, and overhead sit on top — but the figure stays in the range of tens of baht per person-hour.

The conclusion follows directly. At a Thai site, labour reduction alone will not pay back a factory IoT investment. Even if five people are assigned to a line and you prevent one hour of stoppage, the direct labour component of the benefit is on the order of a couple of hundred baht (5 people × roughly THB 47 ≈ THB 235). With Layers 1 to 4 running into millions of yen, stacking up that kind of saving will not reach payback in any reasonable number of years.

So what does pay it back? Three things carry real weight:

1. Capacity gain from additional running time (the component (1) side — by far the strongest lever if you have the orders)
2. Energy cost reduction (covered below; Thai electricity is not cheap)
3. Falling per-machine cost through wider rollout (as calculated above: approximately JPY 600,000 per machine at 5 machines, approximately JPY 367,000 at 30)

In other words, the ROI case for factory IoT at a Thai site should be built not around “fewer people” but around making more with the same people and the same machines, making it with less energy, and extending that cheaply to the other lines.

Thailand-specific assumptions: electricity rates, business conditions, and the real terms of incentives

Finally, the local assumptions you must have straight before evaluating an IoT investment in Thailand. Outdated information circulates freely in this area, so verify against the 2026 position.

Electricity rates: use this figure for energy monitoring payback

Factory electricity in Thailand consists of a base energy charge of THB 3.78/kWh plus a fuel adjustment charge (Ft) of THB 0.1623/kWh for the May–August 2026 period. That is THB 3.9423/kWh as a straight sum. Add 7% VAT, demand charges, and the TOU structure (Cat 3 medium and Cat 4 large, on-peak and off-peak), and the effective rate lands in the range of THB 4.10–5.50/kWh (source: CAP Solar).

Always use the effective rate when calculating an energy monitoring benefit. Calculate on the THB 3.78 energy charge alone and you understate the benefit by roughly 8% at the bottom of that range and by roughly 31% at the top — the effective rate is 1.08 to 1.46 times the bare energy charge. The form of the calculation is simple.

Annual saving (THB) = annual kWh reduced × effective rate (THB 4.10–5.50/kWh)

The kWh you can reduce will not appear without measurement. That is precisely why it is worth adding current sensors to the same gateway used for equipment monitoring and measuring consumption by machine and by time of day first. The best targets are standby power outside operating hours, compressed air leaks, and intermittent loads that happen to cluster in on-peak periods. Under a TOU contract, simply shifting load to off-peak captures the rate differential. When operating data and power data line up on the same time axis, the fact that “this machine is stopped and still eating electricity” becomes visible for the first time.

Business conditions: how to read the timing of an investment decision

Thailand’s manufacturing PMI was 52.7 in April 2026, down from 54.1 the previous month and the lowest reading since January, but still the twelfth consecutive month above the 50 expansion threshold. At the same time, input costs were reported to be rising at the fastest pace since September 2022 (source: Trading Economics).

Those two facts point in a consistent direction for a factory IoT decision. Demand is holding in expansion territory, so the capacity-gain benefit — avoiding the component (1) loss — is a realistic target. Meanwhile, in a period of rising input costs, energy and yield management translate directly into margin. Which means launching equipment monitoring and energy monitoring on the same platform is particularly well matched to the current environment.

The depa 200% deduction: do not misread the eligibility conditions

The tax incentive most frequently mentioned in connection with digital investment is the 200% deduction associated with depa, Thailand’s Digital Economy Promotion Agency. The precise 2026 terms are as follows.

• The legal basis is Royal Decree No. 802 (B.E. 2569), published in the Royal Gazette on 6 February 2026 and effective 7 February 2026
• It applies retroactively to expenditure from 24 June 2025 to 31 December 2027
• Eligibility is limited to SMEs with paid-up capital of THB 5 million or less and annual revenue of THB 30 million or less
• The deduction is capped at THB 300,000 per accounting year
• Only software, hardware, smart devices, and digital services registered in the Thailand Digital Catalog qualify
• General-purpose PCs (laptops and desktops) are excluded

(sources: LexNova Partners, Optimum Accounting)

The critical point is that the threshold is not “paid-up capital under THB 50 million” but “paid-up capital of THB 5 million or less and annual revenue of THB 30 million or less”. That is a very tight condition, and most Japanese-owned companies with manufacturing operations in Thailand fall outside it on either the capital or the revenue test. Even where a company does qualify, the cap of THB 300,000 per accounting year is limited relative to the scale of initial investment discussed above. “We can use the depa scheme” cannot be the principal justification for the investment.

BOI: get the conditions attached to each incentive rate right

On the BOI (Thailand Board of Investment), reporting indicates that the 2026 policy direction for manufacturing centres on Industry 4.0 — smart factories, AI-enabled production, automation — and that the New S-Curve categories now include automation systems and data centres for AI, with quantum computing, advanced robotics, and generative AI added as AI and automation sub-categories (sources: Emerhub, Pertama Partners).

Against that background, the incentive that matters for improvement investment at an existing plant is the “Smart and Sustainable Industry” scheme. Get its conditions exactly right.

• The corporate income tax exemption cap is 50% as the baseline
• It reaches 100% only where automation or robotics are introduced into the production line and at least 30% of the value of the machinery being upgraded is sourced from Thailand’s domestic automation industry
• The application deadline is the end of 2027

So the claim that “the BOI smart factory scheme gives you an unconditional 100% exemption” is wrong. The 100% level carries the specific condition of at least 30% domestic sourcing. Note too that BOI application statistics (how many applications were approved) and the category-by-category incentive structure (which category gets what percentage) are separate matters, and should not be conflated in internal presentations.

The practical implication is that an equipment monitoring system on its own does not easily qualify as “introducing automation or robotics”, so it is easier to capture the incentive by planning it together with equipment renewal or automation investment. Use the bottleneck data from equipment monitoring to select what to automate, and bundle measurement and automation into the same application. In that sequence, the justification for the investment and the eligibility conditions for the incentive tend to be satisfied at the same time. If automating quality inspection is on your list, our guide to key points for implementing AI visual inspection is also worth a look.

Frequently asked questions

How much does factory IoT implementation cost?

Japan domestic market data, quoted here as a reference structure, gives JPY 0.5–2 million for sensors plus gateway, JPY 2–8 million for the cloud platform (plus JPY 10,000–100,000 monthly), and JPY 1–5 million for dashboard development, for a total initial investment range of JPY 3.5–15 million (source: GXO). By scale, the model cases are approximately JPY 3 million for 5 machines, approximately JPY 11 million for 30 machines across 3 lines, and approximately JPY 20 million for a whole plant. For a small single-line deployment with equipment monitoring and alerting, JPY 0.8–2 million is reported, and JPY 0.3–0.8 million for temperature and humidity monitoring alone. On top of all of that sits internal labour — master data, stoppage reason code design, floor training — as a separate annual running cost. If you do not agree internally whether that internal labour belongs in the investment figure or the running cost figure, your payback calculation will not add up later.

How do you make minor stoppages (chokotei) visible?

Human memory and handwritten daily reports will never catch them. What you need is automatic timestamp recording. There are three ways: read the PLC run signal or alarms directly; detect stack light state changes with an optical sensor or voltage detection; or detect that the production counter has failed to increment past the theoretical cycle time. The cheapest and fastest is the stack light, which gives you stoppage start and end times to the second without touching the machine. But it cannot tell you the reason, so pair it with an operating routine where a person selects only the reason code. Machine captures timestamps and quantities, human selects reasons and categories — that division of labour is the practical optimum.

Can you collect equipment data from old machines?

Yes. Current still flows through the motors of a machine from the 1970s, so a clamp-type current sensor on the main feed is enough to distinguish running, idling, and stopped. If there is a stack light, you can read the state from its wiring. If you can open the control cabinet, you can branch auxiliary relay contacts through an isolated input module. No PLC, no communication option, no drawings — none of these is an obstacle to retrofit IoT on legacy machines. The obstacle is forgetting to put the threshold tuning period (one to two weeks of measurement per machine) into the project schedule. The more old machines you have, the more that measurement window decides whether you hit your dates.

Which protocol should we choose for PLC data collection?

The 2026 baseline is a three-part arrangement: OPC UA for semantics on the plant floor, MQTT for transport to the cloud, and Sparkplug B bridging the two. MQTT and OPC UA are complementary rather than competing — MQTT moves data, OPC UA defines what it means (sources: HiveMQ, FlowFuse). Legacy PLCs that do not support OPC UA are handled by placing an edge gateway supporting Modbus, PROFINET, or EtherNet/IP next to the machine and converting to OPC UA form there before sending upstream. With that structure, replacing a machine in future lets you reuse everything built above the gateway.

What do we actually get from OEE improvement and higher utilisation?

Essentially two things: more output from the same machines (capacity gain), or the same output in less time (less overtime and fewer weekend shifts). Which one materialises depends on whether the plant is order-constrained or capacity-constrained. If you have the orders, additional running time converts directly into additional contribution margin; if demand is flat, the benefit stops at reduced overtime and the amount is small. Presenting both scenarios in the capital request is the practical approach. Note that at a Thai site, with the minimum wage set by province at THB 337–400 per day, payback on labour reduction alone is difficult; building the case on capacity gain, energy reduction, and falling per-machine cost through rollout is more realistic.

How far can published manufacturing IoT case studies inform our own decision?

What to take from a case study is the structure of how data was captured and how it was used — not the benefit percentages. Published figures such as 35–50% reduction in unplanned downtime and 20–25% OEE improvement from IoT predictive maintenance are largely aggregations and estimates from vendors and industry media, and there is no guarantee that the industry, equipment mix, or starting baseline match yours (sources: ReliaMag, L2L). Likewise, the figure of approximately USD 260,000 per hour for average unplanned downtime cost is an average pulled up by extremes such as up to USD 2.3 million per hour in automotive, while discrete manufacturing is given a band of USD 10,000–50,000 per hour. Read case studies for which route was used to capture data and who reviewed that data in which meeting, then recalculate the money using your own contribution margin and hourly labour cost.

Should we start with a small pilot or with the whole plant?

The recommendation is to design the platform for the whole plant while connecting machines in stages. The reason is in the cost structure. Five machines at approximately JPY 3 million is JPY 600,000 per machine, while 30 machines at approximately JPY 11 million is roughly JPY 366,700 per machine, because the cloud platform and dashboards are shared costs that barely scale with machine count. Narrow the scope too far and the per-machine figure stays high. On the other hand, making the first phase too large means that mistakes in stoppage reason code design and threshold tuning rework propagate across every line. The way to satisfy both constraints is to design Layers 2 and 3 for your eventual machine count while connecting and learning on one bottleneck line first.

Summary

What determines success in a factory IoT implementation is not the choice of cloud or dashboard product. It is two things: how you get data out of the machines you already own (the measurement layer) and which decisions, by which people, that data feeds (the application layer). There are five routes for capture, and the most cost-effective combination is to start with signal towers across the board and deepen only the bottleneck machines with a direct PLC connection. For transport, the 2026 baseline is OPC UA for meaning, MQTT for movement, and Sparkplug B as the bridge.

Understand the cost in five layers. Layer 1 (sensors and signal extraction) through Layer 4 (screens and alerts) constitute the initial investment, totalling JPY 3.5–15 million as a Japan domestic reference structure. Layer 5 (master data, stoppage reason code design, floor training) is not initial investment and should be managed separately as annual running cost. Mix the two and your payback calculation double counts.

And calculate ROI yourself rather than transplanting international averages. Given that Thailand’s minimum wage is set by province at THB 337–400 per day, payback on labour reduction alone is hard to achieve; the realistic design is built on three components — additional running time, electricity cost reduction at an effective rate of THB 4.10–5.50/kWh, and falling per-machine cost through wider rollout. On the incentive side, hold on to the precise conditions: the depa 200% deduction is limited to SMEs with paid-up capital of THB 5 million or less and annual revenue of THB 30 million or less, capped at THB 300,000 per accounting year; and the BOI Smart and Sustainable Industry corporate income tax exemption cap is 50% as the baseline, reaching 100% only with at least 30% domestic sourcing of the upgraded machinery value.

Which routes are usable on your own machines, which layer your cost will concentrate in, and how to construct a benefit figure that will clear your approval process — none of these can be settled without looking at the actual equipment list and the actual control cabinets. TOMAS TECH is based in Bangkok and provides PEGASUS production management and energy management systems, MES, IoT, FA, and AI to the Thai and ASEAN sites of Japanese manufacturers. We are equally happy to talk even at the evaluation stage, including “we haven’t settled on a direction internally yet” or “we just want to know where other companies started”. Send us your current equipment configuration and the specific difficulty you are facing through the contact form, and we will work through the feasible routes and how to frame the rough numbers with you.

References

• GXO, “IoT Data Platform and Visualisation Development Costs (2026 edition)” https://gxo.co.jp/column/iot-data-platform-visualization-development-cost-2026
• is-prime, “IoT Monitoring for Factories” https://is-prime.co.jp/tech-blog/iot-factory-monitoring/
• OPTiM, “Smart Factory Guide” https://www.optim.co.jp/media/cat-guide/sgp_260617-01
• ReliaMag, “The Cost of Unplanned Downtime in Manufacturing” https://reliamag.com/articles/cost-unplanned-downtime-manufacturing/
• Manufacturing Lead Generation, “Manufacturing Downtime Statistics” https://manufacturingleadgeneration.com/manufacturing-downtime-statistics/
• L2L, “How to Improve OEE” https://www.l2l.com/blog/improve-oee
• HiveMQ, “IIoT Protocols: OPC UA, MQTT and Sparkplug Comparison” https://www.hivemq.com/resources/iiot-protocols-opc-ua-mqtt-sparkplug-comparison/
• FlowFuse, “OPC UA vs MQTT” https://flowfuse.com/blog/2026/01/opcua-vs-mqtt/
• iFactory, “Connected Machine Architecture for Legacy and New Equipment” https://ifactoryapp.com/greenfield-consulting/connected-machine-architecture-legacy-new-equipment
• EmployerRecords, “Thailand Minimum Wage” https://employerrecords.com/eor-location/thailand/minimum-wage/
• Employsome, “Minimum Wage in Thailand” https://employsome.com/blog/minimum-wage-thailand/
• CAP Solar, “Factory Electricity Cost in Thailand” https://capsolar.co.th/en/knowledge/factory-electricity-cost-thailand
• CAP Solar, “Thailand Electricity Tariff” https://capsolar.co.th/en/knowledge/thailand-electricity-tariff
• Trading Economics, “Thailand Manufacturing PMI” https://tradingeconomics.com/thailand/manufacturing-pmi
• LexNova Partners, “Thailand Approves Tax Deduction” https://lexnovapartners.com/thailand-approves-tax-deduction/
• Optimum Accounting, “SME 200% Tax Deduction Thailand” https://optimumacc.com/sme-200-percent-tax-deduction-thailand/
• Emerhub, “Thailand’s Renewed BOI Incentives for 2026-2027” https://emerhub.com/thailand/thailands-renewed-boi-incentives-for-2026-2027/
• Pertama Partners, “Thailand BOI Manufacturing” https://www.pertamapartners.com/training/funding/thailand-boi-manufacturing