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.
My issue with this design is that I feel like if your edge goes down most likely the entire enclose lost power. But if I lose a network connection between the edge and central gateways I can still control and operate the edge and when it comes back online it can sync history to the central gateway. With a centralized system that isn't possible as you'd have lost all that data and local control.
Redundant network links (Rapid Spanning Tree or your favorite alternative) throughout a facility are a far better investment, IMNSHO, than deploying multiple Edge where (redundant) Standard already exists. Keep in mind the engineering costs to prepare fallback projects and UIs. It is attractive to pitch as the subject engineering provider, but it is terrible advice for the end-user.
Thank you for your answer, this is a large system with redundant hardware at multiple physical different locations. The users need the HMI locally if the connection fails and the other systems needs to be available while maintenance is being done.
If the edge system goes down then we need to send someone out in the field, to check it out. But there are 100's of systems configured on the different backends which are being consolidated in to a single frontend.
It sounds to me like your "central" in this case would be more of a monitoring station for your 400 systems? If that's the case then I could see a use case for each of the systems being a standalone edge project (hopefully they're copies of the same system ) and then creating a central project that pulls some, but not all, of the information/tags from the edge systems. If, however, you're hoping for identical functionality at the central for each system that may be a different story. In that case I would take some time to figure out a nice way to launch a client for whichever of the 400 systems you're hoping to target from the central location's project rather than trying to duplicate the functionality in a second project.
I have a client which heavily utilizes Edge (some redundant), with ~200 Edge gateways (and counting) deployed across several states, each has potential to be operated by different personnel. We opted for 1 project for each remote tag provider. Each of them is configured for with at least 2 inherited projects (somewhat resembling Global >> Facility_Type >> Facility). There is minimal setup in the central gateway for a new project. All views and almost all configurations therein remain inherited (except for default tag provider, perhaps a couple of others). We use EAM to sync each project (combine inherited resources to one) to each Edge gateway, where a local touchscreen displays the exact same project as the central, and is used very infrequently.
There are also projects which are intended for SCADA use, whereby summaries for each region are available from a single project (with minimal write access).
I believe that the number of projects should be based on:
Operator access requirements for remote facility (if all sites are operated by the same personnel, then a single project could suffice).
The uniqueness required of each project (if all sites are identical, then a single project could suffice).
Depending on your rollout schedule, & expected client count, you might consider combining frontend & backend gateways until need dictates that you separate them out...?
I'm thinking of creating a different project for each system on the backend. And use the Frontend gateway as an overview that navigates to the correct project/system(Url).
For each project on the backend we are thinking of having 1-5 parent projects (1 main and 4 different depending on category site), and inherit it down to the projectsites.
This sounds close to what we are trying to create structure wise, and the same use area.
It sounds like you have your "main" project for the edge system on the backend gateway, and then you use EAM agents to update the edge system that way when you make changes? Is that correct?
Technically, just a 'central gateway'. Though, frontend / backend might happen in the next couple of years. We combine & send projects periodically. You can also send them on-update (via system.eam.runTask). EAM is included with Edge, and the cost of a single controller is well-worth the $ for this type of architecture.
) and then creating a central project that pulls some, but not all, of the information/tags from the edge systems. If, however, you're hoping for identical functionality at the central for each system that may be a different story. In that case I would take some time to figure out a nice way to launch a client for whichever of the 400 systems you're hoping to target from the central location's project rather than trying to duplicate the functionality in a second project.