IoT in Manufacturing: How Connected Plants Cut Downtime and Raise OEE

What is IoT in manufacturing, and what does it change for an operations lead?

Industrial IoT (IIoT) is the industrial subset of the Internet of Things: sensors and controllers on production assets, connected to a network and to software, so their data can be collected, analyzed and acted on. A smart factory is a plant where that data drives maintenance, scheduling and quality decisions during the shift rather than through end-of-shift paperwork. Industry 4.0 is the wider program of digitizing manufacturing that IIoT belongs to. The distinction between IoT, industrial IoT and Industry 4.0, and the technical hurdles that separate industrial IoT from consumer IoT, is set out in Sisinni et al., IEEE Transactions on Industrial Informatics, 2018.

For an operations lead, the technology matters less than the argument it changes. Today the shift log says the filler stopped for 40 minutes and the reason box says "mechanical". Maintenance runs on calendar intervals because nobody measures bearing condition. OEE arrives in a spreadsheet three days late. IoT in manufacturing replaces those estimates with measurements, so the daily meeting argues about what to fix rather than whose number is right.

• Unplanned downtime costs Fortune Global 500 industrial companies about $1.5 trillion a year, 11 percent of revenue, and a lost hour ranges from $39,000 in fast-moving consumer goods (FMCG) plants to over $2 million in automotive, according to the Senseye True Cost of Downtime 2022 report published by Siemens.
• Predictive maintenance can raise equipment uptime by 10 to 20 percent, cut maintenance costs by 5 to 10 percent and cut maintenance planning time by 20 to 50 percent, per Deloitte, Making Maintenance Smarter, 2017.
• McKinsey reports that 30 to 50 percent reductions in machine downtime and 10 to 30 percent increases in throughput are not uncommon when Industry 4.0 solutions are implemented well, while a large majority of manufacturers remain stuck in pilot purgatory (McKinsey, 2022).
• World Economic Forum Global Lighthouse Network sites raised OEE by 5 to 10 percent on average, and about 75 percent of them paired technology with a talent program (WEF, July 2024).
• OEE is availability multiplied by performance multiplied by quality. Mean time between failures (MTBF) and mean time to repair (MTTR) are defined in the SEMI E10 standard, and the two sets of metrics should be read together.

What data does a plant already have before it buys a single sensor?

Most plants are data rich and insight poor. Before anyone specifies hardware, inventory what the line already produces every shift:

• Programmable logic controller (PLC) tags: machine state, counts, speeds and fault codes, updated many times a second and mostly never stored.
• Supervisory control and data acquisition (SCADA) alarms and events, often in a local historian nobody queries after the shift.
• Computerized maintenance management system (CMMS) work orders: what broke, what was replaced and how long the repair took, the raw material for MTBF and MTTR.
• Enterprise resource planning (ERP) production orders: planned quantity, actual quantity and the schedule the line was meant to follow.
• Quality laboratory results such as fill weights, Brix and pH, in a separate system with its own clock.
• Utility meters for electricity, compressed air and steam, usually at plant level rather than per line.
• Manual downtime logs and reason codes on clipboards, the only place the "why" currently lives.

Condition monitoring is the practice of measuring an asset’s health indicators, such as vibration, temperature or current draw, continuously or on a route, so that degradation is detected before failure. Much of the data above already describes condition; it is trapped in a controller, a historian or a clipboard. That is why the first IoT project in a plant is usually a data-liberation project: existing PLC tags and stop reasons into one time-series store with a shared timestamp and an asset identifier.

The shared clock matters more than it sounds. On a beverage filling line the filler is usually the constraint. When the packer downstream jams, the filler backs up and stops minutes later. If each machine reports on its own clock, the stop is booked against the filler and the packer never appears in the loss analysis. One clock makes the root cause visible without a new sensor.

Which IoT use cases in manufacturing pay back first?

The ranking below is the usual order of payback for a plant with rotating equipment and a known bottleneck. Reorder it for a different loss profile, but keep the discipline: the use case must move a KPI the plant already reports.

1. Predictive maintenance and condition monitoring on the bottleneck asset

