Edge Fallback Tag Subscriptions

I have a question regarding the use of Ignition Edge as a fallback to Ignition Platform.

If I have Platform and Edge running the same project with the same tag provider and tag connections. Is there a difference between running the Platform and Edge in "parallel" vs running the client on the edge with the Edge project being the fallback?

I've used the fallback project before to cut-down the Platform project on the Edge if the connection to the Platform goes down, so I understand the benefit in that situation, but in this case I'm wondering if that fallback setup is actually worth anything. Of course, the Platform project would have more historical data capability, but outside of that why wouldn't I just have them run in parallel and use the Platform only if more in-depth historical data is needed? Does using Edge as the fallback save a tag connection if it's not actively being used (i.e. the Edge is acting as a client of the Platform)?

A fallback gateway is an independent gateway, everything is duplicated, and it makes its own connections to the devices. So, double the traffic on the PLCs involved, even when the client is not pointing at the fallback. Unless the Edge gateway is the only connection to the devices, and forwards to Standard Edition. (But then Edge itself is a single point of failure.)

(Also, terminology: Ignition Platform Edge Edition, Ignition Platform Standard Edition, Ignition Platform Maker Edition, and Ignition Platform Cloud Edition. "Platform" ≠ "Standard".)

In that case the word "Platform" seems useless, IMO. I was looking for some way to differentiate the "Standard" edition from the Edge edition, but I don't see "Standard" used on the website.

I was going based on the terminology that I found on the pricing tool page. This is what I determined from that:

  1. Ignition (Platform)
  2. Ignition Edge (Edition)
  3. Ignition Cloud (Edition)

When you select "Ignition" it lists "Ignition Platform" as a line item. When you select "Ignition Edge" it lists "Ignition Edge" as a line item - so I used "Platform" as the differentiator. Terminology has changed relatively recently.

So if the goal was to limit traffic from the fallback gateway unless it's needed, is there a way to stop Ignition from starting up with the PC and starting as needed instead?

No, but redundant gateways set to cold when inactive don't make extra traffic.

I generally discourage the use of fallback for this reason, and because it often requires a customized, cut-down project to run in Edge. Which means extra engineering and maintenance.

By "as needed" I don't even necessarily mean automatically. It would still be acceptable if the main client fails to manually start Ignition and launch the edge client. Is that doable?

I'm not sure what sequence of events you are suggesting. Fallback is basically just retargeting from the main gateway to load a project from the local gateway. If the local gateway isn't already running and ready, there won't be any fallback.

Right, I'm saying I don't want fallback.

This is the sequence of events I was thinking.

  1. Platform PC running, Ignition running
  2. Edge PC running, Ignition Edge not running
  3. Edge PC runs as a client of the Platform gateway.
  4. Edge PC loses connection to Platform gateway (for whatever reason)
  5. The Edge PC's (Platform) client "error's out"
  6. User closes the client window.
  7. User manually startis Ignition Edge and launches the Edge gateway's project (Desktop shortcut(s).

Oooookaaaay. So Edge will most not be running at all? Sounds like a waste of a license.

If a Standard gateway is present in the same physical site, I generally recommend just adding redundancy. It just works, loses very little history during failover, and requires no extra engineering.

Ya, I tried to argue for redundancy but these PCs are pretty prone to failure due to the environment they're in. It's not uncommon to have 2 fail.

If two PCs can fail in that environment, standard redundancy only covers one gateway failing at a time—it won't help if the failures share a cause like heat, power, or network. The manual-start Edge idea also depends on the Edge PC itself surviving. I'd treat the environmental issue first: UPS/regulated power, enclosure cooling, and separate network paths where practical. Otherwise you're adding failover layers that can all be taken out by the same condition.

Yeah, sorry. Fix that. Site servers should be in a suitably climate- and dust-controlled enclosure. Use rapid spanning tree or similar branded networking tech to make the links to machines robust.

Yep, it's dust :joy: we don't decide what PCs they have or where they keep them.

Let's say we have a site with one Platform PC with redundancy and 6 total clients vs a site with one Platform PC and 5 Edge PCs. In the first case you're depending on the 2 PCs to work for all 6 clients. In the second case you get multiple-redundancy. As many of them can fail so long as one remains viable - but if we can reduce the number of tag subscriptions under "normal" circumstances that would be awesome.

You are in magic wand territory. That is, mechanical/civil/operational problems are expected to be solved by electrical and control engineers with software. It is simply not realistic and will just make you chase your tail.

Tell your client/bosses that you need reliable computer hardware, including environment, to have reliable controls and data collection. Full stop.

And once you do get redundant hardware into suitable enclosures, the staff needs to treat the failure of one of those gateways as an emergency.

Agreed. I'll do my best.

Regardless of the environment issue, it still seems like the redundancy approach may provide some extra value that you're now not reliant on a small portion of you network. Like, let's say that the Platform PC and it's redundant PC are connected to the network from the same switch but the Edge PCs are connected at various points. If that switch goes down and you were using clients they're all dead - even if the edge is still on the network and can reach everything that it would need. So, again we're back to the fallback thing.

In the latter case you now have 5 additional ignition licenses, you need to manage 5 additional projects every time there is changes, you have 5 extra configurations to manage because what if one operator misunderstands procedures and turns all the services on when he sees them off, etc. You've added future operation costs and a higher risk of longer term maintainability.

At the end of the day the business needs to make a risk evaluation of the overall facility. There will always be the risk of a plc processor failing, a network comm card, switches themselves, a faulty cable, etc. How much are they willing to spend for uptime.

Most of this is covered by using EAM on the single Platform gateway that pushes the same project and tags, which is just a duplicate, to all gateways. As far as someone messing with the services, you can't account for all operator error, and worst-case scenario you end up back with multiple tag connections.