Skip to content
Proxus 2.0.0 Proxus 2.0: the largest release in Proxus history Release notes
Try free Book a demo

Platform · Resilience

What happens when the network drops.

Plants lose links: a fibre is cut, a firewall rule changes, a cloud region has a bad hour, a database is restarted for maintenance. This is exactly what a Proxus gateway does then, in order, with the limits that apply.

Book a demo Edge runtime

Step by step

From the moment the link fails to the moment it is caught up.

  1. 01

    The link fails

    The gateway notices the hub, or a database, broker or cloud service, is out of reach. Nothing on the plant floor depends on that link, so nothing there stops.

  2. 02

    Collection carries on

    Drivers keep reading the machines at their configured rates. Rules and anomaly detection keep running on the gateway, and alarms are raised locally.

  3. 03

    Data queues at the gateway

    Values meant for the hub go into the gateway’s local buffer with their original timestamps. Each outbound target has its own queue on the gateway too, so one target being down does not hold up the others.

  4. 04

    Status says so

    In the hub, the gateway shows as disconnected, and a target that cannot be reached shows its error and how many queued messages are waiting at the gateway.

  5. 05

    The link returns

    The hub pulls the backlog from the gateway and the historian fills the gap with the original timestamps. Each target receives its queue in order, then live data again.

The limits

What to expect, stated plainly.

How long data waits
48 hours by default, up to 30 days, set per gateway. Data older than that is dropped first.
What is kept
Everything inside the retention window, for the hub and for every outbound target type, until it is delivered.
Delivery
At least once: in rare cases a value written just before the link failed is written twice. Within the limits on this list, values wait and are delivered in order instead of being skipped.
Above the licensed rate
Data above a gateway’s licensed rate is not delivered and not buffered, online or offline.
A record a target refuses
If a target answers but never accepts one record (a value too long for its column, say), that record is skipped after a few attempts and named in the target’s status, so the rest is not held up.
Alarms
Alarms raised while offline are kept on the gateway until the hub confirms it has them, and sent in the order they were raised.

Details: gateway buffer retention · outbound targets · store-and-forward explained

Proven in production

Running at the edge, including where bandwidth is scarce.

All deployments

Next step

See a gateway ride out an outage.

Bring the outage you worry about: a WAN fault, a firewall change, a database restart. Ask us to disconnect a gateway in the demo, and watch the backlog arrive in order when the link returns.

Book a demo Talk to an engineer
  1. 01

    Scoping call

    Equipment, protocols, sites and the systems the data has to reach.

  2. 02

    Technical walkthrough

    A working demo against a scenario that resembles your plant, not a generic tour.

  3. 03

    Pilot plan

    A defined first line or site, with the deployment and security questions answered up front.

  4. 04

    Roll-out

    The same templates bring the next lines and sites online.