Ignition Edge at a remote site: what you actually get

The problem Edge is shaped for

A remote pump station, a lift station, a well site, a tank farm on the other side of the county. The equipment keeps running whether or not the radio link is up, so anything that depends on a live connection to a central gateway fails on the days you most need it.

Edge puts a gateway at the site. It collects locally, stores locally, and hands data upstream when the link permits, which turns an outage from a data-loss event into a delay.

Three buffers, not one

This is the detail most worth getting right, because the numbers differ by data type and only one of them is the number people remember.

Tag history is stored locally up to 35 days or 10 million data points — in practice whichever limit binds first. Pruning happens automatically, and the historian is automatically enabled and not configurable. Edge runs a single historian provider, an instance of the Internal Historian (Legacy), named the Edge Historian Provider.

The alarm journal and the audit log are a different story: both are limited to one week of local storage, and the audit log limit is not configurable.

So an outage of two or three weeks is survivable for trends, point limit permitting, and is not survivable for alarm history. That asymmetry is worth stating plainly because of how it fails — the trend fills in on reconnection and looks complete, while a week of alarm and audit records is simply gone. Everything appears to have recovered.

What the point limit actually costs you

Local retention and outage tolerance are the same window doing one job, not two competing for it — 35 days or 10 million points, whichever binds. When the link is severed, Edge uses that storage as a store and forward buffer, and the full window is available before data is lost. Older records age out of the same rolling window rather than being displaced by the backlog.

Where it genuinely erodes is on the point axis. Consumption is roughly tag count multiplied by logging rate multiplied by time, and at a high enough combination the 10 million points arrive well before 35 days do. At that point your retention and your outage tolerance are both that shorter number, and there is no configuration change to notice. Value-change logging makes the real rate harder to predict than a nominal scan rate suggests, so this is worth measuring on a live site rather than estimating from the tag count.

What Edge does not do at all

Four limits that decide the architecture, none of them about buffers.

Database access is disabled. Database queries and bindings will not work, and user sources requiring a database connection are unavailable. If your mental model of a site gateway includes querying a local database, that model does not survive contact with Edge.

Visualization is edition-dependent. Edge comes in two editions, Edge IIoT and Edge Panel, and visualization is supported only on Edge Panel, which is limited to two concurrent viewers: two Perspective Sessions, or with Vision one local Client and one remote. So “somebody can look at this locally when the link is down” is a requirement that selects your edition and caps your concurrent viewers at two.

Two more limits worth knowing before you draw an architecture. Redundancy at an Edge site means a second Edge gateway: an Edge gateway can only fail over to another Edge gateway, not to a standard Ignition gateway. And third-party modules do not run on Edge unless they are explicitly stated as Edge-compatible, which is worth checking against anything you already rely on centrally — including ours.

Catching up, and the setting that delays it

When the connection returns, Edge forwards the backlog upstream, paced by the configured Max Batch Size and Sync Frequency until it has caught up. On a thin link a long outage produces a long recovery, which is worth knowing before somebody watches a trend fill in slowly and concludes something is broken.

There is also a schedule option: sync can be restricted to a time pattern, so data only moves during the windows you specify. That is useful on a metered or contended link and it extends recovery accordingly — a detail worth checking before diagnosing a slow catch-up as a fault.

The version trap

Because of serialization updates, Edge Sync Services data originating from an 8.3 Edge gateway cannot be stored to an 8.1 gateway. That covers remote history providers, remote audit logs and remote alarm journals.

Inductive Automation states the sequencing outright: upgrade the central server hosting the data to 8.3 before upgrading any remote 8.1 gateways. Doing it the other way round breaks the thing the remote sites exist to do, and discovering that requires a truck.

Choosing between Edge and a full gateway

• How long can the link be down before the point limit binds, given your tag count and how often values actually change?
• Can you tolerate losing alarm and audit records beyond one week, given that tag history will look complete afterwards?
• Does anything at the site need a database connection, locally, at all?
• Does anybody need to view the site locally during an outage — and are two concurrent viewers enough, given that Vision allows only one of them to be local?
• When you upgrade, does the central gateway go first?

Edge is a limited version of the same platform at a much lower cost. The question is not whether the limits are real — they are, and they are published — but whether they match the shape of the site. For a site that has to keep working alone and then reconcile, they mostly do.

Common questions

References

• Inductive Automation — Ignition Edge: editions, limits and local storage (8.3)
• Inductive Automation — Configuring Sync Services (8.3)
• Inductive Automation — Tag History Providers (8.3)
• Inductive Automation — Edge Architectures (8.3)