Real-time machine data is the live stream of state, counts, faults, and process values flowing from every machine into software within seconds of the event. It turns questions answered tomorrow, what ran, what stopped, why, into questions answered now, while there is still time to do something about it.
This guide covers what counts as real-time, which signals to collect, how the data physically gets off machines old and new, and what changes on the floor once it flows. It is the practical companion to our full machine connectivity guide, and it feeds directly into how AI uses machine data, because everything Harmony AI's does starts with this stream.
What counts as real-time machine data?
Real-time means the data arrives fast enough to change the current decision, and for most plant-floor decisions that is seconds to a minute, not milliseconds. Control loops inside the PLC need millisecond response, and they already have it. The gap in most plants is one level up: the supervisor finds out about a 40-minute stoppage at the end-of-shift meeting, the scheduler finds out a line fell behind when the daily report lands. Closing that gap does not require exotic hardware. It requires the machine's existing signals to leave the machine.
It also means the data carries a timestamp from the moment of the event, not from when someone typed it in. Manually logged downtime recorded an hour later is history, not data you can act on. That distinction, event-time versus entry-time, is most of what separates real-time machine data from a paper log typed into a spreadsheet. See real-time manufacturing data for how this applies beyond machines.
Why does real-time matter more than another report?
Because most of the money lost on a plant floor is lost in the gap between an event and a response. A jam that gets attention in two minutes costs two minutes. The same jam discovered at shift end costs the whole run-rate shortfall, plus the scramble to catch up, plus a reconstruction exercise where nobody quite remembers what happened. Downtime reviews built on memory reliably undercount short stops, which is why plants that connect machines are often surprised by what the first honest week of data shows. Our post on machine downtime covers what those minutes actually cost, and the downtime cost calculator lets you put your own numbers on it.
Real-time data also changes the quality of the historical record. When every state change is captured at event time, the daily report writes itself from facts instead of recollections, and the arguments about whose numbers are right mostly stop. The comparison in real-time vs shift reporting walks through that shift in detail.
Which signals should you collect from each machine?
Four families of signals cover most decisions: state, counts, faults, and process values. State tells you whether the machine is running, idle, or down, and it is the backbone of every downtime and utilization number. Counts, good parts, rejects, and cycles, drive throughput and yield. Fault codes with timestamps tell you why the machine stopped without waiting for someone to remember. Process values, temperature, pressure, speed, catch drift before it becomes scrap.
Resist the temptation to collect every tag the PLC exposes on day one. A machine controller may expose hundreds of addresses; a handful move decisions. Start with the four families above on the machines that matter, and add depth when a real question demands it. The methods for getting each signal are covered in machine data collection methods.
How does data get off the machine in real time?
Through whatever interface the machine already has, which is the point: connecting machines is an integration problem, not a replacement problem. Modern equipment usually speaks OPC UA or an industrial Ethernet protocol out of the box. Networked PLCs from the last two decades can be read directly. Older controllers speak Modbus or serial. Equipment with no controller at all, a manual press, an old oven, takes a retrofit sensor: a current clamp, a vibration sensor, a beam counter. All of it converges at an edge gateway that translates protocols, timestamps events, and buffers data when the network drops, then typically publishes upward over MQTT.
The hop that most projects skip is context. A state change that says "Line 3 faulted at 2:14" is a fact. The same fact joined to the work order, the product, the crew, and the last quality check is a decision-ready record. That join is what an AI-native MES does with the stream, and it is why what an AI-native MES connects to matters as much as how.
How do you stand up real-time machine data without a stalled project?
The pattern that works is narrow and fast: one line, real signals, real users, then repeat. The pattern that stalls is a plant-wide connectivity program that proves plumbing for a year before anyone uses the data.
- Pick one line with a problem someone owns. A bottleneck line with disputed downtime numbers is ideal, because the data has a customer on day one.
- Inventory the interfaces. For each machine on the line, note the controller, its protocol, and its network status. This takes a walkthrough, not a study.
- Connect the four signal families. State, counts, faults, process values, through the existing interfaces, with retrofit sensors only where there is no controller.
- Add context. Join the stream to orders, products, and crews so the numbers mean something to the people reading them.
- Put it in front of the crew, live. A screen on the line and alerts to the supervisor. If operators do not see it, the data is already dying.
- Review after two weeks, then standardize. Keep what changed a decision, cut what did not, and roll the recipe to the next line.
Notice what is not on the list: replacing equipment, a new network for the whole plant, or a data lake project. The no-rip-and-replace rule is not a slogan, it is what keeps step one from becoming a capital request. Connecting machines without replacing them goes deeper on the retrofit paths.
What do teams actually do with real-time machine data?
The first payoff is simple visibility: supervisors see the floor without walking it, and short stops stop hiding. The second is honest metrics, because OEE computed from event-time data ends the debate about what availability really was. The third, and the reason this guide exists, is that live machine data is the perception layer for AI. An AI agent watching the stream can notice a downtime pattern, pull the maintenance history, draft the work order, and route it for approval while the shift is still running. What that looks like in practice is the subject of how AI uses machine data and AI agents in manufacturing.
Where does Harmony AI fit? Harmony AI is a truly AI-native MES, and it is completely agnostic to whatever machines and software you already run: the machine stream, the operator records, and the paperwork from every system land unified in one foundation, and AI agents work on top of that combined timeline within guardrails a person sets. Deployment is white-glove and in person, our engineers walk your floor, inventory the interfaces machine by machine, and lay the data foundation on the first line with your team rather than shipping you a box of gateways and a wiki. The platform is then built custom to your factory with AI agentic coding, which keeps the timeline in weeks rather than quarters. You can see the operational results this produced for a family-owned glass decorator in the CLS case study, and the platform itself on the features section of our homepage.
What does the adoption data say?
Two outside reference points are worth keeping in view as you plan:
- AI adoption in industry is still early. The U.S. Census Bureau's Business Trends and Outlook Survey found roughly 17 to 20 percent of U.S. businesses using AI between late 2025 and mid-2026, and Federal Reserve analysis of the same data shows manufacturing running below the national average. A plant that gets its machine data flowing now is building the prerequisite most of its industry still lacks.
- For governing what runs on top of the data, the NIST AI Risk Management Framework organizes the work into four functions, govern, map, measure, and manage, a useful checklist once AI starts consuming your stream.
Read those together and the message is plain: the data layer is the unglamorous part, and it is the part that decides whether anything intelligent can happen later. Start with one line, four signal families, and a crew that can see the numbers move.