What machine signals should I collect first?

Run state, part count, rate, and fault code, in that order. Run state gives you honest downtime tracking, counts give you output against plan, rate exposes slow running, and fault codes explain machine-detected stops. These four support downtime logs, OEE, and live dashboards on almost any machine.

Why is collecting every PLC tag a bad idea?

Because unmapped, unnamed tags with no consumer cost mapping effort, storage, and attention while answering nothing. Teams that archive everything typically discover their real questions needed a handful of signals plus context. Start with signals that answer known questions and add more one question at a time.

Can I get these signals from a machine without a modern PLC?

Usually yes. A clamp-on current sensor infers run state from the motor circuit, a photo eye counts parts at discharge, and rate is computed from counts over time. Fault codes are the exception; without a PLC, the operator supplies the reason through a prompt instead.

What is the difference between run state and availability?

Run state is the raw signal: running or stopped at each moment. Availability is a metric computed from it: run time divided by planned production time over a period. Clean run state data with accurate timestamps is what makes the availability number in your OEE trustworthy.

Why do fault codes alone not explain downtime?

A fault code reports what the machine detected, such as a jam or a guard open, but not the underlying cause, like a bad batch of packaging film or a crew pulled to another line. Pairing the code with an operator-entered reason at the moment of the event gives you both precision and cause.

How many signals per machine is normal?

There is no single right number, but a useful range for operations is four to eight well-chosen signals per machine: the core four plus a product identifier and one or two critical process values. Condition monitoring on key assets adds a few more. What matters is that every signal has a named consumer.

Do I still need a historian if I only collect a few signals?

You need history, not necessarily a traditional historian project. The short list generates modest data volumes that any modern operations platform can store for years. What matters is that history is queryable in operational terms, by line, shift, product, and reason, not just as raw tag archives.

Machine Signals That Matter

Four signals per machine answer most of the questions a plant actually asks. Here is the short list, and why it beats collecting everything.

The machine signals that matter most are the four that answer a supervisor's daily questions: run state (is the machine running), part count (what did it make), rate or speed (how fast is it going), and fault code (why did it stop). Nearly everything a plant does with machine data, downtime tracking, OEE, live boards, improvement Paretos, is built on these four.

That claim sounds too simple, so it is worth defending. A modern PLC can expose thousands of tags; a plant-wide historian can archive tens of thousands of points. And yet when you look at what actually changes decisions on a plant floor, downtime response, schedule adjustments, maintenance calls, shift reviews, the inputs are almost always some combination of those four signals plus human context. This post makes the case for the short list, explains what each signal gives you, and shows how to grow beyond it without drowning.

Why Not Collect Every Tag the PLC Offers?

Because collection is cheap and attention is not. Storage costs almost nothing; the expensive parts are mapping, naming, contextualizing, and above all consuming the data. Every tag you collect without a consumer is inventory: it takes up space, requires maintenance, and produces nothing. Plants that point a collector at the whole PLC and archive everything end up with what we would call a 10,000-tag dump: an enormous historian database in which nobody can find the running state of line 3 because it is called N7_40_B12 and sits next to nine internal logic bits nobody can identify either.

The dump has a second cost: it postpones the useful work. Teams spend months on the collection project, declare victory when data flows, and only then discover that the questions they cared about need four signals, a naming convention, and operator context, none of which the dump provided. The short list inverts this: pick the signals that answer known questions, get them clean and consumed, and let real questions pull new signals in later.

To be clear, this is not an argument against history or against historians as a class of tool. Process industries with genuine regulatory or process-engineering needs for dense data have good reasons to archive more. The argument is about sequence: for the operational questions most plants are trying to answer first, is it running, what did it make, why did it stop, breadth of collection adds cost without adding answers. Collect deep on the few signals that matter before collecting wide on the ones that might.

The dump archives everything and answers nothing. The short list collects four named signals and wires each one to a consumer.

What Are the Four Signals That Matter?

In order of value, with what each one buys you:

Run state. A single bit: running or not. It is the foundation of downtime tracking, availability, and every honest conversation about what happened last shift. If a machine gives you nothing else, get run state; even a current clamp can infer it on a machine with no PLC.
Part count. Good count and, where the machine knows it, reject count. Counts turn "we ran all day" into "we made 14,200 units, 300 short of plan." Counts feed performance and quality in the OEE calculation, and they end the end-of-shift arithmetic ritual.
Rate or speed. Units per minute, cycles per hour, line speed. Rate exposes the quietest loss in most plants: the machine that runs all shift at 80 percent of standard. Downtime is visible; slow running hides unless you measure rate against standard.
Fault code. When the machine stops itself, the code says why, jam, guard open, low air, upstream starve. Fault codes pre-fill the first half of the downtime story so the operator only adds what the machine cannot know. They are the raw material for the Pareto that drives improvement work.

