There is a long history of planning being applied to hard problems like controlling space shuttle(Chien et al. 2000; Musliner and Goldman 1997) and military logistics(Myers et al. 2011). There are also a few prominent success stories of AI experts having successfully applied it to commercial situations like printing(Ruml et al. 2014), packaged software deployment(Hoffmann et al. 2012), ship navigations(Teng et al. 2017) and IT self-management(Srivastava et al. 2004).
However, planning is still not accessible to developers as other AI sub-disciplines are like machine learning, constraints and (business) rules. There have been occasional reviews of hurdles that prevent planners from getting widely adopted. In (Boddy 2011), the author discusses the representational gap between what the popular language for planning (PDDL) supports and what applications need. In (Ghallab et al. 2014), the authors note that planning has focused more on path-finding methods in a state-transition framework than issues important for executing them.
In this paper, we reflect on the experience of planning-based applications we have done to highlight considerations important in practice. We hope this will help the research community to develop more consumable planners and thereby trigger a mainstream wave of planning-based applications.
In the rest of the paper, we first explain key practical considerations for planners. Then, we summarise how they were handled in 3 planning-based applications: machine learning pipelines, journey planning and web services composition. For each case study, we identify the business problem, the planning-based solution and our approach to promote usage of planning. We then discuss what our experience means for other developers using available planners and identify avenues for improvement.
The traditional focus of planning research has been in developing fast and expressive planners. In contrast, when applying planning in mainstream applications, there are many practical considerations that determine overall success. Some stem from the fact that planners are just another piece of software and hence, must meet well studied concerns of software engineering. Others deal with the unique nature of planning.
Licensing in the software context deals with the legally-enforceable freedom a user has while using a software developed by another party. A license can be unencumbered (e.g., when the user organization itself develops the software for itself), severely restrictive (e.g. single-use license) or in between allowing users to make changes to them (e.g., Apache, GPL and MIT licenses). Planners participating in the AI planning competitions (IPCs)1 have traditionally released source-code for the competition but do not have to make them available to public. Some of the most popular planners like FF and Fast Downward cede some control with GPL, but they may not be usable for commercial products. In fact, most commercial usage of planning is with custom planners that have not participated in the IPCs.
Software Development Ecosystem
While planners have matured rapidly over the past two decades since Graphplan in mid-1990s, the mainstream software development ecosystem has also evolved to reduce its cost drivers – the cost of software development and maintenance. While production software were monolithic C/C++ programs in 1990s built using waterfall process, they turned to interpreted languages like Java in 2000s, adopted service oriented frameworks like web services, and became cloud-based applications in the past few years using Devops (agile) process. Planners, on the other hand, evolved from Lisp programs to C/C++ but very few public state-of-the-art planners are written in Java2 or available on cloud3. As a result, most large applications use planners via a software bridge (Java to C/++, web-based service bridge) but cannot benefit from the planner’s intermediate results (e.g., partial plans).
2 Sapa is an exception.
3 http://planning.domains is an exception.