Best practices creating projects for sites with distinct independent site areas

I’m wondering what the best practices are when a site has multiple distinct areas. By distinct, I mean the areas are physically separated as well as functionally independent and managed by different sides of the business. For example for a winery, the grape processing and tank farms, and the packaging sides are both completely independent areas usually managed independently. The processing side don’t care about the packaging SCADA, and vice versa, more or less.

To build a project for the whole site, for these areas, is it best to:

  • create a tag provider for each area
  • create a SQL database and SQL database connection in Ignition for each area
  • anything else?

If yes to split tag providers, and both sides use the same UDT types, is this just something that you have to manually synchronise between the two tag providers? Is this something the EAM can help with?
Having tag providers/history separated means backing up individual projects is easier.

Does the site have different IT providers and telephone providers and ISPs? And engineers/programmers that can’t be trusted in the Ignition gateway? (If the latter, you can’t let them use a designer, as a designer can break anything in the gateway.)

Unless this winery is so massive as to have tens of thousands of tags, I’d consolidate/simplify as much as possible for the benefit of the poor soul who will have to take care of it. :neutral_face:

( You, right? )

Whoops, I meant to reply back to this a while ago… All good points. The winery does in fact have 10’s of thousands of tags (174,000 apparently). Does this change anything?

Speaking of poor souls and breaking apart project parts, a customer of ours recently decided to take it upon themselves to do some of their own work. I didn’t know it at the time, but when I connected to the site a few weeks later, I noticed that there were about 5-6 additional projects that had been added, all with almost identical Windows in them. The reason was so that they could just launch a single project to display the different (but very similar) windows on different clients :thinking:

1 Like

EDIT: Man I apologize in advance for this wall of text lol

When I have handled this type of things in the past (before I started working with Ignition, so this is pre-Ignition me talking) typically we’d handle a lot of this with schema changes. So we would break eatch functional section of data into a different schema in the same database. Having one database with many hundreds (if not thousands) of tables is much more common than you would think, the backend for an SAP instance can have stupidly large amounts of tables (I looked at one today with 86,000 tables in one database :flushed:).

In ignition I typically keep a separate connection per schema, with an account defaulting to that schema each. This should help with any automated collection from let’s say the tag historian, from impacting performance for any kind of queries the user might trigger (from my understanding).

In regards to tags, i wouldn’t personally find it outrageous to treat the application as a hub & spoke, with each location an independent edge gateway who is just built to sync and that’s it. Then utilizing edge eam to synchronize any UDT types, etc. I mean fundamentally the cost of the edge node is around $700-800 USD, and it will really start to improve the overall performance of the hub when you don’t have to poll 180,000 tags all from the same gateway, and instead use the GAN to bundle updates on change, and only when necessary. If you really wanna be optimal, MQTT would be a good player here, but idk how much improvement you’d see in this setup vs cost.

Then in terms of project, you know I’m typically in perspective, so this may be different if you’re base is in vision. In Perspective im typically able to make things so dynamic as to setting a session property to my current “location” that I’m interested in, and then just keeping a fundamentally similar tag structure at each edge node to allow the app to dynamically look at different sections. And I’m not just talking about a single template that works for multiple, but maybe an accordion that looks at the different types of units (mix tanks and extruders for example) and can dynamically show entirely different views/types of data based of that unit type. Therefore I will handle all of my visualization through the hub, in the smallest set of dynamic pages possible.

Fundamentally I don’t know if this is the best structure possible, and I’m sure certain @pturmel will have several ways this could be improved and simplified further, but this has been the architecture that my team and I find simplest and the most organized to manage in a scenario like what you’re describing.

In regards to your client adding more stuff to the gateway, I typically try to urge mine not to do this, but it’s their system so they could really do what they want. However we typically clarify that if they start adding their own stuff, we’re not responsible for any performance/data issues caused by their newly constructed together additions. This is also why the first step in any new gateway is to change the admin password, setup credentials with roles for project create/designer, and limit access until someone else needs it. Then down the road there’s at least a small chance that new addition gets bounced off of you before they do it while they try to figure out which roles they need, and you get the chance to help them save time/money by doing things 10x faster.

Not saying these things are all perfect solutions, but they are the best my team has come up with so far.

Especially for tag history.

In a WAN perhaps, but I haven’t found any value for Edge in a facility that has a full install of Ignition on-site.

True for Vision, too.

Yup. My clients tend to be competent modifying their own systems.