Predictive maintenance is maintenance triggered by the measured condition of an asset and a forecast of when it will fail, rather than by a calendar interval or by breakdown. On the constraint asset every avoided breakdown is throughput the plant would never recover. Two systematic reviews in Computers & Industrial Engineering map the methods: Zonta et al., 2020 on predictive maintenance in Industry 4.0, and Carvalho et al., 2019 on the machine learning techniques applied to it. Both find the modeling side well studied; the practical gap is getting clean, labeled failure data out of the plant.

From the maintenance side, this is total productive maintenance (TPM) with instruments. TPM asks operators to inspect their machines every shift; a vibration sensor on the filler drive makes that inspection continuous and replaces "sounds a bit rough" with a number. MTBF is the average operating time between failures. MTTR is the average time to restore an asset after a failure. Both, with the six equipment states used to classify time, are defined in SEMI E10. A plant that cannot compute MTBF and MTTR from its own work orders is not ready for a failure model, and a threshold rule on vibration usually delivers most of the value before any model exists.

2. Automatic OEE and downtime reason capture

Overall equipment effectiveness (OEE) is a TPM measure of how effectively equipment is used, calculated as availability rate multiplied by performance rate multiplied by quality rate, where availability captures downtime losses, performance captures speed losses and minor stoppages, and quality captures scrap and rework (Lean Enterprise Institute lexicon). For semiconductor and related industries the measurement rules are formalized in SEMI E79. Machine signals compute availability and performance automatically from run state, good count and reject count. They cannot capture the reason. The decision that makes OEE useful is a reason-code prompt at the line that fires when a stop exceeds a threshold and asks the operator to pick from a short list.

A warning from the plant floor: OEE should not be the only KPI. A line can post a higher OEE by running a non-bottleneck machine faster and piling up work in process while the constraint produces nothing extra. Report OEE beside bottleneck throughput, MTBF and MTTR, so a gain in one number that costs another is visible. Good manufacturing analytics is that set of numbers on one screen, not a bigger OEE gauge.

3. Energy monitoring per line

Plant-level utility bills hide the losses. Sub-metering electricity, compressed air and steam per line, on the same clock as machine state, exposes the usual wins in a beverage plant: equipment left running through changeovers, compressed-air leaks that grow between audits, and chillers held at setpoint for product that is not coming. An energy management system built to ISO 50001 requires exactly this measure, baseline and improve loop; the United States Department of Energy runs a no-cost 50001 Ready program around it. A 2025 simulation study of an IoT-enabled manufacturing framework reported an 18 percent reduction in energy consumption and a 22 percent decrease in machine downtime (Alex and Johnson, arXiv 2502.03040); treat those as modeled figures rather than field results.

4. Quality and traceability, especially in food and beverage

IoT in food and beverage manufacturing has a compliance payback that discrete manufacturing does not. Pasteurizer temperatures, clean-in-place (CIP) cycle times, cold-room readings and fill weights are measured today, mostly on paper forms. Logging them automatically against the lot being produced makes the quality record queryable. In the United States, the FSMA Section 204 traceability rule requires firms handling foods on the Food Traceability List to keep Key Data Elements for Critical Tracking Events such as shipping, receiving and transformation, linked to a traceability lot code, and to hand records to the FDA within 24 hours of a request, with enforcement from July 20, 2028 (FDA, FSMA 204 final rule). A plant that captures process data per lot answers that request with a query rather than a week of binders.

How is an industrial IoT system layered, in plant terms?

Every plant already has a hierarchy for its systems. The ISA-95 standard, published internationally as IEC 62264-1, describes integration between the manufacturing operations and control domain (Levels 3, 2 and 1) and the enterprise domain (Level 4). In plant terms, Level 1 is sensing on the machine, Level 2 is the PLC and SCADA, Level 3 is a manufacturing execution system (MES), and Level 4 is ERP. IoT does not replace that stack; it adds a data path alongside it, in four layers.

• Sensors and controllers. Existing PLC tags first, then added sensors for the gaps: vibration on critical drives, temperature and current on motors, flow and pressure on utilities.
• Edge. A gateway beside the line that reads controller protocols such as OPC UA and Modbus, timestamps and buffers the data, and runs simple rules locally so a lost network link does not lose a shift of data. This is the base of the five-level cyber-physical systems architecture in Lee, Bagheri and Kao, Manufacturing Letters, 2015.
• Platform. A time-series store, a message broker, the OEE and MTBF calculations, any failure models, and integrations into the CMMS and ERP so an alert can become a work order.
• Applications. Dashboards for line leads and plant managers, mobile apps for operators and technicians (reason codes, work orders, alerts) and scheduled reports. This layer is most often custom software, because every plant’s KPIs and workflows differ.

