---
title: "What IoT machine data adds to an MES"
description: "An MES is only as accurate as its machine data. Measured stops and part counts replace typed-in ones, so its downtime and OEE factor split come out right."
category: "Machines and connectivity"
author: "Mahmoud Parto"
published: "2024-08-10"
updated: "2026-10-20"
source_url: "https://www.iotflows.com/blog/manufacturing-excellence-with-mes-and-iot/"
---
> Question: How does IoT machine data improve an MES?

## Key takeaways

- An MES plans and records production, but its downtime, performance and OEE figures are only as good as the machine data feeding it.
- Operator-entered stops miss short stops, which moves lost time from availability into performance and points the team at the wrong problem.
- Machine data reaches an MES three ways: operator entry, a controller connection, or a sensor mounted on the outside of the machine.
- Use controller data where you need alarms and program names, and sensors to cover machines with old, closed or unnetworked controls.
- Agree on one definition of running, one shift calendar and one owner for downtime reasons before connecting machine data to the MES.

IoT machine data improves an MES by replacing the machine facts people type in with facts measured on every machine: when it ran, when it stopped and how many cycles it completed. The MES keeps doing its own job, dispatching orders and recording each run. Its downtime, performance and OEE figures then rest on measured time instead of an end-of-shift estimate.

This article is for plant managers and engineers who run an MES, or are choosing one, and want to know what sensors and machine connections add. It works through one shift on a hypothetical CNC mill, logged both ways.

## What an MES does

> **Definition.** **MES (manufacturing execution system)** is software that runs manufacturing operations on the shop floor: it dispatches orders to work centers, tracks each job through its routing, and keeps the record of what was made, when, by whom and to what quality.

ISA-95, the standard for connecting business systems with plant control, places MES at Level 3, manufacturing operations.[1] PLCs and other controls sit below it at Level 2, and the ERP sits above it at Level 4. The standard primarily deals with the interface between Levels 3 and 4: orders going down and results coming up.[1] [Connecting machine data to your ERP](/blog/connect-machine-data-to-erp/) covers the same interface without an MES.

That interface is where the machine data question starts. The ERP sends the MES an order for 200 brackets, and the MES has to know which machine is free, how fast it runs and why it stopped. ISA-95 defines the activities at each level, not the technology that carries data between them.[1]

## Where an MES gets its machine data

Every MES screen that shows machine state draws on one of three paths. Each one starts at the same machine and ends at Level 3.

Figure: A stack from the machine at Level 0 to the ERP at Level 4. Three paths carry machine data up into the MES at Level 3: operator entry, a controller read over a protocol, and a sensor mounted on the outside of the machine, which is highlighted.

*Three paths carry machine data into the MES; the ERP exchanges orders and results with it.*

- **Operator entry.** The operator records job start, stops and counts on a terminal. It works on any machine, and its resolution is what a person notices and remembers.
- **Controller connection.** The MES or a gateway reads the machine's control over a protocol such as MTConnect or OPC UA, a platform-independent architecture the OPC Foundation released in 2008.[3] Most legacy machines, those built without MTConnect output, need a computer to act as the adapter that translates their data to the standard.[2]
- **Sensor on the machine.** A sensor mounted on the outside reads vibration, sound or a beam broken by each part, and decides running or stopped from that physical signal. It needs no connection to the control.

[MTConnect, OPC UA and Modbus compared](/blog/machine-communication-protocols/) explains what each protocol carries and when a machine needs one.

## What typed-in machine data misses