Two supporting signals earn a place on many machines: product or recipe identifier, which tells you what was running (essential context for rate standards and changeover analysis), and a critical process value where quality depends on it, an oven temperature, a press tonnage, a torque reading. But these are additions to the four, not replacements.

What Can You Actually Do With Four Signals?

More than most plants do with a full historian. Run state plus timestamps gives you an honest downtime log, automatically, with no operator arithmetic; that alone changes shift reviews, as covered in machine downtime. Add counts and rate and you can compute real OEE from source data rather than estimates; run your own numbers with the OEE calculator. Add fault codes and your downtime Pareto builds itself, so improvement work aims at the biggest verified loss instead of the loudest anecdote.

The four signals also power live visibility. A floor dashboard needs exactly these: which machines are running, what they have made against plan, how fast they are going, and what the stopped ones are stopped for. That pipeline is the subject of from machine data to live dashboards.

Walk through one concrete week to see the leverage. Monday, the run-state log shows line 2 lost 96 minutes across eleven micro-stops, a pattern nobody had noticed because each stop was under ten minutes and none made it onto paper. Wednesday, rate data shows the same line running at 82 percent of standard on one product family, which turns out to be a worn feed belt that only slips under the heavier bottle. Friday, the fault-code Pareto puts discharge jams at the top for the third straight week, and the improvement meeting finally has a target with a measured cost attached instead of a debate. None of that required advanced analytics or a data science team. It required four clean signals, honest timestamps, and someone looking at the result. Plants often find their first month of short-list data pays for the connectivity project on its own, because the losses it exposes were invisible on paper; you can put your own numbers on that with the downtime cost calculator.

What Do the Four Signals Miss Without Human Context?

The why behind the why. A fault code says "jam"; it does not say "the new film supplier's rolls are wound too tight." Run state says the machine stopped for 40 minutes; it does not say the crew was pulled to cover another line. The machine's version of events is precise but shallow. The operator's version is deep but, on paper, disconnected and late.

The fix is to join them at the moment the event happens: a machine-detected stoppage automatically opens a reason-code prompt on the operator's screen, and the human answer lands in the same record as the machine timestamps. That join, the signature move of a connected operations layer, is covered in connecting machines and paperwork, and it is how the short list punches far above its weight. Four signals plus one honest human sentence per event beats ten thousand tags with no story attached.

The machine supplies exact timestamps and the fault code; the operator supplies the reason the machine cannot know. Joined at the event, they make one trustworthy record.

How Do You Grow Beyond the Short List?

First, get the four signals trustworthy, because dirty signals are worse than none. Debounce run state so a three-second blip does not log as a downtime event; most plants ignore stops under a threshold like 30 to 120 seconds or roll them up as micro-stops. Verify counts against a physical count for a shift before anyone builds a report on them. Confirm fault codes are current; machines that have been modified over the years often throw codes that no longer mean what the manual says. An afternoon of verification buys years of trust.

Then grow one question at a time. When someone asks "why does the filler lose speed every Friday," that question justifies collecting a few more process values on the filler. When maintenance wants early warning on the compressor, that pulls in a vibration or pressure signal, connected the way described in connecting sensors to operations. Signals added this way arrive with a consumer built in, which is exactly what the dump never has.

Whatever you add, keep the naming and context disciplined from day one: every signal gets a plain name and an address in the plant hierarchy, so Line3/Filler/RunState is legible to everyone forever. The conventions are in our PLC tag mapping guide. This is also where standards help: the ISA-95 standard defines the enterprise, site, area, work center, work unit hierarchy that gives signals their place, and OPC UA (IEC 62541) defines how machines can expose signals with units and metadata attached rather than as anonymous registers. Ranges vary by plant, but a connected machine with four to eight well-chosen, well-named signals is a working asset; the same machine with a thousand raw tags is a liability wearing a project badge.

Where Does Harmony AI Fit?

Harmony AI's machine connectivity work starts from the short list on purpose. During a white-glove deployment our engineers walk each line with your team, identify what every machine can give up, run state, counts, rate, faults, whether from the PLC or a retrofit sensor, and wire each signal into live boards, downtime prompts, and records your crew already uses. Machines are read, not replaced, no rip-and-replace, and the paperwork that used to carry the context moves into the same layer as the machine data. You can see what that produced for one plant in the CLS case study: live visibility into output and downtime, built on exactly this kind of source data.

Start with four signals per machine. Name them well, wire every one to a consumer, and let real questions, not tag counts, drive what you collect next.