Every tag Spall captures arrives with an address and, often, a name someone typed into a PLC program years ago. Neither one tells a dashboard what the value means. A tag named DB12.DBD4 is meaningless to a KPI. A tag named PartCount is more readable, but a dashboard still doesn’t know it’s a part count until a person says so. That confirmation, assigning the tag a role, is what connects a raw reading to availability, downtime, production, and every alert built on top of them. This guide covers the handful of roles that matter most, and why the role does the real work the tag’s own name never could.
Unclassified until someone says otherwise
Every tag Spall captures is auto-created as a measurement the moment it’s first seen, and it starts life unclassified, quarantined from every KPI, alert, and machine-learning feature until a person confirms what it is. That’s a deliberate default, not a missing step. A raw register full of numbers, with no confirmed meaning behind it, can’t safely feed an OEE calculation as though it were trusted data, and a wrong guess baked into a dashboard is harder to catch than a “not yet classified” label sitting in the Signal inbox.
The Signal inbox is where that backlog gets worked, one decision per row: the tag’s name, its unit, and quick buttons for the roles you’ll reach for most, Sensor reading, Run/stop signal, Part counter, Setpoint, plus a More dropdown for the rest. Select several rows at once when a whole device’s worth of freshly wired tags shares one role, a bank of pressure sensors, say.
The roles that carry the most weight
Run state. The single most load-bearing role in the whole vocabulary. A tag marked as run state is what splits every hour into running, idle, and down, the foundation availability and the Pareto of downtime reasons are both built on. Whether it comes from a native control’s run bit, a PLC state flag, or a dry contact wired to a relay, the role is identical once assigned.
Counter. A part counter drives target-vs-actual by shift and job. Be specific about which counter you’re pointing at when a machine keeps more than one. A lifetime total and a per-shift total answer different questions, even though both are legitimately “a counter.”
Setpoint, process variable, and manipulated variable. These three show up together on anything running a real control loop, a temperature, a pressure, a speed being held to a target. A setpoint is the target value someone or something told the loop to hold. A process variable is what’s being measured, the real-world value the loop is trying to steer toward that target. A manipulated variable is the output the controller is adjusting to close the gap between the two, a valve position, a drive command, a heater duty cycle. Tag all three the same way, a bare number, and a dashboard can’t tell a target from a reading from an output. Name the role, and a chart can finally show how closely reality tracked the target.
Alarm and alarm code. A plain alarm role captures that something’s wrong right now, usually a boolean or a short state. An alarm code goes further where the machine reports one, carrying which specific fault fired, worth its own role because a Pareto of alarm codes answers a different question than “is anything alarming at all.” A stack light’s red segment or a door interlock, covered in its own guide, is the plain-alarm case: a state without a code behind it.
Sensor. The generic catch-all for a reading that’s real and worth keeping but doesn’t fit a more specific role: a temperature, a vibration reading, something descriptive on its own, not a KPI driver. Not every tag needs a sharper role than this, and forcing one onto a value that’s just a sensor reading doesn’t make the data more useful.
Tool or program number, and cycle time. A machine-native value like a running program number, a mold code, or a recipe name gets its own role because it’s how a job or product gets recognized automatically, with nobody typing it in by hand each time. Cycle time is its own role too, distinct from a raw counter: a per-cycle duration, not a running total.
Load and override. A load reading, a spindle load, a motor load percentage, is a process value worth its own role when it’s specifically the kind of number a maintenance or process engineer watches for drift over time, distinct from a generic sensor reading. An override is a value representing a manual adjustment layered on top of a program’s own commanded value, a feed override dialed back by an operator, worth tracking separately from the program’s original intent.
Why the role, not the tag name, is what matters
A tag named PartCount that’s never been classified is functionally identical, from a KPI’s point of view, to one named Tag_4471 that’s never been classified either. Both sit quarantined regardless of how descriptive the underlying name is. Conversely, a poorly named tag with the counter role correctly assigned feeds target-vs-actual exactly the way a beautifully named one would. The name is for a human reading a tag list. The role is what a dashboard, an alert, or a model consumes. Treat the two as separate jobs. A good name has not already done the second one’s work.
This matters more on a plant with several kinds of machines than it does on one. A Siemens PLC’s DB address, a FANUC parameter number, and a stack light’s dry contact have nothing in common as raw tag names, one’s a byte offset, one’s a numeric code, one’s a physical wire. Once each is assigned the same role, run state, say, they all feed the exact same availability calculation the exact same way. The role is what lets a dashboard built for one machine work unchanged on the next one, regardless of what protocol or brand happens to be behind it.
Catch a wrong role early. The fastest check is watching the number after classifying it. Don’t trust the assignment on sight. A tag marked run state that never reflects the machine running, because it was wired to something else, produces a wrong availability number that looks plausible until someone compares it against what the floor did that shift.
Quick recap
- Every tag starts unclassified and quarantined from KPIs, alerts, and machine learning, regardless of how descriptive its underlying name is
- Run state is the most load-bearing role. It splits every hour into running, idle, and down
- Setpoint, process variable, and manipulated variable are three separate roles on the same control loop, target, reading, and output
- Alarm and alarm code are separate roles, one says something’s wrong, the other says specifically what
- Sensor is the catch-all for a real reading that doesn’t need a sharper role
- A tag’s name is for a person reading a list. Its role is what feeds a KPI, an alert, or a model