- Monitoring
- Integrators
Stop rebuilding machine monitoring for every factory
Four questions every factory asks its machines, and why the answers should not need a new software project each time.
Harsh Gandhi4 min read
Key takeaways
- Every factory asks four things of its machines: is it running, why did it stop, how much did it make, and is something about to go wrong.
- Building monitoring from scratch for each factory repeats the same work, and every copy has to be looked after on its own.
- Describe a machine once (what to read, which alerts to raise, what to calculate) and reuse that description for every machine of that type.
- Only what really differs is set per factory: machine names, shift timings and alert limits.
- Custom work is right where the factory is different. It is wasteful where the problem is the same.
The four questions every factory asks
Walk into any factory and ask what they want from their machine data. The words change, the questions do not.
- Is it running? Right now, without walking to the machine.
- If not, why did it stop? A reason, not just a gap on a chart.
- How much did it make today? By shift, so the day can be compared with the day before.
- Is something about to go wrong? A warning in time, before the line stops.
The last question matters most. A machine that fails without warning stops production, and a stopped line lands on finance: idle workers, missed dispatches, late deliveries. The first three tell you what happened. The fourth lets you act before it does.
How monitoring usually gets built
In most projects we hear about, the monitoring is built from scratch for each factory. This is typical, not one customer in particular. It goes like this.
- A team builds screens for status, a list of stops, a daily report and a few alerts.
- The next factory needs the same, so it is built again.
- Each version differs a little, so each one is looked after separately.
- When the person who built it leaves, nobody is quite sure how it works.
- A small change, like one new alert, needs a developer again.
None of this is anyone’s fault. A project is a project, and the deadline is the deadline. But look at what the customer receives: a pile of screens. That is not what they asked for. They asked for answers, and a warning in time.
Customers do not want a pile of screens. They want answers, and a warning in time.
The cost nobody puts in the quote
The first build is the cheap part. The cost shows up later, and it comes in five forms.
| Where it shows up | What it looks like |
|---|---|
| Repeat work | The same screens, stops list and report are rebuilt for every factory. |
| Drift | Each copy differs a little, so a fix in one does not reach the others. |
| Upkeep | Every version needs someone to look after it, one at a time. |
| People risk | The one person who knows how it works leaves, and the knowledge goes with them. |
| Slow change | A new alert is a small request that still becomes a development task. |
A simpler way: describe the machine once
There is a simpler way. Describe a machine once: what to read from it, which alerts to raise, and what to calculate. Then use that same description for every machine of that type.
Only what really differs is set for each factory. That is a short list: the machine names, the shift timings and the alert limits. Everything else is already decided, tested and shared.
What changes in practice
- A new factory with a known machine type is set up, not developed.
- A fix or an improvement to the description reaches every machine of that type.
- A new alert is a setting someone can change, not a ticket waiting for a developer.
- The knowledge lives in one description anyone on the team can read.
This is the approach we took building Flowtics, our industrial IoT platform at AvestaHQ. It is set up by configuration, so you get live status, stop reasons, shift reports, limit alerts and service reminders on WhatsApp or email, without a new software project each time.
So is custom work wrong?
No. Custom work is right where the factory is different: an unusual machine, a process nobody else runs, a report that exists only in that plant. That is where an integrator’s skill earns its fee.
It is wasteful where the problem is the same. Status, stops, shift output and alerts are the same problem in every factory. Solve that once, and spend the engineering hours on what is truly different.
Questions people ask
- Does this replace the integrator?
- No. It removes the repeated part of the job, so the integrator spends time on what is different in each factory.
- What is set for each factory?
- Machine names, shift timings and alert limits. The machine description itself is shared by every machine of that type.
- Where do the alerts go?
- To WhatsApp or email, whichever the team uses.