[Operator entry](/blog/manufacturing-data-collection/#manual) captures the stops long enough to remember: a tool that wasn't ready, a pallet of blanks that hadn't arrived. It misses the two- and three-minute stops between them, because nobody walks to a terminal to log a 150-second wait for a crane.

#### Worked example: One shift on a Haas VF-2, logged two ways

- Shift: 480 minutes with a 30-minute break, so planned production time is 450 minutes.
- Logged by the operator: a 25-minute wait for a tool and a 20-minute wait for material, 45 minutes in all.
- Measured by a sensor: the same two stops, plus 18 short stops of 2.5 minutes each, another 45 minutes.
- Ideal cycle time: 4 minutes. Parts made: 85, of which 83 are good.

From the operator log, run time is 450 − 45 = 405 minutes. Availability is 405 ÷ 450 = 90.0% and performance is (85 × 4) ÷ 405 = 84.0%.

From the sensor, run time is 450 − 90 = 360 minutes. Availability is 360 ÷ 450 = 80.0% and performance is (85 × 4) ÷ 360 = 94.4%. Quality is 83 ÷ 85 = 97.6% either way.

**Result:** OEE = (340 ÷ 450) × (83 ÷ 85) = 73.8% in both records

Figure: Two timelines of the same 450-minute shift. The operator log shows two stops totaling 45 minutes and 90.0% availability. The sensor record shows those two stops plus 18 short stops, 90 minutes in all, and 80.0% availability.

*The same shift, logged by hand and measured by a sensor. Sample data.*

OEE is the same in both records, because availability times performance always equals ideal output over planned time. What changes is the split. The typed record says the machine runs 16% slow when it runs; the measured record says it runs close to its ideal cycle and stops 18 more times a shift.

> **Same OEE, different problem**
>
> A team reading the typed record works on feeds, speeds and programs. A team reading the measured record goes after the 18 short stops, such as waits for the crane. Only the second team recovers the hidden 45 minutes, so check the factor split before you assign the work.

The factor definitions behind this example are in [how to calculate OEE](/blog/how-to-calculate-oee/). In a monitoring system, availability is reported as [uptime](/docs/get-started/glossary/#uptime), running time over running plus stopped time.

## Controller data or a sensor?

Both measured paths remove the guesswork from stops. They differ in what else they can tell the MES, and in what it takes to connect them.

| | Operator entry | Controller connection | Sensor on the machine |
|---|---|---|---|
| Works on any machine age | Yes | No | Yes |
| Records every short stop | No | Yes | Yes |
| Counts parts automatically | No | Yes | Yes |
| Reads alarm codes and programs | No | Yes | No |
| Connects to the machine's control | No | Yes, IT usually reviews it first | No |

Most legacy machines built without MTConnect output need an adapter computer before an MTConnect connection works.

Choose controller data when:

- you need alarm codes, program names or process values in the MES, not only running and stopped;
- the machines have networked controls and IT has approved the connection, since a connection to the control is a security concern for many plants.

Choose a sensor on the machine when:

- the fleet mixes brands and ages, and some controls are old, closed or not on the network;
- you need every machine reporting within days rather than after a connection project.

For a mixed fleet, default to a sensor on every machine and add controller data where the extra signals pay for themselves.

Whichever you use, write down what "running" means for each machine type. A control reports what it is executing; a sensor reports what the machine physically does.

## Cover every machine, not only the networked ones

An MES that reads only the machines with modern controls has a partial picture, and the gaps fall in the wrong places. Older machines are often the ones feeding everything else.

For example, take a cell with five networked CNC mills fed by a bandsaw and two manual lathes. The MES reads the mills and nothing else. When the saw stops for 40 minutes, all five mills run out of blanks, and the MES logs five 40-minute stops on the mills with no cause it can see.

[Measured on every machine](/blog/production-line-monitoring-without-plcs/#first-stop), the same morning reads differently: one 40-minute stop at the saw, and five mills waiting on it. The fix moves from the mills to the saw. You don't need more controller connections on the mills to see this; you need any machine signal at all from the saw.

## Connect machine data to the MES

Machine data reaches an MES as events: a stop started, a stop ended with its reason, a part counted. Map each MES function to the events it needs before choosing how to send them.

| MES function | Machine data it needs | Without it |
|---|---|---|
| Dispatching | Which machines are running now | Dispatch by phone or a walk |
| Performance analysis | Run time and part counts | End-of-shift estimates |
| Downtime analysis | Every stop, with start, end and reason | Only stops someone logged |
| Job and labor tracking | Run time matched to each job | Clock time stands in for run time |
| Maintenance hand-off | Stops and alarms per machine | Requests by word of mouth |

1. **Define running for each machine type.** Agree whether a mill with the spindle turning and no cut counts as running, and apply the same rule in both systems.
2. **Use one shift calendar.** Load the same shifts, breaks and timezone into the monitoring system and the MES, so a stop at 06:58 falls in the same shift in both.
3. **Map machines to work centers.** Give each machine one identifier and map it to its MES work center, so a Haas VF-2 in the monitoring system is the same Haas VF-2 in the MES.
4. **Choose push or pull.** Push events over a webhook or MQTT when the MES reacts within seconds, as dispatching does. Pull totals from a REST API when the MES needs a shift rollup.
5. **Pick one owner for downtime reasons.** Let operators classify stops in one system and send the reason with the stop, instead of asking for it twice.
6. **Check counts against a hand count.** Count ten parts by hand and compare. A count that is exactly double or half points to a quantity-per-cycle setting, as the [part count troubleshooting guide](/docs/production/troubleshoot-part-counts/#double) shows.

## Feed an MES from every machine with IoTFlows

A [SenseAi](/products/senseai/) attaches magnetically to each machine and reads its vibration and sound, with no PLC and no wiring into the controls. It decides running or stopped every second on the device, and the cloud derives uptime, downtime, part counts and cycle times from that record. [How IoTFlows works](/docs/get-started/how-iotflows-works/#on-device) shows where each decision is made.

Operators classify stops in a tap, and an automatic rule classifies [short downtimes](/docs/monitoring/auto-downtime-rules/#short-downtimes). To reach your MES, IoTFlows posts machine events to your own endpoint as [signed webhooks](/docs/alerts/webhooks/#secret), and a REST API returns the same records the dashboard shows. On Enterprise, the [edge device](/docs/get-started/glossary/#edge-device) brings in controller data from the controls you choose to connect.

[MiRus](/customers/mirus/) ties every Epicor job to the machining and labor hours behind it through a two-way connector that went live in about a month.

## Do you need an MES at all?

Machine data makes an MES more accurate, but it doesn't make an MES necessary. You probably don't need one yet if your daily questions are what ran, why it stopped, what to fix and what to make next.

You need an MES when a customer or regulator asks for a complete record of every run, every operator and every inspection. [Machine monitoring vs MES vs CMMS](/compare/machine-monitoring-vs-mes-vs-cmms/) compares the three systems and which one to put in first.

## Questions

### Does an MES need a PLC connection to get machine data?

No. An MES can take machine state and part counts from operator entry, from a controller connection, or from sensors mounted on the outside of each machine. Many plants mix them, with controller data where alarms and program names matter and sensors on machines whose controls are old, closed or not on the network.

### Which system should own downtime reasons?

Pick one. If operators classify stops at the machine in the monitoring system, send the reason to the MES with the stop instead of asking for it a second time. Two places to enter a reason produce two different answers, and someone then spends every Monday reconciling them.

### Does sensor data change the OEE number in the MES?

Often not the total. Availability times performance equals ideal output over planned time, so short stops the MES never saw move from availability into performance while OEE stays the same. What changes is which factor looks low, and so which problem the team spends its week on.

## Sources

1. [ISA-95 Standard: Enterprise-Control System Integration](https://www.isa.org/standards-and-publications/isa-standards/isa-95-standard), International Society of Automation (ISA), accessed Oct 16, 2026
2. [Digital Manufacturing for Legacy Equipment Using a Standards-Based Approach: An MTConnect Use Case](https://www.amtonline.org/article/digital-manufacturing-for-legacy-equipment-using-a-standards-based-approach), AMT, The Association For Manufacturing Technology, accessed Oct 16, 2026
3. [OPC Unified Architecture](https://opcfoundation.org/about/opc-technologies/opc-ua/), OPC Foundation, accessed Oct 16, 2026