- Reliability
- Edge
Monitoring that still works when the internet drops
An outage should cost you minutes of delay, never a day of history. Four questions to ask of any monitoring system.
Harsh Gandhi3 min read
Key takeaways
- Connections drop: shared lines, remote sites, a router someone restarted. A monitoring system is judged on the bad nights, not the good ones.
- If the monitoring depends on the connection, the outage window is simply missing: a hole in the shift report, and an OEE that looks better than it was.
- Ask four things of any system: does it keep recording at the machine, does it send the missed data in order, do alarm rules run at the machine, and is each stop tied to a reason?
- For a machine builder with machines at customer sites, the difference is a clean service history versus a guess.
A Tuesday night, 40 minutes without internet
Say the internet drops for 40 minutes on a Tuesday night. This is an example, not one customer. The machine does not care. It keeps running, keeps counting, and stops twice.
Now ask the only question that matters: where is that data? If the monitoring depends on the connection, those 40 minutes are simply gone.
What goes missing
- The shift report has a hole. There is a stretch with no numbers, and no way to fill it in.
- The OEE looks better than it was. The stops in that window never reached the report, so the machine looks like it ran more than it did.
- Nobody can say what happened. Two stops, no reasons, no times.
This is not a rare case. Shared connections, remote sites, a router someone restarted for another reason. It happens in every kind of plant, and it happens most at the sites that are hardest to visit.
A monitoring system gets judged on the bad nights, not the good ones.
Four questions worth asking of any system
You do not need to read a datasheet to find out how a system behaves in an outage. Ask these four, and listen for a plain answer.
| Ask | Why it matters |
|---|---|
| Does it keep recording at the machine while the link is down? | If recording stops with the connection, the outage is a blank. If it carries on at the machine, the data still exists. |
| Does it send the missed data afterwards, in order? | Readings that arrive late and out of order scramble the history. Sent in order, the history has no gaps. |
| Do the alarm rules run at the machine, or wait for the cloud? | A rule that waits for the cloud cannot fire while the cloud is out of reach. |
| Is each stop tied to a reason? | A stop with a reason is a fact you can act on. A gap with no reason is only a missing number. |
How we handle it in Flowtics
Flowtics, the platform we build at AvestaHQ, keeps reading at the machine. It buffers the readings and syncs them when the link returns. The alarm rules are checked at the gateway, so they do not wait for the cloud.
For a machine builder with machines at customer sites, that is the difference between a clean service history and a guess. When a customer says the machine stopped on Tuesday night, the record is there, with the times and the reasons.
Minutes of delay, never a day of history
No connection is perfect, and no monitoring system should pretend otherwise. What you can ask is that an outage costs you minutes of delay, never a day of history. If the answer to the four questions is a plain yes, it will.
Questions people ask
- Is any data lost when the internet is down?
- Readings are kept at the machine while the link is down and sent in order when it returns, so the history has no gap.
- Do the alarm rules still work during an outage?
- The rules are checked at the gateway next to the machine, so they do not wait for the cloud.
- Why does this matter more for machine builders?
- Their machines sit at customer sites, often on shared or remote connections. A complete record is what lets them answer a service question with facts.
