Reason codes are a popularity contest.
Ten buttons, one shift, a queue behind the machine. The code chosen is the one closest to the thumb. Six months later the analysis blames the top three codes, which were only the top three buttons.
DOWNTIME TRACKING · LOST HOURS
Most downtime reports are a well-formatted argument about who was at fault last month.
THE SHORT ANSWER
Downtime tracking captures every stop, its duration and its cause. Manual reason codes are where it fails: operators pick the fastest button, not the true one. Useful tracking captures the stop automatically from machine data, infers the plausible cause from how the machine behaved before it, and connects the loss to the plan that now has to absorb it.
WHY DOWNTIME DATA IS RARELY TRUSTED
Ten buttons, one shift, a queue behind the machine. The code chosen is the one closest to the thumb. Six months later the analysis blames the top three codes, which were only the top three buttons.
Knowing that line 2 lost 180 minutes tells you nothing about whether it lost them the same way each time. The repeated micro-stop that becomes a breakdown never appears in a monthly total.
Downtime that arrives on Monday for last week cannot change last week's schedule. It becomes a meeting topic instead of a planning input.
The market counts lost minutes.
WHAT ATHERYA DOES INSTEAD
Stops are detected from the machine's own signals in the historian, PLC/SCADA tags and MES records — the data your plant already writes — so the record does not depend on who was free to classify it.
A stop is placed in context: the recipe running, the shift, the behaviour that preceded it, and the comparable events in the machine's history. You get a candidate cause you can challenge, with the signals attached.
Short repeated stops are invisible in a monthly total but obvious against a machine's learned normal. They are usually the cheapest hours in the plant to recover.
When a stop or a predicted failure changes feasibility, Atherya proposes the revised maintenance and production plan and waits for your sign-off.
READ FROM ONE REAL PLANT — BEFORE INSTALL
Rubber moulding, northern Italy. Figures from a real onboarding, read from existing data before any installation. Anything beyond them is a scenario, and we declare it as a scenario.
WHAT A REAL READ FOUND
Most predictive maintenance tools score signals. Atherya builds an operational memory of the plant first, then reasons on top of it — with the evidence in plain sight and the decision left to a person.
Every event, anomaly, intervention and shift becomes shared memory. What was a log yesterday is experience tomorrow, and the model reads new signals against it.
Not just "anomaly detected", but when it already happened, how similar it was, how it evolved and which action worked. The senior maintainer's memory, available to everyone.
Machine defects, weak points, how the crew actually works and the environment around the line. A deviation that is normal for that machine, that shift or that season stays quiet.
FMEA, manuals and procedures become an active part of the reasoning: causes, effects, sensors and suggested actions are connected, instead of sitting in a document nobody opens.
Every alert arrives with the signals involved, the comparable history, the failure mode and a confidence level. Data, interpretation and decision stay separate and verifiable.
Atherya does not stop at the warning: it proposes the maintenance window against real orders and shifts, and replans when something changes. Nothing is applied until a person approves it.
It works on PLC, SCADA, MES, ERP, maintenance records and feedback as they are — fragmented and legacy included. Sensors are added only where no existing signal carries the degradation.
Maintenance, production and planning read the same operational state, so a predicted failure immediately becomes a scheduling question instead of a separate dashboard.
QUESTIONS, ANSWERED
Software that records when equipment stops, for how long and why, then aggregates those stops into availability and loss analysis. The stronger systems capture stops automatically from machine data instead of relying entirely on operator reason codes.
Because classifying a stop competes with restarting the line. Under pressure the fastest acceptable code wins, so the data describes button placement as much as it describes the plant.
In most plants, yes. PLC and SCADA tags over OPC-UA, SQL historians and MES records already contain the state changes needed to reconstruct stops. Atherya starts there.
They are the ones worth finding. Individually they are too short to log, collectively they are a shift. They surface when each machine is compared with its own learned normal rather than with a threshold.
It proposes the change and shows the trade-off. Nothing moves in the plan without a human approving it, and every approval is auditable.
YOUR PLANT · YOUR DATA · THE PROOF
One export of existing machine data is enough for the first read.
Discover Atherya