We are tasked with the creation of an Ignition MES monitoring system to deploy to a large number of similar plants. We want to allow the individual plants to be able to create some custom reports and views, but we want to be able to push updates from the central Ignition config. We are in the middle of the POC deployment now, but I want to make sure we are headed in the right direction. Currently on 8.0.16 but moving to 8.1 shortly.
We have a base project ‘global’ that contains only scripts. We have a derived project ‘Corporate’ that contains most of the views and reports. There is another project then derived from "Corporate’ called ‘Site’ that is for the plant to create custom reports and add views that may be specific to them. The plan would be to copy this project layout to the next plant and use a similar tag structure. We’ll clearly need to create UDTs based on what we are learning for alarming, etc.
I think this will work in general, but I have some concerns about Gateway Event scripts and reporting. From what I’m seeing Gateway Event scripts will not fire from an inheritable project, so it appears that firing of timed events needs to be in a leaf project, but I want to keep as much as possible out of the plants leaf project . It sounds like some people advocate creating a separate leaf project just for firing off scripts. I’m not sure if that’s the best way to go, but maybe. I really want to keep the ‘Site’ leaf project as simple as possible.
Has anyone written a handy-dandy guide to structuring enterprise projects?
We want (need) to allow them some autonomy. While similar, they all have unique equipment, processes, and needs. We don’t have enough centralized manpower to respond to all their needs, so we will have to rely on local experts to create custom reports for views for each location as needed.
It seems like it would be very difficult to try to write one monolithic project to try to cover everyone’s needs (50+ plants). Maybe that could be done, but it seems like a big task. We are trying to cover the majority with the common project and let the local teams tweak what they need for that plant in the derived ‘Site’ project.
understood. I have seen in many instances where people try and be too granular and just cause themselves (or those of us that have to fix or work on the system in the future) alot of trouble.
I really appreciate your input. The more I think about it and the more I see some of the quirks with inheritance the more I think you may be on to something there. It’s got me rethinking our strategy.
As a former full time Java developer it drove me nuts when people added extra layers of abstraction that served no meaningful purpose and just made it harder to untangle.
I can't speak to what will work best for you/your environment, but some general technical concerns to be aware of:
As you are aware, inheritable projects will not run scripts. Inherited projects will, but there's another wrinkle there - all gateway event scripts (startup, shutdown, timer, message handler) are one resource. As soon as any change is made in the leaf projects, you're no longer inheriting from the parent, and there's no obvious way to revert. In the short term, we want to make that more clear in the UI; in the long term, we're hoping to do the obvious thing and separate those script types into distinct resources.
In general, I would say to keep as much logic as absolutely possible in project script resources (which do properly inherit) and just accept some duplication of effort in leaf projects re: timer scripts and the like - which should be as simple as possible and immediately call project scripts anyways. That way your development experience can only get better as we introduce better capabilities, instead of an exercise in frustration as things don't inherit properly, or in unexpected ways.
This is also a good practice to avoid legacy python scoping hiccups. Gateway event scripts of all kinds should be one-liners that delegate to a project script.