Modeling Concurrent Constraints

Concurrent constraints refer to conditions that must be simultaneously satisfied when scheduling or executing multiple tasks or activities—particularly when they overlap in time or occur in parallel. Last week, we shared a blog about Aurora’s scheduling decision capabilities, some of which include the ability to handle complex constraints. When you’re dealing with a scheduling engine like Aurora, concurrent constraints, in particular, come into play when more than one task is active at the same time, and the system must ensure that shared resources, timing, and rules are not violated during that overlap. 

Concurrent constraints add complexity to scheduling because the system can’t just treat each task in isolation. It must evaluate how the execution of one task interacts with others, especially in terms of time, resources, and environment. In this blog, we will take a deeper look at concurrent constraints for more realistic project modeling by walking you through a concurrent constraint example.

Concurrent 

The shorter job must be performed during the time span when the job is in work. 

Consider A concurrent B: 

Note that A concurrent B can also be modeled with S<=S and F<=F constraints–except that the combination would vary depending on whether A or B was longer.

In the example above left, where A is shorter, the equivalent would be: B S<=S A; A F<=F B

In the example above right, where A is longer, the equivalent would be: A S<=S B; B F<=F A

Acceptable results:

Unacceptable results:

Finer Points

As with all constraints, you need to be a little careful when constraining groups of jobs to make sure that the relationships will transmit as you intend. However, this is even more true for concurrent constraints than for most constraints, because the exact interpretation of the constraint depends on the relative durations involved.

The result is that concurrency constraints are not transitive, unlike most other constraints. 

Consider the following:

A – concurrent – B

A – concurrent – C

What that actually means in terms of results will depend very much on the relative durations of A, B, and C.

A is longer than B or C

If A is longer than B or C, both B and C will need to occur during A’s life-span. If there are sufficient resources, they may occur at the same time. 

A is shorter than B but longer than C

For this particular configuration, there must be sufficient resources to satisfy all three simultaneously, because there will always be a time period where all three are occurring simultaneously. 

A is shorter than both B and C

For this particular configuration, there must be sufficient resources to satisfy all three simultaneously, because there will always be a time period where all three are occurring simultaneously. B and C will overlap by at least A’s duration. However, there is no requirement that they happen in a specific order.

Ramifications

Concurrency constraints are both more robust and more perilous because of their flexibility. The important point is that they are not transitive (unlike most other constraints).

A F<= S B F<=S C implies that A F<=S C

A – concurrent – B – concurrent – C does not imply that A – concurrent – C.

The main conclusion, then, is that if A – concurrent – B, and A – concurrent – C, and B – concurrent – C, then you need three constraints. As long as you consider whether a pair of jobs should be concurrent, and make a constraint if they should be, the resulting model should be robust.