Hub/Spoke Alarming

Hi everyone, looking for some advice on the best way to handle alarms on a hub and spoke architecture with multiple spokes. I have details included below and wanted peoples opinion if this looks like a correct setup for such an architecture. What prompted my question is I am attempting to transfer the alarming to the local spokes based on Ignition best practices, but all operators typically use our Hub for control due to remote access availability. If I handle the alarms locally, and an operator acknowledges the alarms on the Hub, they still remain as unacknowledged on the local project. Current setup:

Hub (Ignition Gateway)

  1. Alarming is handled on the hub level for all systems
  2. Reporting is handled on the hub level for all systems
  3. Operators use the Hub for control/viewing unless fall back situation occurs.

Spoke/Local (Ignition Gateway)

  1. Handles transaction groups for the spokes (Stores locally and also writes to a secondary database server)
  2. Gateway fallback; if connection is lost to the Hub, the local client launches (however it remains active at all times)
  3. Tag historian is handled on the local spoke and runs as splitter between local database and hub database
  4. If local spoke is powered off, hub connection goes down as well (which seems backwards to me but I do like the local control of a physical machine onsite)

Are you using remote tag providers (where 'spoke' "shares" its tags with 'hub')?

In that scenario, I would expect acknowledgement on the 'hub' to properly send down to the 'spoke', since it's the same tag.

Thanks for your response! Currently the setup is using a "Standard Tag provider" on each Gateway. Based on your response, is it safe to assume that the method you mentioned would be a best practice for this type of setup. Am also reviewing

Do you see any conflicts using this configuration if the Hub vs the Spoke are operating on two different Ignition versions? All of our local machines are version 8.0X but the hub is still operating under a 7.8X platform.

It has been fun trying to correct the ongoing list of architecture issues while keeping everyone online!

Oy! Both hub and spokes are unsupported versions. (Not expired LTS, but versions that were never long-term-support.)

You should consider fixing that problem first.

1 Like

Tell me about it.... :slight_smile: I have a Windows backup server running that I can get a clean install of the most recent release on. I will work on that and consider it my new "Hub" as I transition away from the other online hub server.

If I want to set up Redundancy, would the local machines be the "Master" with the hub being the "Backup"? So that in the event any of the local machines distributed across the network fail, they will be diverted to the Hub.....assuming that the local ISP network wasnt the failure. I just want to make sure I begin configuring the correct Gateway allocated as the backup as the instructions are pretty specific that you should start with a clean install on this device.

No, redundancy is always an otherwise identical pair. Two hubs, but functioning as one. (I would get the master working before worrying about the backup.)

2 Likes

Recent versions of 8.1.X and 7.9.X are expected to be able to interoperate w/ remote tags, although you will not be able to edit tags across the bridge; only read/write (alarming should work, though).
'Legacy' versions like 8.0.X and 7.8.X have no such expectation of compatibility; as Phil mentioned, they're both no longer supported, and thus probably have no released versions that overlap in time.

I was able to setup a Gateway Network and Remote Tag Provider on a test server and all went well so thank you for the advice. I do have another hopefully simple question. I imported Vision windows from another project, but obviously the component paths are broken due to the new tag provider name. Is there an easy way to change all the tags used by components to include [New tag provider path] ? I did change the default tag provider for the project to my new provider but that did not convert all of the tags over. Thanks

It depends on how the bindings were created. If they were using an unqualified or 'default' qualified (starts with [~]) path, then they should just automatically switch.

If they were using a fully-qualified reference to the old path, then Find And Replace is probably your best option.

Thanks, I will look into it. they do indeed start with a 'default' provider path; but only partially converted after changing the new project tag provider default to use the remote tag provider.