IoT in Manufacturing

What is IoT in manufacturing?

IoT in manufacturing is the collection of sensor, PLC and historian data on the plant floor, tagged with the machine, line, shift and order it belongs to, and delivered to applications for downtime, quality, maintenance and energy. It covers process data, not only location, and it needs a defined rule for who may write back to equipment.

Locating tools and pallets is one use of plant IoT, but it is a different data path. This guide is about process data: temperatures, pressures, speeds, counts, states and alarms coming off running equipment.

Which standards shape plant IoT?

Five standards and guides shape how plant data is modeled, moved and secured. Using them keeps the design portable across vendors and familiar to plant engineers.

• ISA-95: The ANSI/ISA-95 series, published internationally as IEC 62264, models how manufacturing operations relate to business systems, from equipment control up to enterprise planning. Its equipment hierarchy of site, area, line and cell is a common base for naming plant data.
• OPC UA: The OPC Unified Architecture, standardized as IEC 62541 and maintained by the OPC Foundation, defines a platform-independent way to read and model data from industrial equipment, with built-in security.
• MQTT: OASIS publishes MQTT version 5.0 as a lightweight publish and subscribe protocol, widely used to move plant data from edge gateways to brokers and applications.
• ISA/IEC 62443: The ISA/IEC 62443 series sets requirements and processes for securing industrial automation and control systems, including the zones and conduits model for separating networks.
• NIST SP 800-82 Revision 3: NIST's current guide to operational technology security covers how to connect OT networks to enterprise systems without exposing control equipment.

For new sensors and gateways, NIST IR 8259 Revision 1, published in April 2026, lists the cybersecurity activities a device manufacturer should complete before sale. It gives the purchasing team concrete questions to ask suppliers about updates, identity and support periods.

How does plant data reach an application?

Plant data reaches an application in six steps. The order matters, because an application built on uncontextualized tags produces numbers nobody trusts.

• 1. Inventory: List the machines, PLCs, sensors and historian points in scope, with tag names, units, sample rates and the owner of each source.
• 2. Collect: Read through an OPC UA server, an edge gateway publishing to an MQTT broker, or the existing historian. Avoid ad hoc polling of controllers from office systems.
• 3. Contextualize: Bind each point to its place in the equipment hierarchy and to the order, product and shift active at that moment, usually from the MES or scheduling system.
• 4. Store: Keep time series in a historian or time-series store, and keep events such as stops, alarms and quality holds as records with start, end and reason.
• 5. Build: Deliver the application the users asked for, such as a downtime board, a maintenance work list or a quality traceability view.
• 6. Control: Decide whether the application stays read-only. If it writes, route writes through a controlled interface with limits, confirmation and logging.

Reading from controllers without disturbing them

• Prefer an existing source: If the historian or SCADA system already reads the points, take data from there instead of adding another connection to the PLC.
• Limit request load: Group reads, use subscriptions where the server supports them and agree poll rates with the controls engineer, since older controllers have limited communication capacity.
• Use the server's security: Turn on OPC UA certificates and user authentication instead of anonymous access, and give the collector read-only rights.
• Buffer at the edge: Keep data on the gateway when the uplink drops, and backfill in order with original timestamps.

What does context mean for plant data?

Context is the set of facts that turn a raw value into something a person can act on. A spindle temperature means little until the system knows the machine, the part being cut and the limit for that part.

• Equipment: Where the point sits in the site, area, line and cell hierarchy, with a stable ID that survives a PLC tag rename.
• Production: The work order, product, batch or serial number running when the value was recorded.
• Time: Shift, crew and the machine state at that moment, such as running, idle, changeover or planned maintenance.
• Meaning: Engineering units, normal ranges and the specification limits that apply to the current product.
• Lineage: The source system and any calculation applied, so an engineer can trace a dashboard figure back to the raw point.

Some plants publish this context in a shared namespace on the MQTT broker, organized by the ISA-95 hierarchy, so every application reads the same names. Others keep it in the historian's asset model. Either works if one team owns the tag dictionary and changes go through review.

Which plant applications should come first?

Start with the application that has a clear owner, data already available and a decision it will change. These four are common starting points, each with a different data need.

• Downtime tracking: Machine state signals plus operator reason codes. It needs reliable run and stop states and a fast way for operators to enter reasons.
• Condition-based maintenance: Vibration, temperature, current and run hours linked to the maintenance system, so thresholds create work orders instead of emails.
• Quality traceability: Process values tied to serial or batch numbers, so a quality engineer can see the conditions behind every part in a hold.
• Energy monitoring: Meter data by line and shift, joined with production counts so energy per unit can be compared across products.

Overall equipment effectiveness is often the headline metric, calculated as availability times performance times quality. It is only as good as the state and count signals beneath it, so trusted downtime data usually comes before an OEE dashboard.

Scoping the first application

• Owner: A named person on the floor who will use the application daily and judge whether it works.
• Decision: The specific action it changes, such as which machine maintenance visits first or which lot quality holds.
• Data check: Proof that the needed signals exist, have the right units and match what operators see at the machine.
• Line scope: One line or cell first, built on the same data model the rest of the site will use.
• Success measure: A comparison against the current manual method, agreed before build, without a promised percentage.

Writing back to the line

Write-back is a separate product from read-only dashboards. An application that changes a setpoint, releases a hold or starts a recipe touches the control system, and needs controls of its own.

• Defined scope: A written list of the values the application may write, with upper and lower limits enforced outside the application as well as inside it.
• Controlled path: Writes go through a supervisory interface or an OPC UA method the controls team owns, not direct writes to PLC memory from an office network.
• Confirmation: An operator at the machine confirms changes that affect running equipment.
• Change control: New writable values and limit changes go through the plant's management of change process.
• Audit: Every write records the user, old value, new value, time and reason.
• Network design: The application sits in a zone separated from control equipment, with a defined conduit between them, following the 62443 zones and conduits model.

Where plant IoT programs stall

These failure points stop plant IoT programs between the pilot and the second line. Check for each before scaling.

• Sensors before a data plan: Hardware goes in, but no one has mapped tags, units or owners, so the data cannot be used.
• No context source: Values are collected without order or product, so quality and maintenance teams cannot tie them to their work.
• Tag names as identifiers: A PLC program change renames tags and silently breaks every dashboard built on them.
• Pilot-only architecture: A single gateway and script that worked for one line cannot be repeated across the site.
• Uncontrolled write-back: An office application writes to a controller with no limits, confirmation or log.
• Metric before trust: An OEE target is announced before state and count signals have been checked against the floor.
• No support model: The pilot was run by a project team that has moved on, and nobody on site knows how to add a machine, fix a broken collector or update a threshold.

How Agnotic can help

The hard part of plant IoT sits between the data that exists and the applications people use. Agnotic Technologies builds manufacturing software on plant data: collection through OPC UA, MQTT or the historian, a contextualized data model, and downtime, quality and maintenance applications, with write-back designed alongside the controls team.

Agnotic works with the plant's controls and IT teams rather than around them. The controls team keeps ownership of PLCs and safety systems, and Agnotic builds the collection, context and application layers on top, so the software can be supported after the first line goes live.

Sources

• ISA: ISA-95 standard
• OPC Foundation: OPC Unified Architecture
• OASIS: MQTT Version 5.0
• ISA: ISA/IEC 62443 series of standards
• NIST CSRC: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
• CISA: Industrial control systems