1. A Test Bed for Manufacturing Planning and Scheduling Discussion of Design Principles
Sept
Claude Le Pape
Director R&D Manufacturing Planning and Scheduling

2. © ILOG, All rights reserved
Motivations
Compare algorithms
Check evolution of algorithms over time (new ideas, better encodings)
Get ideas on how to do better on specific problem classes
11/14/2018
© ILOG, All rights reserved

3. © ILOG, All rights reserved
Outline
The Problem
Integrated Manufacturing Planning, Batching, and Scheduling
The Test Bed: Issues and Choices
Content
Protocol
Data format
Result management
11/14/2018
© ILOG, All rights reserved

4. Planning, Batching, and Scheduling (1)
Too often mid-term production planning, batching, short-term scheduling, and execution control models are applied independently one of another
Ignoring that execution (and data!) is uncertain
Ignoring the constraints of the following level
Ignoring “details” which in fact have a large impact at the following level (e.g., cleaning constraints)
Ignoring that some changes can no longer be done, or cannot be done without incurring delays (e.g., need to heat an oven up)
With no reference to a common objective
11/14/2018
© ILOG, All rights reserved

5. Planning, Batching, and Scheduling (2)
Production planning
Divide the time line in relevant time buckets
Decide
Which amount of which recipe to execute in each bucket
Which demands to deliver in each bucket
On the basis of an abstraction of costs and constraints
Batching
Create batches based on planning results
Large batches allow economies of scale
Small batches bring flexibility
Scheduling
Schedule the batches
Execution Control
Check execution and revise the plan, batches and schedule as needed
(This step is beyond today’s presentation)
11/14/2018
© ILOG, All rights reserved

6. Planning, Batching, and Scheduling (3)
Natural decomposition of the overall problem leads to considering each step separately, but a plan is good only if good schedules can be derived from it.
The first schedule is less costly but the second is more likely to allow on-time delivery of the red products
11/14/2018
© ILOG, All rights reserved

7. © ILOG, All rights reserved
Overall master model
Resources with given capacity and calendars
Materials (raw, intermediate, final products) with storage limitations and costs
Recipes
To be instantiated with given batch sizes
Consisting of activities linked by precedence constraints
Each activity has one or multiple modes specifying the resources to be used, the time needed depending on the batch size, and the resulting cost
Each activity consumes and produces materials in given quantities
Setup initial states, times and costs
Cleanup initial states and recipes
Demands with due dates
Procurements (for raw materials)
Production orders (recipe instances) and material flow arcs
Scheduled activities
11/14/2018
© ILOG, All rights reserved

8. Global OR-oriented optimization model
For each recipe R, define a set of production orders ORi with batch sizes BRi
For each production order ORi and each activity A in R, select a mode MAi, a start time SAi and an end time EAi for the corresponding activity instance Ai
For each demand D, define a set of shipments SDj with quantities shipped QDj and shipping times TDj
Batch sizes, selected modes, activity start and end times, shipment quantities, and shipment times must respect the constraints
The value of the solution is obtained by summing the relevant costs
Note: The same problem can alternatively be described as a global AI-planning optimization model
11/14/2018
© ILOG, All rights reserved

9. © ILOG, All rights reserved
Outline
The Problem
Integrated Manufacturing Planning, Batching, and Scheduling
The Test Bed: Issues and Choices
Content
Protocol
Data format
Result management
11/14/2018
© ILOG, All rights reserved

10. © ILOG, All rights reserved
Content (1)
Conflicting objectives:
Simple (to state) problem instances are easy to reason about, to teach and talk about.
Their complexity is due to a small set of features that are often encountered in real life. Progress of the community on these features has potential impact on many applications. Yet this impact is hard to evaluate as long as the results are not applied to real cases  more realistic instances are needed.
Detailed (real) use cases require too much initial effort, and nothing guarantees that the results obtained will be widely applicable.
11/14/2018
© ILOG, All rights reserved

11. © ILOG, All rights reserved
Content (2)
Instances come from different sources
Some instances are simplifications of a real problem
Less constraints
Smaller size
Some instances come from academia
Hard random instances
Instances generated with respect to a real-life pattern
For each instance, a batching solution is provided allowing one to use the instance
Either for scheduling alone
Or to solve the full problem
11/14/2018
© ILOG, All rights reserved

12. © ILOG, All rights reserved
Content (3)
An instance is identified by
A category defining the active constraints and costs
A number in the category, the higher the number, the bigger the instance
A letter for earliness, tardiness, and storage costs
“a” instances are such that earliness and storage costs are not considered. In addition, tardiness costs are such that different production orders will have (roughly if you re-batch) the same weight.
“b” instances are such that earliness and storage costs are not considered.
“c” instances are such that it is always better to deliver a demand early than to store the corresponding material. In addition, earliness and tardiness costs are such that different production orders will have (roughly if you re-batch) the same weight.
“d” instances are such that it is always better to deliver a demand early than to store the corresponding material.
“e” instances include storage, earliness and tardiness costs.
11/14/2018
© ILOG, All rights reserved

13. Benchmarking protocol (1)
Objectives:
Stress on robustness of generic techniques
Variety of instances
Size
Numeric characteristics
Side constraints
Optimization criteria
Algorithm execution constraints (CPU time limit, depending on computer used), based on what is acceptable is practice
Penalization of relative bad performance, in comparison to other algorithms
11/14/2018
© ILOG, All rights reserved

14. Benchmarking protocol (2)
A recommended CPU time is given, dependent on the size (first digit of the number) of the instance and the power of the computer that is used
0* 1* 2* 3* 4*
10a 25a 50a 75a 100a
60s 150s 300s 450s 600s
5* 6* 7* 8* 9*
250a 500a 1000a 2500a 10000a
1200s 1800s 2400s 3600s 7200s
for a 1 GHz computer
Evaluation: Mean Relative Error
= average(cost-of-solution-found / cost-of-best-solution-known) – 1
Drawback
Reliance on best known solutions (keep changing)
11/14/2018
© ILOG, All rights reserved

15. © ILOG, All rights reserved
Format (1)
Conflicting objectives:
Simplicity
Expressivity
Extensibility
11/14/2018
© ILOG, All rights reserved

16. © ILOG, All rights reserved
Format (2)
Relational format
Each instance is described by a set of tables
Some tables, or some columns in some tables, are optional, depending on the instance category
Some instances are provided in a simpler text format
Easier to start with
Gap to fill when moving from these simple instances to more complex instances
11/14/2018
© ILOG, All rights reserved

17. Management of results (1)
Conflicting objectives:
Keep the results base manageable
Keep non-dominated results
Lower and upper bounds for each instance
Full results for non-dominated algorithms
Full results for the algorithms that are among the best on a given instance category
11/14/2018
© ILOG, All rights reserved

18. Management of results (2)
The results of a problem-solving method that is among the three best methods on a significant subset of instances are kept
Issue: definition of the relevant subsets
The results of other problem-solving methods are eliminated unless this elimination would make a best-known lower or upper bound disappear from the result base
Issue: tie-breaking and dependence on the order in which results are received
No fully satisfactory automatic decision on what to keep
11/14/2018
© ILOG, All rights reserved

19. © ILOG, All rights reserved
Conclusion
Many issues to look at, in the process of defining a scheduling competition
Classification of these issues
Content
Protocol
Data format
Result management
11/14/2018
© ILOG, All rights reserved

20. Questions & Answers
Thank You