Architecture Question Using Edge Panel

Ignition
1

Hello Everyone.

I am looking for a little bit of guidance and some answers on a system I am proposing.

Client has 10 furnaces. History stored in a central SQL database. Recipes are stored in a central SQL database. Current SCADA system and architecture are ancient.

What I want to propose (if I'm understanding Edge correctly) is the following:

Main Ignition Gateway with Vision Unlimited, Tag Historian, and Batch Reports. SQL Database on it's own server. Each furnace will have a panel PC running Edge Panel.

Create gateway network, Configure Edge sync services, and configure client failover on Edge gateway.

During normal operation, furnace clients connect to the main gateway and are able to run furnace, download recipes from SQL, view history, view batch reports.

If Main Gateway fails, we fail over to Edge Client so operators can still operate the furnace, still see trends, but have no access to recipe system or batch reports.

Assume all 10 furnaces use the same set of windows so when accessing the windows, will have a custom parameter for Furnace # and use indirect tags on the windows and for trends.

Questions:

Should I be able to use client tags to set the Furnace # parameter and how does that work with the failover?

Do I create the tags only on the Edge gateways or do I need tags on Edge gateway AND Main Gateway using remote tag providers

Do I need two sets of the main windows (minus the recipe windows) since the windows on the main gateway would reference the tags differently that when they are running on the Edge client?

When I create trend screens, do I point to the remote tag providers which only give me two weeks or can I point to the DB since I am syncing?

Any insight or lessons learned here would be helpful.

Thanks in advance!

2

I recommend not using Edge in this scenario. Spend those $$ on the license for a redundant backup gateway. Instead of Edge Panel for local HMI's, just use cheap touchscreen PCs to run Vision. Much more robust and easier to maintain, and you loose no client functionality at all on failover.

Use a startup script in Vision to examine the local client's IP address, machine name, or MAC ids to set the furnace number in a Vision Client Tag.

2 Likes
3

Hey Phil thanks for the input. Seems you're always fist in line to help me out!

I had considered that strategy early but the customer is excessively paranoid about the network failing and wants to try to keep local availability. They have this really complicated scheme now where history is created at each furnace and forwarded to SQL every hour. And if they lose view while furnace is running it's a big deal.

I'm gonna go back and give them the option though. I think with a little budget we could make the network a little more fault tolerant and it would be a easier and less convoluted solution.

Failing that, any thoughts on the other questions?

4

Client tags are not carried into local client fallback.

To share realtime tag information, you create the tags on the edge gateways, then create corresponding realtime tag providers on the central gateway. You can enable read/write/edit for the shared tags on each Edge gateway, and then you'll be able to seamlessly manage them from the central gateway.

Use explicit tag provider references/indirect tag bindings everywhere, and you can "just" provide a tag provider name in some root container property/client tag/etc, and all the bindings will continue to work. This requires discipline when adding components, to make sure something doesn't appear to work on the main gateway and stop working when you fail over.

Note also, since it's a little hard to glean this information until you've done the full set up yourself:
The Edge panel 'fallback' projects are completely independent from the 'main' gateway project. If you want them to be kept in synchronization, that's up to you to do. EAM can help with this, but it's still something you have to set up. So even if the project has the same windows with the same paths, when fallback kicks in, you are closing 'main' and opening 'fallback'. It's also a sticky, one-way failover (automatically) - if you want to 'switch back' to the main project, you'll have to add that functionality yourself via e.g. system.util.retarget.

5

Awesome info thank you so much.

I still like Phil's way better but I like having a plan B in my back pocket.

6

Then an Edge system that collects and forwards data to a main Ignition is a single point of failure. If you go the Edge route, your main gateway will need duplicate tags and device connections, and you'll end up with two sets of history. Ewwww!

I recommend making your network/server architecture robust. Some suggestions:

  • Dual infrastructure network switches in the plant datacenter, but in separate physical racks with separate power, etc. Or, perhaps, two datacenters, at opposite ends of the plant. Tie together with Rapid Spanning Tree Protocol or your IT group's favorite alternative.
  • Dual physical hypervisors co-located with the infrastructure switches, but include trunk ports to both switches. (Also using RSTP.)
  • Dual network drops to each furnace's local network, from each infra switch. (More RSTP.) Perhaps device level rings on the furnaces themselves.
  • Ignition redundant gateways split across the two hypervisors.
  • Master database and redundant replica split across the two hypervisors. (I recommend PostgreSQL with its Replication Manager service, fwiw.)

What Paul said... :grin:

7

Excellent thank you!

8

Call me pedantic but have you been working on your image driver today using Real Time Streaming Protocol =)

1 Like
9

No, but I answered a question about it earlier. :neutral_face: