The machine times the stop. The operator says why.
Start, end and duration come from the controller. The operator is asked only for the reason, from the list set for that machine, while still standing at it. Every split and reclassification afterwards keeps the original on file.
A stop typed at the end of the shift is a guess with a timestamp.
When downtime is written down after the fact, start times are rounded, short stops are forgotten and the reason that comes back most is ‘other’. That is not carelessness; it is what any form filled in from memory produces. VZIAM MES starts the clock on the controller’s state change, so the record exists before anyone is asked anything, and the one thing left to ask is the cause.
Five rules every stop is held to.
They keep a downtime Pareto a picture of the line rather than of the reporting.
- 01
A stop starts on the controller, not on a declaration.
After 15 seconds without a signal the cockpit shows a pre-alert and creates nothing. After 60 seconds a stop is created and the operator is asked for the reason. Both delays are settings.
- 02
An unqualified stop stays unexplained.
It is not filed under a default reason or absorbed into running time. It shows as unexplained on the timeline and in the Pareto, and an alert is raised once it passes the threshold you set.
- 03
The operator sees only the reasons for that machine.
Reasons are assigned machine by machine, in the order you set, the most frequent first. The operator of a filler is not scrolling through the breakdowns of a press.
- 04
Splitting a stop keeps its total.
A stop split in two is still the same length. A split point outside the stop is refused, and the original stays in the audit trail with who changed it and when.
- 05
Retiring a reason does not rewrite history.
A deactivated reason disappears from the cockpit. Stops already filed under it keep it, so last year’s Pareto still adds up.
From the first second of a stop to the Pareto.
Qualified in three taps
Family, component, reason, from a tree you define. Each reason is typed under AFNOR NF E60-182 as closure, planned, induced, own or micro-stop, so choosing it also decides what it does to OEE.
Declared after the fact, with the conflict shown
A stop declared for a past period is checked against what the machine counted in it. The parts in conflict are shown before you confirm, and neutralised in the same transaction if you do. The floor’s account wins, on the record.
Target durations per reason
Set the expected length of a changeover or a cleaning, per reason or per machine. The cockpit shows the overrun as it happens, and the analysis compares actual with target. Changing a target later does not rewrite past stops.
Qualified in bulk at the end of a shift
A supervisor can qualify the unexplained stops of a period in one pass rather than opening them one at a time.
Alerts on prolonged stops
A stop still unqualified past the threshold you set raises an alert on the operator’s screen. It closes when the stop is qualified, with its start and end kept.
Corrections reserved to supervisors
Reclassifying after the shift closes, merging intervals and validating large count adjustments are supervisor actions. Each one is recalculated on the server and audited.
What the module commits to.
- Detection
- From the PLC signal
- Pre-alert
- 15 s without a signal, by default
- Stop created
- After 60 s, by default
- Reason model
- Family › component › reason, per machine
- Stop types
- Closure · planned · induced · own · micro-stop
- Corrections
- Audited: before, after, who, when
Frequently asked questions.
Bring your current reason list and ask the engineers who would set it up.
Book a callFrom the controller’s signal. After 15 seconds without one, the cockpit shows a pre-alert without creating anything; after 60 seconds a stop is created and the operator is asked why. Both delays are settings.
Split it at the cockpit. Each part gets its own reason and its own duration, the total stays the same, and the original stop is kept in the audit trail.
Yes. The declaration is checked against the parts the machine counted in that period. The conflict is shown before you confirm, and the declaration takes precedence if you do.
A supervisor. Operators qualify and split the stops of their own machine; reclassifying after the shift closes and merging intervals are supervisor actions. Every change records the old value, the new one, who made it and when.
No. A closure or a planned stop reduces the time the line was required, not its availability. The type is set on the reason once, and every stop filed under it follows.
The order’s real times go back to the ERP when it closes, with its good quantity and rejects. The stop detail stays in VZIAM MES, and the timeline exports as CSV for BI tools.
Plan the change before it reaches the line.
Request a demo and an engineer looks at how your production runs today, shows how the software would fit around it, and where a pilot on one line would start.
01Pick a time
Choose a slot in the calendar, and note what you make and what reads your machines today.
02Screen shared with an engineer
A video call with someone who builds the software, in English or French.
03What would connect
For each machine, its path: native (OPC UA, MQTT or HTTP push), through a gateway, or nothing to build.