Unless you live unplugged you certainly saw the astounding pictures of Comet 67P/Churyumov–Gerasimenko taken by the Philae lander. Besides producing nice images, Philae embarked scientifc instruments, each developed by a European laboratory, to accomplish scientific experiments when approaching, and after landing on the comet. Given that communication takes about 25 minutes between Earth and Philae once landed, it was very important to carefully plan every operations of the mission in advance. Indeed, there would be little room to adjust and modify plans after landing.
Credit : ESA http://blogs.esa.int/rosetta/2014/11/13/comet-with-a-view/
The plans for the approach, landing, and for performing all experiments were elaborated on the ground at the Science Operations and Navigation Centre (SONC) in Toulouse, France. The problem was modeled as a constraint programming problem. A software (called MOST) has been developed on top of IBM Constraint Programming technology (Ilog-Scheduler/Solver) to solve this constraint programming problem.
The above description is based on the Rosetta/Philae blog entry by E. Hebreard. With his colleagues, he has published a scientific paper that describes the use of constraint programming for scheduling Philae operations. We reproduce the paper abstract below.
The Rosetta/Philae mission was launched in 2004 by the European Space Agency (ESA). It is scheduled to reach the comet 67P/Churyumov-Gerasimenko in 2014 after traveling more than six billion kilometers. The Philae module will then be separated from the orbiter (Rosetta) to attempt the first ever landing on the surface of a comet. If it succeeds, it will engage a sequence of scientific exploratory experiments on the comet. In this paper we describe a constraint programming model for scheduling the different experiments of the mission. A feasible plan must satisfy a number of constraints induced by energetic resources, precedence relations on activities, or incompatibility between instruments. Moreover, a very important aspect is related to the transfer (to the orbiter then to Earth) of all the data produced by the instruments. The capacity of inboard memories and the limitation of transfers within visibility windows between lander and orbiter, make the transfer policy implemented on the lander’s CPU prone to data loss.We introduce a global constraint to handle data transfers. The goal of this constraint is to ensure that data-producing activities are scheduled in such a way that no data is lost. Thanks to this constraint and to the filtering rules we propose, mission control engineers are now able to compute feasible plans in a few seconds for scenarios where minutes or even hours were previously often required. Moreover, in many cases, data transfers are now much more accurately simulated, thus increasing the reliability of the plans.
The paper is worth a read. i can't resist highlighting this piece: "Except for the data transfer aspect, all the constraints above can be modeled using the standard methods and algorithms  all available in Ilog-Scheduler. Hence, we focus on data transfers and propose a global constraint to reason about this aspect of the problem." This shows that we can both have a quite powerful tool (ILOG Scheduler), and a need to extend it with problem specific constraints (data transfer constraint). The ability to extend constraint programming solvers is one of their key value.
Update on Nov 20. Let me conclude with a comment on the IBM product being used here, namely ILOG Scheduler. It is a great product, but we made quite significant evolutions to our constraint programming offering over the past decade. We now recommend to use CP Optimizer for scheduling problems like the above. Converting applications from ILOG Scheduler to CP Optimizer was discussed in our November 19 virtual user group. Slides and replay are available here.