Ignition Hub and Spoke Layout - Discussion

I have a larger project coming up and I was hoping to pick the community's brain to see what people have done in the past, or what is recommended.

The process has multiple smaller sub-process areas that are relatively independent. The desire is to have one central master gateway (and a redundant backup) and then have edge gateways in each process area.

I'm wondering what the best method might be to manage all of the different projects.

To me, it seems like it would be best to have an individual project for each edge gateway, and one master project that combines all of the sub-process areas, as well as adding a number of other things (all projects as part of the master gateway and inherited by the edge gateways). That way, there's one project to maintain for each sub-process area and changes automatically propagate to each edge gateway, and up to the master. However, with only single-project inheritance, there would end up being many intermediary projects used to combine them all, and that doesn't seem ideal.

Alternatively, I've also been considering having only one project and limiting screens in the sub-process areas based on the IP address of the accessing edge gateway.

Would love to hear any thoughts people have on the subject.

TIA.

If it is all in one facility on a decent LAN, I would just run the redundant pair of full Ignition servers.

2 Likes

Then forget about the edge gateways and just run clients?

Yes. Clients running off a full Ignition that fail over to a backup gateway are effectively maintenance-free. Not so with Edge Panels and fallback projects.

Thanks.

And what about the project setup? Multiple inherited sub-projects or a one big project that limits screens based on IP?

I'm not a master architect, but I'd have several smaller projects.
Let's say zone A is in charge of frobnication, zone B does the blunking, and the tlosping is left to zone C.
Operators don't need to interact with what's in other zones.
Make 3 projects.
They can still have access to relevant information from other zones through tags.
That way, you reduce the scope to what's needed.

If required, you can have another project that pulls interesting data from all 3 of them to make a dashboard, a global report, or whatever.

3 Likes

This. But also use inheritance from a common project with UI elements you want to be common across them all. That also makes it easier to produce the supervisory project that can "see" all activity.

4 Likes

@pascal.fragnoud

Thanks for the insight. I thought that this would be the best route.

Sadly, the client wants all local panels to be able to operate the local area in the event the LAN connection is completely severed. Looks like I've got my work cut out for me. :upside_down_face:

Well, presumably more revenue too. Silver linings....

2 Likes

Slowly gaining a better understanding of what the Edge Gateways are and how they would be used in this layout.

The edge gateways being modern computers, is there any reason that the edge panels, and the fallback project, couldn't be the full-fat SCADA project?

Then there's only one project to maintain and operators would have access to all of the plant from every panel. In the event of network disconnect, the fallback project on the Edge Gateway would still work for control of that local area and the errors/overlays on other areas would be temporary until network connection is restored.

This is a very solid LAN system, but complete disconnection from the hub needs to be accounted for.

Some people put the full Standard Ignition on the RPi, so it isn't a question of hardware. Standard Ignition is simply more expensive than some application requirements justify. Do note that careful selection of modules and use of a limited-client visualization module can trim that cost significantly.

So, maybe. Personally, I'd spend the money on multi-path LAN hardware that supports rapid spanning tree.

When I said full-fat project, I was referring to the fallback project on the Edge Gateway, not installing full Ignition on the local PCs.

Multi-path LAN would be great, but that's outside of our scope of work and up to the client's IT to determine what they want.

I always offer my paying clients this kind of advice for free. They may have other reasons for wanting to upgrade their LAN, and this cost saving opportunity may put them over the top to execute.

Assuming we can't talk them into that and we end up with a hub + redundant hub and 5 Edge Gateway hubs for local client fallback, where do I go to learn how to set all this up? I'm running into numerous questions as I explore how it all works.

There's one central hub where all project/gateway changes would be made (project changes, user changes, etc.). Changes somehow need to propagate both to the redundant hub and the edge gateways. (EAM module would handle this?) How does that all get set up?

If there's a fallback project, where do I set up the "default" project?

Ignition Edge only allows one project, no inheritance, so you may have some difficulty. (I vaguely recall some support for automatically consolidating a leaf+parents into a single project in EAM to send to Edge--not sure about that.)

I hardly ever use Edge, so I'm not going to be much more help.

Thanks for the help, I might need to reach out to support for some more info.

It's making more sense now that I've got a controller and agent set up I can see a list of agent tasks:

Still lots of questions, like

  1. I see "Send Project" as a task, but what about gateway resources that are updated?
    a. Can an Edge Gateway accept a backup from a full Ignition Gateway?
    b. If not, how are updated Gateway resources shared? Or, is it completely manual?

Consider contacting sales engineering instead of (or in addition to) support. They help people layout systems all the time, and know all the pros and cons.

1 Like

I started down this path, just creating some empty projects, and the issue I see is that every project would be entirely separate, except for the inheritance of UI elements. There's no way to "combine" two separate projects as I would like to in order to create the master project.

The approach I would like to use would be something along the lines of each zone has it's own project and then the central project inherits from all of those projects so that it can show all of the zones without remaking (importing) all of the screens. Then the individual zone projects would only need to be maintained and changes would automatically sync up to the central project.

I don't think that's possible with the single project inheritance, unless I'm missing something. So, I'll likely have the central project be the inheritable master and have components that "trim down" the master to the individual area (and one central project "viewer" that inherits but changes nothing).

It seems you're thinking about the inheritance scheme backwards. You don't combine two projects into one master, you have a master project with shared resources that the two zone projects inherit from (downstream). My inheritance setup looks like this

                   inheritable global project
                        /               \
     inheritable department1        inheritable department2 
            /      \                        /      \
     project 1    project 2           project 3    project 4

In this setup, all of the projects have access to everything in the global project, but only project 3 and 4 have access to what is exclusive to department 2 project. The same with project 1 and 2 with department 1.