I’ve managed to avoid more complex Ignition setups in the past, but that time is coming to an end..
Disclaimer: I haven’t put much thought into this as yet, just starting to think about it out of hours…
We have a project coming up where we’ll be designing an Ignition rollout that involves multiple sites and a central hub to view the status of all sites. There will be application redundancy at each location which matches their existing SCADA setup.
In their existing SCADA system, each site has the ability to show information from other sites as well. Taking this to an extreme, if they have 100 sites, I don’t know how I would manage the remote tag provider connections and the GAN connections required to facilitate this, nor what network traffic impact this would have on the network? I imagine that I would need 99 remote tag provider connections, 1 to each of the other sites, configured on all 100 site gateways, as well as the 100 RTP’s configured to each site on the central. That seems like a lot to manage and a lot of overhead.. In the existing SCADA, the tag address space is global, so there is no more configuration to be done in order to read tags from different sites. The clients just know how to get the data based on the project’s network configuration
Regarding the project setup, I imagine that I would have a global project or projects which all projects inherit from. I would have a project for each site, and a project for the central hub. Say I need to display exactly the pages or at least a subset on the central hub, I don’t know how I would structure the inheritance to make this possible, given that Ignition’s project inheritance is linear and not hierarchical. In the existing SCADA, you can inherit from multiple projects at once, in which case your site projects inherit from the global and your central project inherits from each site as well as the global projects, and it can then just make use of the resources in all of the site projects. In Ignition, the only way to do this with inheritance is by the central inheriting site A which inherits site B which inherits site C, etc. which finally inherits global. For 100 sites, this is extremely cumbersome to configure, but it also means that each site project is not runnable. I don’t know if this affects EAM if I have the central hub as the master configuration which pushes changes out to the sites.
I’m sure there will be a lot more questions as I investigate this more..
Edit: inheriting site projects could be dangerous if the site projects have project gateway scripts defined
I've got a client running a hub and spoke setup like you described with one hub and 7 spokes. Here's some details on the setup.
Network topology:
Hub: full-fat Ignition gateway with unlimited clients. This is a beefy instance on a VM as it is connected to every device and will handle as many clients as needed. This VM also has a dedicated historian server instance.
Spokes:
a) In normal operation, each spoke just runs as a client of the hub.
b) Each spoke also has an Edge gateway that serves as the fallback (edge/full may depend on how many devices the spoke needs to connect to in fallback - more on that in a minute). Each spoke gateway is running the same project as the hub gateway.
Project:
The project for all gateways (hub and all spokes) is the same. The windows/views are limited based on which gateway the client is viewing from. I used some of the built-in device tags that exist when a device is defined on the gateway to determine which gateway is being used.
Tags:
Each "area" where a fallback gateway is needed gets it's own tag provider. The hub will include all tag providers. The spokes will just have the one. The result is that each tag has 2 connections, which is not ideal but the tradeoff here is worth it, IMO.
Example:
Area 1 devices : RTU10, RTU11, RTU12
Area 2 devices : RTU20
Area 3 devices : RTU30, RTU32
There would be tags in the "default" provider to determine which devices exist on the gateway. The hub would have all 5, Area 1 fallback would have 10, 11, and 12. Area 2 fallback would have 20. Area 3 fallback would have 30 and 32. There would also be 3 providers, one for each Area.
Within the one "master" project that runs on all gateways you now limit which buttons/components are enabled/visible based on the determined "area".
Now you only have one project to maintain, although you do have to maintain multiple gateways and make sure you have EAM tasks set up (although you don't actually need the licensed version of EAM, the trial works because the tasks can just run on-demand as needed). Some notable EAM tasks: syncing UDT types between the "default" tag provider and all other tag providers. Sending tags to all agents. Sending project to all agents.
One thing that is difficult here would be security, as far as user login and things go, unless you're managing that outside of Ignition.
Full disclosure I haven't scaled a project to that level but my initial thoughts on it are 100 RTPs on each site is creating a mesh network not a hub and spoke model and you're already on the right track thinking that's not a valid route. Instead I would set up each site as a remote tag provider on your central hub then on the hub create another tag provider as your central tags and aggregate all the sites into that. Then go back to each of the sites and add the central tags as a remote provider.
So then all your data goes site A -> Hub -> site D. That being said, I have no experience if this is best practice nor how it'll look from a network efficiency / loading delay aspect.