I’m working on an Ignition architecture with three gateways and would like some input on the recommended setup and best practices.
The planned base setup with this as a base: (intended architecture: multiple pairs of redundant backend gateways, 1 pair of redundant frontend gateways, 100's of edge clients)
Edge Gateway – connected to local PLCs/equipment and contains the original tags. (Shown on image)
Backend Gateway – used as a central layer for data collection, history, alarms, logic, and integrations. (Shown on image)
Frontend Gateway – hosts the final Perspective HMI for operators. (Added gateway, not shown)
The idea is that Edge collects the local data, Backend centralizes it, and Frontend is used for the operator interface.
I have attempted to embed a Perspective session from the Edge Gateway into another gateway using an iframe / Inline Frame component, but I am encountering issues.
My current understanding is that the operational Perspective HMI should be built or copied to the Frontend Gateway, while Edge and Backend mainly act as data sources.
If the same tag provider names and tag structures are available on the Frontend, copied Perspective views should hopefully work without major binding changes.
Example tag path:
[edge]Folder/TagName
I’m trying to confirm that this is the right approach before continuing with the HMI and tag provider setup.
Questions
What are the best practices for this type of Ignition setup?
Should the final operator HMI be hosted on the Frontend Gateway?
Is embedding a Perspective session from one Gateway into another using an Inline Frame/iframe supported or recommended?
What is the recommended Remote Tag Provider setup for Edge → Backend → Frontend?
Is copying views to the Frontend and keeping the same tag provider names/paths a good practice?
Are there any important Docker or Gateway Network considerations for this setup?
Sorry for the extra long post.
And thank you in advance for the feedback.
You're on the right track. Where you'll diverge from the Edge project when going to the Backend/Frontend is that your tag providers will change because each remote tag provider will need a unique name. A search/replace on a view should fix it though.
Forgot to answer questions:
I think you're good on the architecture, but others may have recommendations.
Depends what you call final operator HMI. You have a couple of options. If you're using Edge Panel at the local PLC level you could have the local HMI show and control only that local Edge project. You could also show the Frontend HMI project if you need to control or view other stations as well. Your Frontend HMI would always come from the frontend server though since you'll be limited on sessions for the Edge systems.
Don't embed iFrames.
Not sure on this one. Depends on how much you're doing on the backend server. Others who have done the multi tiered approach may have suggestions. Technically you could pass the backend data to the Frontend via the gateway network by setting up the maximum hops to 2 on your connections.
You'll have to change tag provider names somewhere because they can't all be named [edge] and still work.
Setting gateway network hops to 2 will let you connect directly from Frontend to Edge if needed. If this isn't needed, keeping them at 1 will limit what the Frontend can see directly and will require proxying the data through the backend server.
I dislike this approach because you now have extra software, multiple projects to upkeep, multiple points of failure (even if you have those failures covered by redundancy, but that contributes to the extra complexity), and possibly even extra hardware.
I prefer dual-connection setups as apposed to this edge-served remote tag setup. In your scenario, if the central goes down you have redundancy to cover you. In the case that that backup fails you still have the local edge gateway. Heaven forbid that one fails too, you still have one more failover. But, what happens if your edge goes down first? Of course you've got one backup there, if that one fails you're SOL as your central no longer has connection to any of those tags. With redundancy, sure you have a fallback, but that adds complexity. Not to mention you now must have different projects for frontend and backend that you now have to manage separately.
I prefer to have one project, a central gateway with redundancy, and local edge gateways without redundancy but set up as a client of the central with the edge project as a fallback. Your one project now runs on all gateways and when your edge gateway is running the project you just hide things that are outside of that edge gateway's "scope." Project management is super easy with EAM (just use trial mode and reset when you need to send tags/projects to the edge). Each edge gateway scope has it's own tag provider in the central gateway. This makes it easy to separate tags for the edge panels to use. Now, if an edge goes down your central keeps running no problem. If your primary central goes down there's a backup. If that backup fails you still have the edge gateway fallback. Eliminates the need for any redundancy at the edge level. You also don't have to make sure all of your tag provider references are updated.
In this setup I also use EAM to "send" my UDT types to each provider from the default UDT definition to make sure they're all in sync.
