Scheduling multiple concurrent tasks on a linear project to ensure no overlap

4 views (last 30 days)
I have a problem where I have several events that are occurring in a project, the events happen semi-concurrently, where they do not start at the same time but multiple can still be occurring at once. Each event is a team of people working on a linear task, starting at the beginning and then working their way to the end. Their progress is based on a physical distance. I essentially need to figure out each events start time in order for no teams to be at the same location, nor passing eachother, at any point.
I am trying to program this in MATLAB so that the output would be the start and end time for each event. The idea would be to optimize the total time taken for the project.
I am not sure where to begin with something like this so any advice would be greatly appreciated.
  5 Comments
Walter Roberson
Walter Roberson on 8 Jun 2021
To confirm, they have different classes of task, and team 2 will need to do their task on the same sections that team 1 already worked on?
Are the teams each able to handle either task? Even if restricted so that any given day they can only handle one particular kind of task?
Does Team 1 need to process the entire continuous pipeline? Or do they work on a section, then move on to a further section? For example if Team 1 installed the pipeline itself, Team 2 installed the pump stations, Team 3 did the testing and burying, then Team 1 would have to cover the entire distance, but Team 2 would only have to go to the places where the pump stations are to be installed ?
Are there other considerations? For example, if Team 2 works twice as fast as Team 1, then you could schedule
Day 1: Team 1, unit 1, Team 2 not started yet
Day 2: Team 1, unit 2, Team 2 not started yet
Day 3: Team 1, unit 3, Team 2 unit 1 and 2
Day 4: Team 1, unit 4, Team 2 idle
Day 5: Team 1, unit 5, Team 2 unit 3 and 4
and so on, with Team 2 being idle every second day, and the overall project would finish 1 day after Team 1 finished its last unit.
But you could also schedule
Day 1 to 51, Team 1 working alone on unit 1 to 51,
Day 52, Team 1 on unit 52, Team 2 on unit 1, 2
Day 53, Team 1 on unit 53, Team 2 on unit 3, 4
...
Day 97, Team 1 on unit 97, Team 2 on unit 91, 92
Day 98, Team 1 on unit 98, Team 2 on unit 93, 94
Day 99, Team 1 on unit 99, Team 2 on unit 95, 96
Day 100, Team 1 on unit 100, Team 2 on unit 97, 98
Day 101, Team 1 idle, Team 2 on unit 99, 100
Same total time, but probably less expensive since no team would be idle.
Jadon Latta
Jadon Latta on 8 Jun 2021
@Walter Roberson Yes, each team each has a different task, but each team can only complete the task they were assigned. Technically, it is correct that certain teams don't process the entire continuous pipeline, but in terms of how we have productivity represented it is simply a meter/day coverage regardless of whether they only hit a specific area every x amount metres, due to the fact we have travel time considered within our productivity rates.
We also would be doing something more similar to the second option, where we aim to have 0 idling time to reduce costs.

Sign in to comment.

Accepted Answer

Walter Roberson
Walter Roberson on 8 Jun 2021
Let the rates of work be R1, R2, R3, and the total distance be D.
Team 1 should always start immediately and work continuously.
If team 2 is slower than team 1, then team 2 should start after a delay equal to the minimum separation between the two teams (and team 1 will then pull further and further ahead)
If team 2 is faster than team 1, then team 2 should start later, such that
delay2 + D/R2 == (D+minsep12)/R1
where minsep12 is the minimum physical separation distance between teams 1 and 2. You might need a ceil() or two to get the proper separation semantics.
... and knowing the rates and minimum separation, that allows you to calculate the delay.
Then team 3 just has the same logic, except with respect to team 2, so by knowing the rates and minimum separation, you can calculate the delay between them and team 2 fairly easily.
What becomes more difficult is the case where the production rates are not constant. For example it would be expected that the rate of laying down pipeline would be less where there was blasting to be done, compared to loam; the rate of laying down pipeline in wetlands would perhaps be faster than areas where you had to blast, but slower than loam.
Then there are contingencies, especially in the part about laying down the pipeline. For example, you might discover an Artesian well that leads to a section of ground being unacceptably subject to slip-faults, so you might have to re-route.
Or there might have been problems leading to a leak...
  1 Comment
Jadon Latta
Jadon Latta on 9 Jun 2021
Thank you! That works great. We are defintely aware of all of the uncertainties and contigincies, but this program is supposed to be a proof-of-concept so as long as we can produce something, we can deal with those then. I appreciate the help!

Sign in to comment.

More Answers (0)

Categories

Find more on Get Started with Optimization Toolbox in Help Center and File Exchange

Products


Release

R2021a

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!