A Test Bed for Manufacturing Planning and Scheduling Discussion of Design Principles Sept-22-2007 Claude Le Pape Director R&D Manufacturing Planning and Scheduling clepape@ilog.fr

© 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

© 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

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

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

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

© 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

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

© 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

© 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

© 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

© 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

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

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

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

© 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

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

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

© 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

Questions & Answers Thank You