Competition on Dynamic Stacking Optimization in Uncertain Environments
tl;dr: In this competition your goal is to write a policy that optimizes crane actions in simulated environments. Your policy receives the current simulation state as input in intervals of 1 second and may send a crane schedule in response or at any other time that contains moves for the crane, e.g. relocate block 15 from stack 1 to stack 2. You have to run your policy on your own machine communicating with our simulation environment in real time. You can develop and test your policy against various training settings and score it for a final ranking against unknown settings. The policies are ranked based on a lexicographic objective as explained further below and in more detail in the documentation of the respective tracks. Leaderboards are available.
Motivation: Stacking problems are central to multiple billion-dollar industries. The container shipping industry needs to stack millions of containers every year. In the steel industry the stacking of steel slabs, blooms, and coils needs to be carried out efficiently, affecting the quality of the final product. The immediate availability of data thanks to the continuing digitalization of industrial production processes makes the optimization of stacking problems in highly dynamic environments feasible.
Rules: Everyone is invited to participate in this competition. The results will be presented during the respective host event where the winner and possibly runner-ups will be announced. It is usually not required to attend the host event in order to participate in this competition. We will forward any official participation or winning certificates to the winner through mail.
Deadline: To be eligible for winning the competition you must complete all scoring simulation runs before the deadline of the respective track.
About: This competition is hosted by Andreas Beham, Stefan Wagner, Sebastian Leitner, Johannes Karder, and Bernhard Werth at the University of Applied Sciences Upper Austria (fh-ooe.at) Hagenberg Campus within the research project Josef Ressel Center for Adaptive Optimization in Dynamic Environments (adaptop.at) led by Stefan Wagner and funded by the Christian Doppler Forschungsgesellschaft (cdg.ac.at). If you have any questions, comments, or suggestions, please don't hesitate to contact us at dynstack@adaptop.at!
Competition
The competition provides several simulations. The first simulation "Hotstorage" was introduced as part of GECCO 2020 and contains a simple
stacking scenario with a single crane, a single arrival stack and a single handover stack. The main challenge is to deal
with unknown and stochastic information that is dynamically changing while solving a simple stacking problem. This is still rather
easy to solve using hand-crafted heuristics.
At GECCO 2021 a new simulation "Rolling Mill" was created that provides a much more challenging scenario where the number of arrival
stacks is raised, and where there are two cranes and two different handovers. In addition, the cranes have a carrying capacity
larger than one and thus overall the second simulation provides a new and challenging dynamic environment for solvers to tackle.
For GECCO 2023, a new simulation "Crane Scheduling" was implemeneted. This is another dynamic warehouse scenario that is derived
from real-world scenarios. It features two cranes, much more buffer stacks, and multiple arrival and handover stacks, where blocks
must be picked up from and dropped off to arriving vehicles. The simulation generates pickup and dropoff moves automatically.
The optimizer is free to submit schedules containing these pre-computed moves, but can also create custom moves to be carried out
by the cranes. In this scenario, more emphasis is put on the scheduling of moves and cranes to minimize crane interference, but
nevertheless, stacking should not be disregarded.
Prize: There will be one winner for each track that receives a prestigious certificate
If you are interested, please create a user account on this website so that we can associate the simulation runs and performances with your user. If you want to quickly dive into experimenting within about 15 minutes, head over to the Getting started section or explore the in-depth documentation of the respective environment. Have fun!
Environment 1: Hotstorage
In this simulation a dynamic environment is provided that represents a simplified, but realistic stacking scenario. It is characterized by three types of stacks called Arrival, Buffer, and Handover as well as a Crane which relocates Blocks between the stacks.
Each of the stacks has a certain capacity. If the capacity is full, no more blocks can be put on the stack. There is an upstream process that spawns new blocks and inserts them at the bottom of the arrival stack. However, if the arrival location is full, the upstream process is delayed which is strongly undesired.
Objective #1 (min): The first objective is to avoid delays in the upstream process.
To avoid such a state, there is a range of buffer stacks that may be used to store blocks for some time. Blocks may only leave the system when they have reached a Ready Date, but should leave it before their Due Date. Blocks must remain either at the arrival stack (at the risk of blocking the upstream process) or at a buffer stack. To remove a block it must be put on the handover stack, after which the handover is unavailable for some time.
Objective #2 (max): The second objective is to deliver as many blocks as possible on time.
A crane is available to perform block relocations within the stacks. This crane can pick up one block at a time
from either the arrival or buffer stacks and drop it off at either a buffer or the handover stack. Such a relocation is
typically composed of four steps:
(1) move to the stack where a block has to be picked up
(2) grab the topmost block from the stack
(3) move to the stack where the block should be dropped off
(4) release the block on top of the stack.
In this crane the crane is always available and performs all orders with
perfect accuracy. Nevertheless, its use should be minimized to save energy and reduce wear.
Objective #3 (min): The third objective is to perform as few crane operations as possible.
It is your task to develop policies which organize the sequence of relocations such that the above objectives are optimized starting from the most important objective (#1) and proceeding in a lexicographic order.
Your policy does not have all information about the world, i.e., it does not know when blocks become ready, it does not know the time required to move a certain block, the time a delivery requires, and the time a new block is produced. However, you will receive estimates about these variables as you progress in the simulation. In addition the performance indicators will be promptly updated and also be available to the policy.
Environment 2: Rolling Mill
In this simulation a dynamic environment is provided that represents a more complex and realistic stacking scenario. It is characterized by three types of stacks called Arrival, Buffer, and Handover as well as two Cranes which relocate Blocks between the stacks. The buffers are distinguished further into shuffle and sorted buffers, which differ only in their maximum height. In the settings the sorted buffers are located more closely to the handover stacks.
Each of the stacks has a certain capacity. If the capacity is full, no more blocks can be put on the stack. There is an arrival process that delivers new blocks from a block yard in batches and puts them atop a random arrival stack. In the real world this happens with the help of heavy vehicles and thus it has to be ensured that either the crane or the vehicle is manipulating the arrival stack. Cranes that are waiting for orders will be moved automatically to make way for the delivery. If the arrival locations are full, the arrival process is delayed. In contrast to the first environment, delaying the arrival process is not considered critical, but can easily lead to the situation that blocks arrive too late for the downstream process - which is critical.
The downstream process always consumes the topmost block at the respective handover stack. It expects a certain sequence of blocks and if there is no block or the topmost block is not the next in sequence a MoveRequest is generated. The handover stack can contain multiple blocks and it is advisable to deliver the blocks in batches. If the handover contains a different block than that in the sequence, a messup of the sequence is recorded. This is highly undesirable as the sequence must be strictly adhered to. Furthermore, if the block is posititioned at the wrong handover stack, the recorded messup is even higher.
Objective #1 (min): The first objective is to avoid any messups of the downstream process.
The downstream process is critical also in that a delay is highly undesirable and should be avoided at all costs. Thus, the policy should ensure the timely delivery of blocks. Sometimes, this is difficult to achieve exactly and thus it is the objective of secondary priority.
Objective #2 (max): The second objective is to minimize the delays of the downstream process (i.e. mill).
To prepare for a timely delivery of blocks, there is a range of buffer stacks that may be used to store blocks for some time. Blocks can be arranged according to their sequences so that the cranes may pick up and drop off larger batches. It is entirely up to the policy how to perform this sorting process and to consider the needs of clearing the arrival stacks while ensuring timely delivery to the handover stacks.
Two cranes are available to perform block relocations within the stacks. Both cranes can pick up more than just one block
at a time. The cranes cannot however move past each other. In addition, the first crane may not reach the handover stacks
while the second crane may not reach the arrival stacks, so all blocks have to be relocated at least once by each crane.
Any such relocation is typically composed of four steps:
(1) move to the stack where blocks have to be picked up
(2) grab the topmost N block from the stack
(3) move to the stack where the blocks should be dropped off
(4) put all blocks on top of the stack
In this environment both cranes are always available and perform all orders with perfect accuracy. Nevertheless, their use should
be minimized to save energy and reduce wear. Assignment of the planned moves to the cranes is carried out by a basic
crane scheduler within the simulation.
Objective #3 (min): The third objective is to perform as few crane operations as possible.
It is your task to develop policies which organize the sequence of relocations such that the above objectives are optimized starting from the most important objective (#1) and proceeding in a lexicographic order.
Your policy does not have all information about the world, i.e., it only knows about the next batch of blocks arriving. The policy does not know about the time it takes to relocate blocks. It is responsible to collect that information and derive meaningful statistics. In addition the performance indicators will be promptly updated and also be available to the policy.
Environment 3: Crane Scheduling
In this simulation a dynamic environment is provided that represents a realistic stacking and scheduling scenario. It is characterized by three types of stacks called Arrival, Buffer, and Handover as well as two Cranes which relocate Blocks between the stacks. Dynamicity is added by dispatching vehicles that enter the system and park at arrival and handover locations. These vehicles must be serviced as efficiently as possible. A crane awaiting orders is automatically making way for the other working crane if need be.
Each of the buffer stacks has a certain capacity. If the capacity is full, no more blocks can be put on the stack. There are arrival/upstream and handover/downstream processes that generate vehicles, which need to be serviced by either picking up all transported blocks from arrival locations (in case of upstream vehicles) or dropping off all required blocks onto the handover locations (in case of downstream vehicles). In the real world this happens with the help of trucks or other heavy vehicles that can park at specified parking locations. Once a vehicle parks, the simulation generates a respective MoveRequest for each block that has to be picked up or dropped off. If all arrival/handover locations are occupied by parking vehicles, newly generated vehicles are queued and dispatched first in first out. Again, in contrast to the Hotstorage environment, delaying the arrival and handover processes is not considered critical.
Parked downstream vehicles always wait until their required number of blocks has been loaded and then proceed to a so called load check. This check records the number of (in-)correctly placed blocks. As downstream vehicles cannot be unloaded anymore, it is critical to correctly load each downstream vehicle. As opposed to the unloading order, the loading order is irrelevant.
Objective #1 (min): The first objective is to avoid any delivery errors in the downstream process.
The up- and downstream processes are critical also in that a prolonged parking time is highly undesirable and should be avoided. Thus, the policy should ensure the timely delivery of blocks. Sometimes, this is difficult to achieve and thus it is the objective of third priority.
Objective #2 (max): The second objective is to pick up and drop off as much blocks, and thus service as many vehicles as possible.
To prepare for a timely service of vehicles, the policy should not prefer upstream to downstream vehicles, or vice versa, but instead treat all vehicles equal. Therefore, the third objective is introduced to track the maximum parking time of any dispatched vehicle.
Objective #3 (min): The third objective is to minimize the maximum parking duration of all vehicles that have been dispatched.
Two cranes are available to perform block relocations within the stacks. Both cranes can pick up one block at a time.
The cranes cannot however move past each other. In addition, the first crane may not reach the very right stacks,
while the second crane may not reach the very left stacks, so some moves may have to be split up into two.
Any such relocation is typically composed of four steps:
(1) move to the stack where blocks have to be picked up
(2) grab the topmost block from the stack
(3) move to the stack where the blocks should be dropped off
(4) put all blocks on top of the stack
In this environment both cranes are always available and perform all orders with perfect accuracy. Nevertheless, their use should
be minimized to save energy and reduce wear. Assignment of the crane moves to the cranes must be done by the policy.
It is your task to develop policies which organize the sequence of relocations such that the above objectives are optimized starting from the most important objective (#1) and proceeding in a lexicographic order. For all dispatched vehicles, the simulation generates MoveRequests that you must fulfill. In addition, the simulation generates CraneMoves that, when executed in order, will fulfill all generated move requests. However, you are not obligated to execute these predefined cranes moves, but create and schedule your own custom moves instead.
Your policy does not have all information about the world, e.g., it only knows the currently parked vehicles and not which vehicles arrive in the future. Performance indicators will be updated periodically and also be available to the policy.