Modeling constrained resources

[nightscape]

Hi all,

we have a use case where we would like to model constrained resources (e.g. people or machines) in Baker.
Each of these resources has a corresponding token and those tokens cannot be shared or duplicated.
So a worker could work on process step A but then he's unavailable for process step B (or process step A for another "product" token flowing through the Petri Net).
Is something like this possible, or would it be desirable to have in Baker?
I would be willing to create a PR if I don't have to change the core assumptions of Baker for this.

[nikolakasev]

Hello Martin, to understand better the use-case I'd like to ask a few more questions:

a. Can the number of people (or resources in general) be configurable? For example, five workers taking on a very specific task that no other group of workers can do;

b. If this group of five workers picks up step A, that would mean that there will be five active processes in Baker at that very step and no more, correct? So for example, if a sixth and seventh process gets started and goes to step A, they will first wait for a worker to become available?

c. By "worker", I understand a human intervention in the process. Have you thought of solving this by making some steps in a process actionable via a UI of some sort? For example, list all recipe instances that are waiting on input from a certain step and allow the workers to handle them as they become available? This way you leave this constraint handling (work queue management) outside of Baker.

If I understand correctly, Baker might not be the best fit for this. Have you looked into constrained programming in general and tools like MiniZinc that are very suited for problems like this?

[nikolakasev]

The reason I don't see it is a very good fit is that processes (recipe instances) in Baker are supposed to be independent of each other. This makes the runtime more simple to implement and that's have been a guiding principle for us since the beginning.

[nightscape]

Hi @nikolakasev, thanks for your response!
Regarding your questions:
a. Yes, that is one explicit scenario. Workers have different qualifications, and for one transaction, a worker with qualification A, a worker with qualification B and a certain workstation C might be required. How many workers with which qualifications are available could change from day to day.

b. Sounds correct, although I'm not entirely sure how a process is defined in Baker. Are there multiple running instances of a net, one for every business case that should be handled? In our case, all business cases would/should be handled in one instance of a net, so that at runtime we have an overview like "worker A is at workstation 1, working on product X, worker B and worker C are at workstation 2, working on product Y" and also come up with a schedule what each worker should best do next.

c. Yes, the idea would be that transactions make instructions about what to do next appear on screens at the workstations or on mobile devices of workers. When the worker has finished, he clicks a "Done" button and the transaction completes. Your idea of having the workers decide on which recipe to work on would work, but we want to create an optimized schedule for them which maximizes throughput, minimizes cycle time, etc.

Regarding MiniZinc: We are actually considering something like MiniZinc to do the schedule optimization part. Or did you mean we could model the entire Petri Net via Constraint Programming? I read a thesis where they did this and also performed optimizations, but in my ideal world, we would still think and model in Petri Nets and then generate CP problems/code from the Petri Net.

Do you think Kagera would be a better fit? It seems more basic and afais deals with colored multisets of tokens in places.

[nikolakasev]

Hello @nightscape, I thought about your problem further:

a. I can also imagine that a single worker could have multiple qualifications. You mention a schedule, so I also suppose workers might be on vacation for example or have preferences when they work. It could also be that you want to optimize the process in such a way that a worker can do related work in the minimum amount of days. For example, if two separate steps take 4 hours each, let the worker come on a single day and perform both instead of asking them to come on a separate day. If my thinking out loud is even close, CP is a very good fit and certainly, Baker and Petri nets are not;

b. A process is what we call a recipe instance in Baker. For example if you are making cars and you have a recipe of how to make a car, making each car is a separate recipe instance, hence a separate process. Putting the making of multiple cars in a single recipe (instance) wouldn't follow the design principle of Baker;

Re: Petri nets to CP, I'm actually thinking the other way around. How about you compute an optimized execution plan with CP (availability of workers, work schedules, the importance or criticality of work, etc.), then turn it into a Baker recipe dynamically and let Baker orchestrate that. I remember you can even encode a finite state machine in MiniZinc ;) You will, of course, have to build the UI and the work queue functionality separately because Baker doesn't have those.

I find thinking of constraint programming in combination with Baker a very interesting topic, so let me know if we can collaborate in any way.

Best regards,

• Nikola.

[nightscape]

Hi Nikola, just as an update: I'm currently trying to encode a Petri Net in OptaPlanner which is a Java Constraint Solver that doesn't have multiple solvers like MiniZinc, but seems to be well maintained and could be distributed easily for JVM projects.
Regarding collaboration: Would you be interested in a pair programming session or rather in a more high-level discussion?