I am going to be starting a project which involves smart scheduling. Basically I will need to read data from a mutliple db tables to get things like, inventory, sales, prices, OEE of production, etc and come up with production scheduling automatically to make sure things run as efficient as possible. The key is reduce downtime as much as possible and not miss order that need to be filled faster then others. I am wondering if anyone has done anything similar to this and what are things to look out for, questions to ask and also if they have any examples.
That's quite a project. We have had an Ignition-based MES in place for a while now and still can't get to the point of "true" smart scheduling due to the complexity of our operation (and we probably never will).
Start simple... define every parameter that goes into the decision of whether a given piece of equipment is "scheduled" or "not scheduled." You might find that some of these parameters cannot be represented as data points integrated into Ignition, in which case, you can get close to smart scheduling but might need some user input to handle these. I'm guessing you will get stuck at this stage as the complexity will become unmanageable, or data availability will become a show-stopping constraint. Keep an eye on database polling rates and complicated SQL queries... consider a pub/sub protocol like MQTT to get around this requirement. The obligatory follow-up to that point is, a Unified Namespace (UNS) is a good topic to look into if you are not using one.
This problem becomes a question of predicting the future with as much accuracy as possible -- this means the more data you have in one place, the better the prediction that can be made. You may also find you need to store and track more hard data points for your product(s), equipment (including maintenance systems), or anything else like that, thereby increasing complexity for other teams around you.
If you get stuck on the magic function described above, it might help to granularize each input parameter in terms of whether it is available in Ignition (and if not, which user(s) are needed to input it, including when/where/how this happens), how often it refreshes, how confident you are in its value, whether user error might affect its accuracy, any error catching that might be needed, and so on.
Is OEE already being tracked and dumped into a database? If not, I would start there, as it is not too hard to do and can lead to huge gains pretty quickly. For example, you can create an expression tag (UDT) that spits out a realtime OEE value after grabbing some data from production machines via OPC. From there it could be as simple as enabling history on that tag.
Maybe also implement a manual scheduling system (if you don't already have one) so you can compare your function's outputs to what is being manually scheduled and adjust input parameters as needed. Make sure the users doing the scheduling know what they are doing.
Yes that defiantly helped get the wheels turning in my head. Is there any specific module in Ignition that helps this all out or some python functions that can help this? Or with something like this am I stuck to just custom scripting?
Also in terms of parameters is there any rule you used to choose what was needed in the decision making?
In the beginning use as little custom scripting as you can possibly get away with...Instead use built-in features of Ignition like the tag historian, which works well with the Perspective module (which has a handful of time series visualization tools, allowing history-enabled tags to be dragged and dropped quite easily). And the Perspective module works well with tag bindings... Tags are your friend, but it's easy to use them inefficiently or in a way that is difficult if not impossible to scale or maintain. Maybe think less in terms of modules that can specifically help you with automatic scheduling, because like bmusson said, there is no magic bullet. Think more in terms of how you might best utilize the tools inside (or outside) Ignition to create an efficient, scalable, and accurate model of your business process. Figure out which integrations (OT, IT, ERP) you can use to be even more efficient at moving data around. Understand your respective "sources of truth" to keep your data in sync across all systems. These could be entries in a database, values in a tag historian, data out of a PLC, MQTT telemetry, or anything else that is agreed upon by the broader team.
Definitely browse the Ignition Exchange site for some ideas. Follow the value stream of the process when it is unclear which direction to take your development.
Perfect. I really appreciate all the information it has really helped a lot to get a clearer idea. However, I must ask just to better help me even more. Are there any examples maybe a simple one that has been done within Ignition just to have more clarity?
For what it's worth, I've never seen a truly self-determined scheduling, fully automatic scheduling system that works over a long period of time - I'm not saying it's not possible. You can probably get 90% of the way there but the edge cases and funky requirements that every customer has always seems to throw a wrench into the operation.
"This is how we run orders, B U T sometimes on certain Tuesdays, we get an order that must be scheduled at the highest priority - our business depends on it" - that's how those conversations go. Maybe it was the places I worked where this is the case.