Security runs across all four layers. Operational technology (OT) networks were never designed to be reachable from a cloud dashboard. The NIST Guide to Operational Technology Security, SP 800-82 Rev. 3 and the ISA/IEC 62443 series set the expectations: segment the control network from the business network, define zones and the conduits allowed between them, and assign security responsibilities to asset owners, integrators and product suppliers. The practical rule is one sentence: data flows out of the control network through the edge; commands never flow into a PLC from the dashboard.

Sigi Technologies builds the platform and application layers of that stack: data pipelines from the edge into a time-series store, OEE and maintenance dashboards, CMMS and ERP integrations, and operator and technician mobile apps, through its custom software development service and mobile app development service. Sensors, gateways and PLC programming stay with the automation vendor or in-house controls team, and Sigi has not deployed a factory IoT system of its own. Its closest work is the Muzziball companion app, a UX design engagement for the mobile control surface of a connected sensory device, which shares the pairing and device-state patterns an operator app needs.

How do you start IoT in a plant without ending up in pilot purgatory?

McKinsey names five reasons Industry 4.0 pilots stall, and two are the operations lead’s to prevent: a technology-first rollout with no link to value, and "letting the perfect defeat the good" by waiting for an ideal IT/OT architecture (McKinsey, 2022). The remedy is a minimal viable architecture on one line, measured against a baseline, then copied. The sequence that works:

1. Pick the constraint line and one KPI. Unplanned downtime minutes on the bottleneck asset is the usual choice because it converts directly to cases not produced.
2. Baseline it manually for four weeks from existing shift logs and work orders, so the pilot has a before number nobody can dispute.
3. Inventory the data already in the PLC and SCADA. Add sensors only for the gaps, typically vibration on the drives whose failure stops the line.
4. Install one edge gateway, stream the tags to a time-series store with an asset identifier and a shared timestamp, and confirm the data survives a network outage.
5. Build one dashboard and one alert, with a named owner and a written response: who checks, who repairs, within how long.
6. Add reason-code capture at the line on a tablet, so every availability loss has a cause the morning meeting can act on.
7. Run for 8 to 12 weeks, compare against the baseline, and write the payback in downtime hours and cases.
8. Scale by copying the same template to the next line. Resist adding features to the first line until the second is live.

What does the software layer typically cost?

Sensors, gateways and controls work are quoted by the automation vendor. The software layer scopes like any custom product. Sigi does not publish client invoices; the bands below are typical-scope planning estimates for a professional custom team, reused from Sigi’s guide to how much it costs to build a mobile app, and cover software only.

On timing, treat 8 to 12 weeks for a pilot-line software layer as a planning estimate, after the manual baseline has run. Plant rollouts are paced by network segmentation approvals, not by software.

What goes wrong with IoT in manufacturing projects?

• Dashboards with no decision owner. If nobody is named to act when a metric moves, the screen becomes wallpaper within a quarter.
• Skipping reason codes. Automatic availability without operator-entered causes says how much time was lost and nothing about why.
• Data locked in a vendor cloud. Machine data belongs to the plant. Require an export path and a documented schema before signing a platform contract.
• Leaving operators out. About 75 percent of Lighthouse sites paired technology with a talent program; a reason-code tablet nobody was trained on captures nothing.
• No baseline. A pilot without a before number cannot prove payback, and a pilot that cannot prove payback is not funded to the second line.

Related reading

For another operations system built around one shared record, read the guide to how to build a warehouse management system, which draws on the 3DLogistiX warehouse platform case study. If several plants will share one platform, the guide to multi-tenant SaaS architecture covers tenancy and data isolation. The guide to how much it costs to build a mobile app explains the cost bands used above, and the Muzziball companion app case study shows device-pairing and live-control patterns for a connected product. To scope the software layer of an IoT program, see Sigi’s custom software development service or get in touch.