An operator who’s run a machine for years already knows some of its tells. A particular fault code tends to show up a few times before the real jam happens. Spall’s job here is to find that same pattern in the data without anyone having to notice it first, check whether it actually holds up across enough stops to be real, and offer a one-click way to turn it into an early warning.
Two related patterns, one method
Spall mines two kinds of precursor. A numeric one looks at a continuous reading, a temperature, a vibration level, and compares its average in the hours right before a downtime reason’s stops against its normal baseline the rest of the time. An alarm-sequence one looks at discrete alarm codes instead, and asks how often, and how many times, a given code fires in the hours before that same reason’s stops.
Both work the same way underneath: try every combination the asset’s own history offers, and let the floor’s own data decide which ones are real. Nothing is hand-picked in advance. A code that never precedes anything simply never produces a pattern, and it costs nothing to have tried it.
What has to be true before it counts
Both detectors abstain until there’s enough to say something. A numeric precursor needs at least three pre-event windows to compare, and the separation between the pre-event average and the normal baseline has to clear a real effect-size threshold, not just be different by chance. An alarm code needs at least three total occurrences of the reason it’s being checked against, and it has to have actually fired before at least half of them, a code that only sometimes precedes a stop isn’t a pattern reliable enough to page anyone over.
Scrap gets mined the same way, without a second code path. Production records with a real reject or scrap count get reshaped into the same event structure as a downtime stop, so “which alarm precedes scrap on this line” gets answered by the identical logic that answers “which alarm precedes a Tooling stop.”
The trigger it proposes
A precursor finding that clears both bars doesn’t just sit on the Insights feed as trivia. It carries a proposed rule, in the numeric case a threshold set partway between the metric’s normal baseline and its pre-event average, so the alert fires while there’s still time to act, not only right at the historical peak. In the alarm case, the proposal names the code, how many times it typically fires, and the window that repetition happens in, “alarm 1043 twice within 60 minutes.”
Clicking the offer opens the rule-authoring form with every field already filled in from the pattern itself. Nothing about the threshold or the window gets typed from memory, it’s pulled straight from what the data actually showed. From there the rule behaves like any other trigger in Spall: it counts occurrences inside its window, fires once the count is reached, and clears again once the count drops back under it.
Reading the evidence on the card
Every precursor insight states its basis in plain terms right on the card: how many stops the pattern is built from, what the metric or alarm code did in the hours before those stops compared to its normal range, and the friendly name of both the signal and the downtime reason, never a raw tag key or a bare reason code. These cards carry no dollar figure. A leading-indicator pattern is evidence of a relationship, not a measured loss on its own, so attaching a price to it would mean inventing a number nobody could check.
One detail worth knowing: a precursor card doesn’t carry the same “flagged X days ago” aging label an anomaly card does. That’s a deliberate difference, not an oversight. An anomaly card describes something observed in a recent window, so its age matters. A precursor card describes a pattern mined from a machine’s whole history, it isn’t a claim about right now, so there’s no freshness clock running on it the way there is for a live reading.
What this needs from the floor to work at all
Neither detector can mine a pattern out of nothing. The numeric precursor needs downtime events with reason codes attached, since “the hours before a Tooling stop” only means something once stops are actually being labeled Tooling instead of left blank. The alarm-sequence detector needs alarm codes flowing in as their own events too, which on most controllers means a bit-level fault flag, a numeric fault register, or an MTConnect condition level wired up and reporting. None of that is protocol-specific: a boolean alarm bit, a numeric code, and a condition-level string are all just “a code that fired at a point in time” to this feature, so it works the same way regardless of which controller or protocol an asset happens to speak.
A floor that codes most of its stops with a real reason gives both detectors far more to work with than one where most stops sit uncoded. That’s not a configuration step specific to this feature, it’s the same reason-coding discipline that already improves every other part of Spall built on downtime data, and it shows up on the Opportunities page as a context-density figure so a supervisor can see, in plain terms, how much of a window’s downtime actually carries a reason before trusting a ranking built on it.
An example, worked through
Say Tooling stops keep happening on a stamping press, four of them in the last two weeks of training history. The alarm-sequence detector checks every code that fired anywhere near those four stops. Alarm 1043 turns out to have fired at least once in the three hours before all four, twice on average each time. That clears both bars, at least three occurrences of the reason and a hit rate at or above half, so a card appears: “Alarm 1043 precedes Tooling stops,” with the count and hit rate spelled out, and a proposed rule to fire once 1043 repeats twice within roughly the same window it was observed repeating in historically. A supervisor who clicks the offer gets that threshold and window already filled in on the rule form, built from what actually happened on this exact press, not a generic starting point copied from a manual.
Why this stays useful as a machine’s history grows
A precursor pattern isn’t fit once and left alone. Every retrain re-tries every code and metric against the asset’s current history, so a pattern that strengthens as more stops accumulate gets a firmer footing over time, and a pattern that turns out to have been a coincidence in a thin early dataset stops clearing the bar once more data comes in, and the card behind it withdraws. Nothing about this depends on a person tuning a threshold by hand or deciding in advance which alarm code might matter. The floor’s own history does that work every time the model retrains.
Quick recap
- Spall tries every combination of metric or alarm code against every downtime reason an asset’s history offers, and keeps only the ones that clear a real support and effect-size bar.
- A numeric precursor needs at least three comparable pre-event windows and a real separation from baseline. An alarm precursor needs at least three occurrences of the reason and a hit rate of at least half.
- Scrap is mined through the same mechanism as downtime, reshaped into the same event structure, not a separate feature.
- A qualifying pattern proposes a one-click rule, a threshold or an alarm-repeat trigger, prefilled from exactly what the data showed.
- No dollar figure attaches to a precursor card, since it’s a checkable pattern, not a measured loss, and it carries no staleness label because it describes history, not a live reading.