Software Architecture for Next-Generation AI Planning Systems
SSoftware Architecture for Next-Generation AI Planning Systems
Sebastian Graef a, ∗ , Ilche Georgievski b a M.Sc. in Software Engineering, University of Stuttgart, Germany b Service Computing Department, Institute of Architecture of Application Systems, University of Stuttgart, Germany
Abstract
Artificial Intelligence (AI) planning is a flourishing research and development discipline that provides pow-erful tools for searching a course of action that achieves some user goal. While these planning tools showexcellent performance on benchmark planning problems, they represent challenging software systems whenit comes to their use and integration in real-world applications. In fact, even in-depth understanding oftheir internal mechanisms does not guarantee that one can successfully set up, use and manipulate existingplanning tools. We contribute toward alleviating this situation by proposing a service-oriented planningarchitecture to be at the core of the ability to design, develop and use next-generation AI planning systems.We collect and classify common planning capabilities to form the building blocks of the planning architec-ture. We incorporate software design principles and patterns into the architecture to allow for usability,interoperability and reusability of the planning capabilities. Our prototype planning system demonstratesthe potential of our approach for rapid prototyping and flexibility of system composition. Finally, we provideinsight into the qualitative advantages of our approach when compared to a typical planning tool.
Keywords:
AI Planning, Software Architecture, Planning Capabilities, SOA
1. Introduction
Artificial Intelligence (AI) planning computation-ally solves the problem of finding a course of actionthat achieve some user goal. The planning problemis usually based on a model that describes the worldin a given domain and how to change such a world.The course of action that solves the the problem iscalled a plan. Different planning techniques havebeen developed that produce solution plans. In ad-dition to solving techniques, the AI planning com-munity has invested a lot of effort on approachesfor addressing other planning-related tasks, such asrepresentation and compilation of domain knowl-edge, validation of plans, monitoring and executionof plans, and visualisation and explanation of plansand decisions made. We refer to capacities as theseas planning capabilities .AI planning research is at a stage where softwaretools, called planners, can produce plans consist- ∗ Corresponding author
Email addresses: [email protected] (SebastianGraef), [email protected] (IlcheGeorgievski) ing of hundreds of steps in basically no time. Theplanners are traditionally evaluated on benchmarkdomains the majority of which are synthetically cre-ated for the International Planning Competitions(IPCs), and only few seem to stem directly fromthe real world (e.g,. power supply restoration [1]).The excellence of planners is largely demon-strated within the scope of scientific applications.Outside of this scientific scope, there are severalstudies reporting on the use of planners for real-world domains, and on the integration of planningin actual applications and systems. Examples in-clude Web service composition [2], games [3], spacemissions [4], and ubiquitous computing [5]. Exceptmaybe for the domain of games, there is hardly anyother evidence on the wide and continuous use ofplanning in real-world applications.Given that AI planning has been recognised ascapable of application to realistic domains, thequestion that arises is why AI planning has not beenwidely used in practice. It might be that real-worldand modern applications require planning toolsthat are interoperable, modular, portable, main-tainable, and reusable. Planning software compo-
Preprint submitted to an Elsevier Journal February 23, 2021 a r X i v : . [ c s . A I] F e b ents need to be compatible with each other andother application components, thus designed for in-teroperability. Modularity requires from planningtools to have well-defined and independent func-tionality. The modularity together with evolvabil-ity should provide for high maintainability, i.e., easyfixing of issues or modifying some capability.Software systems with such considerations aretypically designed and developed following funda-mental software design principles at both architec-tural and component level. Research in AI planningappears to alienate the planning tools from suchconsiderations principally due to their orthogonal-ity to knowledge representation and reasoning asprimary concerns of the community. By examiningexisting planning tools, one can notice that soft-ware design decisions are neither known nor con-sidered. For example, the influential Fast Forward(FF) planner is associated with an architecture thatconsists of two techniques rather than componentsor separate concerns [6], and another prominentplanner, the Fast Downward (FD) planner, is as-sociated with a diagram representing three phasesthat sort of give a coarse separation of concerns [7].Similar observations can be made about planningtools for domain parsing [8], domain modelling [9],plan validation [10], and so on.So, there are no specific engineering approachesthat capture the peculiarities and design decisionsof current planning tools. Also, apart from stan-dard languages for modelling planning problems,there are no standards for planning capabilities.A designer or developer must get bogged down intheory and detail of source codes to use and inte-grate planning capabilities. This situation gets evenworse when the developer would need to look at thescale and maintenance of planning capabilities.Our aim is to address usability, interoperabil-ity and reusability by looking at a collection ofplanning capabilities through the prism of Service-Oriented Architecture (SOA) [11]. We summariseour contributions as follows. • We reduce planning complexity by providing aset of flatting and sizing planning capabilities.This collection of capabilities is not only ben-eficial to our approach but it can also serve asa stepping stone for future software designs ofAI planning systems. • We propose a novel classification of planningcapabilities from an operational and techni-cal view. These classifications provide a new perspective over planning capabilities and newinsights about their properties, commonalitiesand differences. • We propose a new planning architecture inwhich planning capabilities are designed asloosely coupled services that communicate viamessaging. This service-oriented architectureis the first one that considers software designprinciples and patterns for the purpose of pro-viding usable, interoperable and reusable plan-ning capabilities. Another important contribu-tion of the planning architecture is that it sep-arates technical issues from planning-relatedchallenges. • We implement a prototype planning systemand demonstrate the potential of rapid proto-typing, the flexibility of integrating differentservice implementations, and the possibility tocompose the planning capabilities dependingon the application needs. • We asses the quality of our approach and showthat our approach has the potential to im-prove usability, interoperability and reusabilityof planning capabilities in comparison to typi-cal existing planning systems.To the best of our knowledge, no approach ex-ists that discerns a collection of planning capabili-ties from existing planning tools upon which serviceorientation together with software design principlesand patterns are applied. Our work is the first sig-nificant step towards placing a planning architec-ture at the core of ability to design, develop and usenext-generation AI planning system for real-world,modern and future applications.The remainder of the article is organised as fol-lows. Section 2 briefly introduces the field of AIplanning and SOA. Section 3 provides a discussionon related work. Section 4 presents relevant AIplanning capabilities and their classification. Sec-tion 5 introduces the proposed design of planningarchitecture. Section 6 gives insights into the pro-totype planning system. Section 7 presents a qual-itative assessment of our proposal. Section 8 pro-vides a discussion on our architecture, prototypeand assessment. Section 9 finalises the article withconcluding remarks.2 . Background
We introduce the field of AI planning, includingthe basic concepts related to modelling and solvingplanning problems, languages for specifying plan-ning problems, and planners used to solve planningproblems. After this introduction, we turn to de-scribing service-oriented architectures with an em-phasis on loose coupling and integration via mes-saging and patterns.
AI planning is a growing research and develop-ment discipline that originated around 1966 fromthe need to give autonomy to Shakey, the firstgeneral-purpose mobile robot [12]. Over time,many planning approaches have been proposed foraddressing general and more specific problems andaspects. A planning problem , which consists of aninitial state, a goal state and a set of actions, issolved by searching for actions that lead from theinitial state to the goal state. The initial state de-scribes how the world looks like at the moment theplanning process starts. The goal state describesthe goals of the user. Actions represent domainknowledge and describe the transitions from onestate to another. An action consists of precondi-tions, which are conditions that must be satisfiedin the current state so that the action can be ap-plied, and effects, which are conditions that musthold in the state after the application of the action.A plan as a structure of actions is a solution to aplanning problem if the preconditions of the plan’sfirst action are satisfied in the initial state and ifthe goal is satisfied after the execution of the plan.Planning approaches often rely on several sim-plifying assumptions, such as completeness and fullobservability of the initial state, determinism of ac-tions, modifiability of states only by planning ac-tions, hard goals, sequentiality of plans, and noexplicit use of time [13]. These assumptions aretoo restrictive for real-world domains, where com-pleteness of information cannot be assured and planexecution cannot be guaranteed to succeed as ex-pected during planning. In addition, for some do-mains, actions and goal states may not be suf-ficient or adequate to express complex or struc-tured domain knowledge (e.g., as hierarchies). So,much work has focused on developing planning ap-proaches that relax one or more of the assumptions(e.g., [14, 15, 16, 17]), and support specifying ad- ditional knowledge, such as Hierarchical Task Net-works (HTN) planning [18].AI planning approaches are typically imple-mented as software tools, called planners , with thepurpose to demonstrate their performance in termsof speed of planning and quality of plans. Plannersare often only solvers of planning problems, and insome cases planners may include other functional-ity, such as modelling and plan execution. Amongthe most prominent ones are FF and FD due totheir performance advantages. These planners rep-resent the base implementation for many otherplanners (e.g., TFD [19], PROBE [20]). AmongHTN planners, the Simple Hierarchical OrderedPlanner (SHOP) [21] is the most well-known plan-ner that has been extended with numerous addi-tional functionality, such as partially ordered tasksin SHOP2 [22], preferences in HTNPlan-P [23], etc.Other hierarchical planners include SIADEX [24],SH [25], and PANDA [26].Planning problems are typically specified in somesyntax. The most common specification syn-tax is the Planning Domain Definition Language(PDDL). PDDL is a Lisp-based language developedfor the needs of the first IPC in 1998 [27], and hasbecome a defacto standard language for specifyingplanning problems also outside IPC. To supportmodelling more realistic planning problems, PDDLwas later extended with additional constructs, suchas numeric fluents, plan metrics and durative ac-tions [28], preferences [29], probabilistic effects [30]and mixed discrete-continuous dynamics [31]. Formodelling planning domains with HTNs, a few lan-guages exist, such as SHOP2-based syntax, Hi-erarchical Planning Definition Language (HPDL),which is the first language for hierarchical plan-ning built on the basis of PDDL [32], and Hier-archical Domain Definition Language (HDDL) [33],a merely slight modification of HPDL.
SOA defines a way to make software componentsinteroperable and reusable. These can be accom-plished by using common communication standardsand design patterns in such a way that softwarecomponents can be integrated in existing and newsystems without the need of deep integration.The basic building block of an SOA is a service,which encapsulates a capability that addresses aspecific functional requirement, hiding away codeand data integration details required for the service3xecution. This definition entails service loose cou-pling, a key feature of SOA. Loose coupling ensuresthat services can be invoked with little or no knowl-edge of how the integration is achieved in the im-plementation. That is, loose coupling intentionallysacrifices interface optimisation to achieve flexibleinteroperability among systems that are disparatein technology, location, performance, and availabil-ity [34]. In other words, as services are typicallydistributed, the communication between them maybe affected due to various reasons, such as net-work outage, failure of interacting services, speedof data processing or computation, and provision-ing of resources. Therefore, a set of autonomies ofloose coupling among services should be enabled,namely reference autonomy, time autonomy, for-mat autonomy, and platform autonomy [35]. Ref-erence autonomy indicates that interacting com-ponents do not know each other. Only the placewhere to read/write data is known. Time auton-omy means the communication between interactingcomponents is asynchronous. Components accesschannels at their own pace and the data exchangedis persistent. Format autonomy allows componentsto exchange data in different formats, and eachcomponent may not know the data format of theinteracting component. Platform autonomy indi-cates that interacting components may not be im-plemented in the same programming language andrun on the same environment.Software components can work together and ex-change information while maintaining loose cou-pling by using messaging. Under the messaging in-tegration style, two components exchange a mes-sage via a message channel [36]. The sendingcomponent creates a messages, adds data to themessage, and pushes the messages to a channel.The messaging system, or Message-Oriented Mid-dleware (MOM) [37], makes the message availableto an appropriate component. The receiving com-ponent consumes the message and extracts the datafrom the message.
We use Enterprise Integration Patterns [36], orjust patterns , as a way to solve recurring architec-tural problems in the messaging context. The pat-terns are formulated in an abstract way to providetechnology-independent design solutions. Besides,the patterns provide a common vocabulary to maketechnical discussion and reasoning easier to follow.
3. Related Work
Several studies have focused on designing plan-ning architectures, frameworks and service-orientedplanning systems. Since these studies have ap-peared over a longer period (1997-2017), the rangeof architecture designs is also broad. A monolithicplanning framework, called CPEF, is designed tooffer several planning components [38]. Due to thetight coupling of the components, the frameworkhas a lack of flexibility. Usability, interoperabilityand reusability seem to be not considered. An im-plementation of the framework seem to have existedat the time of the publication.PELEA, a generic architecture for planning, exe-cution, monitoring, replanning and learning, is pre-sented in [39]. The architecture seems to be a mono-lithic design with some modular structure where themain focus is on the processing of permanently in-coming data. For usability, a dashboard is offered.Apart from an interface for the execution module,no other interfaces are described. An implemen-tation of the architecture existed that focused onsensing and actuating.A set of planning services and a service-orientedarchitecture for the domain of space mission are dis-cussed in [40]. The architecture does not focus onusability though some visualisation service are en-visioned. To ensure interoperabilty, the standardis-ation of interfaces is discussed. The approach seemsto offer a potential for rapid prototyping since manyimplementations already exist within the domain.The presented approach does not go beyond a the-oretical discussion.The RuG planner is a system designed on thebasis of an SOA and event-driven approach [14].Usability is not specifically investigated though itmight have a potential for a high degree of usersatisfaction due to the incorporating of industryneeds. No particular interoperability considerationscan be observed. The planner integrates an existingconstraint-satisfaction solver, supporting reusabil-ity to some extent. Particular attention is paid tothe scalability of the planner. The system is pro-totypically implemented and empirically evaluatedto demonstrate its performance.The SH planner is a system designed as a service-oriented architecture and offers a high degree offlexibility [41]. Usability is enabled by a Web inter-face for modelling planning domains and problems.The use of RESTful interface offers a certain level ofinteroperability. No reusability is considered. The4ystem is implemented as a prototype and used inthe domains of ubiquitous computing [25] and clouddeployment [42].Planning.Domains is a convenient platform so-lution that does not require any setup [43]. Thesolution is primarily intended for scientific and edu-cational purposes. It provides several RESTful ser-vices that offer only technical interoperability. Onthe other hand, plugins are offered, allowing newfunctions to be integrated. The solution integratesan existing framework to solve planning problems.SOA-PE, a service-oriented architecture for sens-ing, planning, monitoring, execution, and actua-tion, is presented in [44]. It draws architecturalideas from PELEA but transforms them into anSOA. The architecture seems to offer usability byproviding appropriate interfaces. The architecturecomponents are designed to communicate via somemiddleware for cyber-physical systems. Except forcomponent distribution, no particular software de-sign approaches or standards are observable. Thearchitecture seems to have been prototypically im-plemented.In contrast to these existing studies, our ap-proach provides a planning architecture with a largecollection of common planning capabilities. The ar-chitecture design is based on software design prin-ciples and patterns which have not been consideredin the existing studies. Our prototype implemen-tation represents a modern planning system thatdemonstrates the possibility of rapid prototypingand flexibility of composing planning capabilities.We also qualitatively assess our approach with re-spect to usability, interoperability and reusability.
4. Planning Capabilities
Before presenting the planning architecture, wefirst need to identify and collect important AI plan-ning capabilities that will form the basis for the de-sign of the architecture. In addition, we proposeclassifications of the identified AI planning capabil-ities to provide a systematic overview of the differ-ent kinds of properties, features, commonalities anddifferences among AI planning capabilities.
We want to identify and collect common AI plan-ning capabilities necessary to design and implementa wide range of planning-based systems. To do this,we search existing literature describing planners, planning architectures and planning frameworks.We refer to these as planning artefacts . In addi-tion to those identified in related work, we selectseveral prominent planners and systems, resultingin a total of 20 artefacts. We then employ contentanalysis and inductively identify planning function-ality. The outcome is a collection of 18 AI planningcapabilities. Table 1 shows an overview of the anal-ysed planning artefacts and the capabilities identi-fied per each artefact. Sometimes a planning capa-bility service is described but not provided by theartefact itself, or it is not available in all versions ofthe artefact (indicated by “(X)”).We determine three types of artefacts: planners,which are artefacts whose main capability is to solveplanning problems (indicated by “P”); planningsystems with an external planner, which are arte-facts whose range of capabilities goes beyond thesolving capability and integrate an external plan-ner for the solving capability (indicated by “ (cid:98) P − ”);and planning systems with a dedicated planner (in-dicated by “ (cid:98) P+”).A Converting capability performs transformationof planning data from one format to another with-out much complexity. An Executing capability exe-cutes plan actions typically by using low-level com-mands or APIs. A Graph-handling capability pro-vides certain graph utilities that often needed orprove useful to planning techniques. A Learningcapability is commonly used for learning domainmodels or to aid the planning process. Managingand orchestrating capabilities are used as routers orsystem handlers. A Modeling capability representsan interface between users and planning systems.They are used to generate domains and problem in-stances. Monitoring capabilities observe the worldand execution of plan actions, and look for poten-tial execution contingencies. A Normalising capa-bility is especially used in the context of heuristics.Also, some unifying steps can be added to this ca-pability. A Parsing capability is necessary to cre-ate programming-level objects from models speci-fied in the planning languages. Problem generatingcapabilities are used to automatically create plan-ning problem instances from data representing theworld, such as sensor data. A Reacting capabil-ity enables handling unexpected events. Typically,this requires replanning. Planners often use heuris-tics to find plans fast or of improved quality. TheRelaxing capability supports the relaxation heuris-tics [6]. A Searching capability deals with search5lgorithms used to explore the space of planningstates. A Solving capability creates a plan and canutilise any number of supporting capabilities duringthe process. In order to reuse domain specificationsor other elements, Storing capabilities are required.A Verifying and Validating capability is designed todetect possible errors at an early stage. When usersor sensors are involved, it is necessary to filter in-correct inputs to reduce the system load. It is alsoused to validate the correctness of plans A Visual-ising capability is a front-end functionality used todisplay charts, tables, and other statistics.
We classify the identified AI planning capabilitiesfrom two orthogonal views. The first view classifiesthe capabilities according to their operational com-petences, while the second view according to theirtechnical properties.
Our operational view for classification of AI plan-ning capabilities is inspired by the following classesof capabilities defined in a business context for oper-ational processes: core capabilities, enabling capa-bilities, and supplemental capabilities [55, 56]. Corecapabilities are defined as capabilities that provideaccess to a wide variety of domains, make a sig-nificant contribution to the perceived benefits, andare challenging to imitate [56]. Enabling capabili-ties are defined as capabilities that do not providea competitive advantage on their own but are nec-essary for other capabilities [56]. Supplemental ca-pabilities are easily accessible and provide a com-petitive advantage for the user. This class of capa-bilities often requires Enabling capabilities to run.By following these definitions, we classify plan-ning capabilities as follows. The minimal set ofCore planning capabilities consists of the Modeling,Solving and Executing capability. The set of En-abling planning capabilities consists of the Convert-ing, Graph-handling, Managing, Monitoring, Nor-malising, Relaxing, Searching and Verifying & Val-idating capabilities. The set of Supplemental plan-ning capabilities consists of the Explaining, Learn-ing, Parsing, Reacting, Storing and Visualising ca-pabilities.
We now turn the view orthogonally to the tech-nical perspective. It is known that patterns repre-sent scientific and timeless approach to describe the behaviour and context of behaviour [57]. The en-terprise integration patterns instantiate such an ap-proach [36], which we apply on the AI planning ca-pabilities to classify them into appropriate classes.Before we map AI planning capabilities to pat-terns, we want to reduce the complexity of the plan-ning process and its relevant aspects. To achievethis, we view the process as a black-box pipelinebased on the Pipes and Filters pattern [36]. Themain components of this pattern are filter nodes,source nodes, and sink nodes. Filter nodes are pro-cessing units of the pipeline. Source nodes provideinput data to the pipeline, while sink nodes collectthe outcome from the end of the pipeline. By usingthese types of nodes and analysing the AI planningcapabilities, we observe that each capability can bereduced to one of the node types. The left-handside of Table 2 gives an overview of the reductionof the planning capabilities to node types.With this knowledge, we map the AI planningcapabilities to appropriate patterns. The right-hand side of Table 2 gives an overview of the map-ping. The resulting patterns can be grouped intofour classes, namely Endpoint, Transforming, Sys-tem Management and Routing. The Endpoint classincludes patterns that enable software componentsconnect to a messaging system for the purpose ofsending and receiving messages. The Transformingclass encompasses patterns that translate, enrich,normalise or perform any other form of transforma-tion of messages. The System Management classcontains patterns that monitor the flow and pro-cessing of messages and deal with exceptions andperformance bottlenecks of the underlying system.The Routing class includes patterns that enable de-coupling a component that sends a message fromone that receives the message. As a consequence ofthis pattern grouping, AI planning capabilities canbe also categorised in the four classes, providing thetechnical view of classification, as shown in Table 2.The connections among the pattern classes andtheir relationship with the node types is shown inFigure 1. Endpoints represent either source nodesor sink nodes. Such endpoints can call each other orcall filter nodes from the Routing or Transformingclass. System Management also monitors routingand transforming capabilities.
5. Architecture Design
With the collection of planning capabilities andthe classifications, we can design a fully operational6 a p a b ili t y N a m e T y p e Parsing Modelling Solving Visualising Verifying&Validating Executing Monitoring Managing Reacting Converting Searching Graph-Handling Relaxing Storing Learning Explaining Normalising Problemgenerating C PE F [ ] (cid:98) P + XXXXXXX F A PE [ ] P XXXXX F a s t D o w n w a r d [ ] P XXXXXX F a s t F o r w a r d [ ] P XXXXXX G T O H P [ ] P XX M a r v i n [ ] P XXXXX O - P l a n [ ] (cid:98) P + XXXXXXXXXX P AN D A [ ] (cid:98) P + XXXXXXXXXXXXX PE L E A [ ] (cid:98) P + XXXXXX R O S P l a nn e r [ ] (cid:98) P − X ( X ) XX R u G P l a nn e r [ ] (cid:98) P + XXXXXXXX S H P l a nn e r [ ] (cid:98) P + XXXXXXXXXX S H O P [ ] P XX S H O P [ ] P XX ( X ) XXX S H O P [ ] P XXXXXXX S I A D E X [ ] (cid:98) P + XXXXXXX S I PE - [ ] (cid:98) P + XXXXXXXXX S O A - PE [ ] (cid:98) P + XXXXXXX S M P S y s t e m [ ] (cid:98) P − XX ( X ) XXXXX U M C P [ ] P XX T a b l e : A n O v e r v i e w o f P l a nn i n g A r t i f a c t s a nd T h e i r C o rr e s p o nd i n g C a p a b ili t i e s . P i nd i c a t e s a p l a nn e r , (cid:98) P − i nd i c a t e s a p l a nn i n g s y s t e m w i t h a n e x t e r n a l p l a nn e r , a nd (cid:98) P + i nd i c a t e s a p l a nn i n g s y s t e m w i t h a d e d i c a t e dp l a nn e r . “ X ” i nd i c a t e s a s upp o r t f o r a p l a nn i n g c a p a b ili t y , a nd “ ( X ) ” i nd i c a t e s t h a t a p l a nn i n g c a p a b ili t y i s n o t i m p l e m e n t e d o r n o t a v a il a b l e i n a ll v e r s i o n s o f t h e a r t i f a c t . apability Node Type Pattern Class Source Filter SinkConverting X
Message Translator
TransformingExecuting X
Service Activator
EndpointExplaining X
Message Endpoint
EndpointGraph-Handling X
Message Translator
TransformingLearning X X
Message Endpoint
EndpointManaging X
Process Manager
RoutingModelling X
Message Endpoint
EndpointMonitoring X
Control Bus , Wire Tap
System-ManagementNormalising X
Normalizer
TransformingParsing X
Message Translator
TransformingProblem generating X
Content Enricher
TransformingReacting X
Event-Driven Consumer
EndpointRelaxing X
Message Translator
TransformingSearching X
Content Filter
TransformingSolving X
Message Translator
TransformingStoring X
Message Store
System-ManagementVerifying & Validating X X
Content Based Router , Detour
RouterVisualising X X
Polling Consumer , Event-Driven Consumer
Endpoint
Table 2: Technical Classification of AI Planning Capabilities
Endpoint
SystemManagement
Routing
Transforming
Source&Sink Filter
Figure 1: Relationships Between Pattern Classes and NodeTypes planning architecture. Next, we determine the re-quirements of interest and structure of the planningarchitecture, and then we provide some general andmore specific consideration for the architecture de-sign.
While current planning artefacts provide pow-erful means to search for and execute plans, theylack qualities as software systems. Planning arte-facts are often functionally overloaded to meet thegoals, which increases the complexity and reduces the level of usability, which is the first requirementof our interest.Since real-world planning problems are too com-plex to be solved by a solving capability only, theproblems are often decomposed into sub-problemsthat need to be handled by separate planning ca-pabilities, such as modelling, execution and reac-tion. These capabilities in turn must communicateamong each other and with external services, thusexchange messages. So, the second requirement ofinterest is interoperablity.Many planning artefacts require the same plan-ning capabilities for full functionality. For instance,numerous planning artefacts require a PDDL pars-ing capability. Currently, the planning artefacts ei-ther implement their own version of a parsing ca-pability or integrate full planners to use the plan-ners’ parsing functionality. So, enabling reusabilityof planning capabilities is the third requirement weconsider in the design of the planning architecture.
Usability starts on the interaction side. Indepen-dent of the user’s skills, the user should be able to8se the planning capabilities. Thus, a certain levelof “ease of use” is mandatory for planning capa-bilities to be usable. With good usability, it doesnot matter if a planning capability is a front-end orback-end service; the appropriate usability criteriaare the same. According to the ISO 9241-11 stan-dard [58], we need to maximise the effectiveness,efficiency and user satisfaction.
Interoperability is majorly achieved by using uni-fied models on every endpoint. So, the concepts forloose coupling and messaging are mandatory. Ac-cording to [59], four levels of interoperability shouldbe considered for the design: organisational, seman-tic, syntactic and connectivity level. On the organ-isational level, we must ensure that each planningrequest follows a purpose. This level contains astrategy, choice of interacting component, and out-sourcing parts of the functionality to other services.On the semantic level of interoperability, we haveto ensure that both interacting services interpret amessage or request in the same way. This means adomain of values, relevant rules, and/or choreogra-phy must be provided to ensure equivalent handlingbetween interacting components. On the syntacticlevel, we need to focus on the notation (format)of a planning request. The message must followthe structure according to defined schematics. Inmost cases, RESTful Application Programming In-terfaces (APIs) or messaging channels use JSONor XML as a message format. On the connectivitylevel, we need to deal with a protocol as an essentialstep for transferring a planning request. This levelrequires a selection of a message protocol and rout-ing to the correct endpoint. Note that, to achievethe best possible interoperability, planning capabil-ities have to aim for the best interoperability oneach of the levels.
To mitigate or reduce the development effort fornew AI planning capabilities, the reusability of ex-isting planning concepts and services is indispens-able. To allow reuse of planning capabilities, thenumber of dependencies has to be minimal. Thisrequirement is also related to the loose coupling au-tonomies (see Section 2.2). To support the reusabil-ity of planning capabilities, we consider the follow-ing quality characteristics: portability, flexibility,and understandability. For details on these charac-teristics of reusability, we refer to [60].
Our choice for the design of the planning architec-ture falls to a decentralised approach as it offers thebest properties to achieve loose coupling. First, thecommunication between capabilities based on mes-saging in the publish-subscribe stack is most oftencharacterised by good performance, which is espe-cially useful in systems with a high load and sev-eral clients, such as in energy smart systems [25].Second, decentralised planning systems may scalevery well horizontally since each planning capabil-ity would have its own incoming and outgoing topic.Furthermore, the automatic configuration detectionin MOM helps to add new planning capabilities dur-ing a system’s runtime. The most crucial point isthat planning capabilities themselves can requestother capabilities directly without another gate-way, checking the availability first. Finally, sinceit is essential to increase reliability and not violatethe principles of services, the planning capabilitiesmust be designed and implemented to be stateless.Therefore, our choice for the design of the planningarchitecture falls to the decentralised approach.
We design the planning architecture consideringgeneral service requirements (see [61]). The ar-chitecture aims at defining a composition of plan-ning capabilities and thereby facilitating their im-plementation as services. Our proposal for the de-sign of the planning architecture is based on the
Hub-and-Spoke pattern [36]. Usually, this kind ofarchitecture pattern is not performing well when itcomes to scaling. However, since MOM providesthe hub, selecting the best-fitting technology forMOM can help overcome this issue. The usage ofthis design pattern also provides an easy solution toconnect new planning capabilities with each otherusing the hub.Figure 2 shows an abstract overview of the plan-ning architecture. The architecture consists of afront-end service, MOM, and various back-end ser-vices. Due to the ease of implementation, we pro-pose communication of the front-end capabilitiesbased on RESTful Web services for synchronouscalls and Web Sockets for asynchronous messaging.Using these standard Web communication conceptsalso enables the simple integration of security fea-tures (e.g., HTTPS and JWT on the header).Figure 3 shows the complete architectural de-sign. It can be observed that the architecture pro-vides great opportunities since the operational and9 ystem «Service»
Capability «MOM»
MessageBroker «Service» [...] Capability «Service» [...] Capability «Service» [...] Capability «Service» [...] Capability
Publish &Subscribe Uses
Customer
Figure 2: Abstract Overview of the Planning Architecture technical classes also specify the context of use.The range of functionality can be extended signifi-cantly by implementing different capability serviceinstances for the same capability class. Some capa-bilities require different interfaces to work in a suf-ficient way. For instance, the Executing capabilityrequires interfaces for action invocations. Besidesthis, the Storing capability requires a database todo not violate the stateless principles of services.Since front-end capabilities require a bridging ser-vice to access the MOM data, a Managing capabil-ity is utilised. All other capabilities are connectedusing messaging on a publish-subscribe basis.User interaction is also considered by accountingfor appropriate graphical user interfaces throughwhich information can be passed to the system.This information mainly refers to models of do-mains and problems, or configurations. Addition-ally, a Visualisation capability is envisioned to dis-play relevant results (e.g., sequential plans) and toprovide monitoring figures or statistics. The designdoes not put any restrictions on the use of third-party API.
We propose the following template for namingMOM topics:
The last part of the template ( ) defines thehandling of instances of a capability. Note that acapability instance refers to an implementation in-stance rather than a service instance for high avail-ability. This value should not be a unique instanceID since horizontal scalability is necessary. In caseof multiple instances of the same planning service,a common name should be used to enable paral-lel execution of tasks. Therefore, the architecturedoes not define any implementation detail. Onlythe existence of an additional sub-topic or flag isimportant.To avoid blocking, outgoing topics are not pro-vided since this would encourage polling endpoints. It is necessary to specify a response topic in a re-quest message to route the message after its pro-cessing dynamically. The underlying pattern is
Request-Reply with an extension of the
Return Ad-dress pattern [36].
If a capability service needs to assign a sub-taskof its planning task to another capability, the stateof the process must be stored temporarily so thatthe capability service becomes stateless and non-blocking after the assignment (i.e., sending a mes-sage). To maintain the IDEAL properties of thefuture system (see [35, 62]), the use of an isolatedstate is necessary. Therefore, the planning capa-bilities that call other capabilities to place requestsmust store the state externally. To merge the re-sults of sub-tasks in the corresponding capabilityservice, a so-called correlation identifier is used toguarantee the correctness of the correlation [36].
We now describe the adopted integration pat-terns per technical class. These patterns can beapplied to all capability services of the respectiveclass.
Endpoint planning capabilities
Since Endpoint planning capabilities can occur indifferent variants, a general pattern is not applica-ble. Therefore, a distinction between front-end andback-end services is necessary.
Back-end capabilities.
All planning capabilitieswithin the Endpoint class that do not have to pro-cess direct user input can be considered back-endcapabilities. Figure 4 shows an example for the pro-cessing of a planning request. The following stepsare performed (also highlighted in Figure 4):1. The back-end service has an established sub-scription to its incoming exchange topic andstarts processing the message.2. The request is received and placed in a queue.All the requests will be processed after eachother (i.e., a first-in-first-out order). The re-sults are pushed to the corresponding replyqueue.3. The response is taken from the reply queue andsend to the corresponding topic.10
System» B acke nd PubSubPubSub « M O M » M essa g e B r o ke r PubSub PubSub
USER
Interface InterfacePubSub PubSub PubSubPubSubPubSubPubSubPubSubPubSubPubSubPubSub PubSubPubSub F r on t e nd RESTWebSocket WebSocket «Service»
Modelling Capability C «Service» Visualizing Capability S «Service» Monitoring Capability E ..«Service» Managing Capability E «Service» Solving Capability C «Service» Parsing Capability S «Service» Searching Capability E «Service» Converting Capability E «Service» Explaining Capability S «Service» Learning Capability S «Service» Relaxing Capability E «Service» Executing Capability C «Service» Storing Capability S .. «Service» Unifying/ Normalizing Capability E «Service» Graph-Handling Capability E «Service» Problem Generating Capability E «Service» Reacting Capability S «Service» Verifying & Validating Capability E .. core E enablingsupplemental CS System Management .. Transforming Endpoint Router t e c hn i c a l ope r a t i ona l Modells:Domain & Problem Plan/SolutionGraphs
Figure 3: Overview of the Planning Architecture MOM»
Message Broker publish «Service»
Endpoint (backend) Capability v1.endpoint.X-capability
Subscribe ... v1.endpoint.X-capability.in Exchange Topic Queue v1.endpoint.X-capability.reply.ANY legend: Figure 4: Back-End Endpoint Capability
Front-End capabilities.
All planning capabilitieswithin the Endpoint class that have to process di-rect user input can be considered front-end capabil-ities. Figure 5 shows an example for the processingof a user request. The following steps are performed(also highlighted in Figure 5):1. The front-end capability service receives newinformation from user input. All informationis placed at the request body of a RESTfulPOST message.2. The front-end capability service calls theRESTful endpoint of a routing capability.3. The Routing capability service process the re-quest and sends it to a Solving capability usingMOM.4. After the system processed the request, the re-sponse or error is passed back to the routingcapability. A Web Socket is used to send theasynchronous response back to the front-end.5. The front-end receives the response or acustom-error and processes it (e.g., visualisesit).
Transforming capabilities
Since all planning capabilities in the Transform-ing class are identical from an architectural pointof view, one pattern can be applied to all of them.Figure 6 shows a processing of a simple request bya transforming capability. The following steps areperformed (also highlighted in Figure 6):1. Service A creates a new request and pushesthe message to the corresponding transformingtopic in MOM.2. The transforming service has an establishedsubscription to its incoming topic, and themessage is pushed to the queue of the trans-forming capability.3. The transforming service process the requestand sends it to the given response topic. 4. The response is placed on service A’s capabilitytopic in MOM.5. Service A has an established subscription to itsincoming topic and starts processing the mes-sage.Since the architecture allows dynamic routing,the transforming capability is free to decide if anyother transformation is necessary to reach the re-quested response format.
System Management Capabilities
System management and monitoring capabilitiesdiffer slightly at the architecture level. Only theorigin of the information varies within MOM. Anexample of behavior of the system management ca-pability includes a step in which the service estab-lishes a subscription to at least one topic and an-other step to process a message.
Routing capabilities
Since there is only one capability classified as arouting capability yet, one architecture pattern canbe applied. The basic functionality is similar to theone for the front-end endpoint capability. Here wefocus on the global error handling that is done bythe Routing capability. Figure 7 shows the archi-tecture pattern and behavior for the Routing ca-pability. The following steps are performed (alsohighlighted in Figure 7):1. Service A throws a custom error on processinga request. The request is handled and sent tothe routing capability topic.2. The routing service consumes the messagefrom the topic and pushes it to the correctqueue.3. Normally the request is pushed to the in-queue(step 3 . .
6. Implementation
As a proof of concept, we implemented a proto-type planning system whose deployment diagramis shown in Figure 8. It consists of five planningservices that provide a fully functioning planningsystem. Besides the general division into front-endand back-end services, the technologies used for the12
Service»
Routing Capability «Service»
Endpoint (fontend)Capability
REST Exchange Topic Queuelegend: subscribe v1.router.X-capability.replyREST Controller WS WebSocketREST Client WebSocket Client «MOM»
Message Broker v1.
Message Broker v1.class.X-capabilityv1.transforming.X-capability... «Service» Transforming Capability v1. transforming.X-capability.replyv1.transforming.X-capability.in sendsubscribe «Service» Capability v1.class.X-capability.insender sendsubscribe Exchange Topic Queuelegend:
Figure 6: Transforming Capability «Service»
Routing Capability v1.router.X-capability.inv1.router.X-capability.error «MOM»
ParsingRequest interface, which includes syn-tactic models of a planning domain and probleminstance. To reduce the size of messages, the in-put should be given as base64 strings. The inputis interpreted according to the stored informationin the call stack. To manage multiple syntacticforms of inputs to this service (e.g., PDDL, HDDL,SHOP), we use the
Strategy pattern, which allowsencapsulating a set of interchangeable algorithmsindividually [63]. The basic approach towards theimplementation of this service consists of convert-ing internal data models into wrapped data modelswhich are in turn serialised and provided as JSON https://spring.io/reactive System» B acke nd PubSub PubSubPubSub
USER
Solutions ->UI ModellsDomain & Problem PubSub F r on t e nd RESTWebSocket «Service»
Modelling Capability «Service»
Managing Capability «Service»
Solving Capability «Service»
Parsing Capability «Service»
Converting Capability «MOM»
MessageBroker
Figure 8: Deployment Diagram of the Prototype Planning System messages. The conversion is accomplished by theConverting capability.The service implementation parses PDDL plan-ning problems. This is accomplished using thePDDL4J library [64]. For other alternatives, seeSection 8.
We use the converting capability to demonstratethe dynamic routing and independent insertion ofintermediate steps, such as encoding of planningproblems. The encoding step transforms a givenplanning problem into its final form. Such a trans-formation is typical for most PDDL-based plan-ners [64].The Converting service requires implementa-tion of the
EncodingRequest interface. Sinceour prototype completely supports planning prob-lems specified in PDDL, we implemented the en-coding of PDDL to a finite domain representa-tion using the PDDL4J library. We created a
PddlEncodedProblem class that follows the objectstructure of the library. We wrap the whole datastructure by custom classes to avoid serialisationproblems. This implementation choice preservesthe representation of a given planning problem as acausal domain transition graph, which provides anefficient way to determine which propositions areaccessible from the current state [64].
The Solving capability requires implementationof a
SolvingRequest interface with four argumentsabout the chosen planner, chosen planning lan-guage, domain, and problem instance. A user canselect a planner and planning language. The servicesubsequently decides on its own authority whichplanning capabilities are to be used. That is, the solveProblem() method is called, which sends arequest to the Parsing capability. This connectionis currently preconfigured, but the ultimate objec-tive is to search a repository for required interfacesand select an appropriate service interface. Thecornerstone for this is already implemented in theManaging capability.After receiving a reply from the Converting ca-pability, the solving of the given planning problembegins. Since the data model may not contain aplanner field for the response, the call-stack stateis used at this point. Depending on the embeddedplanner, different types of plans can be produced(e.g., sequential plans or partially ordered plans).All results are forwarded according to the call stack.In our case, the user can select planners withdifferent search strategies and heuristics as imple-mented in the PDDL4J library. For other alterna-tives, see Section 8.15 .5. Modelling Capability
The Modelling capability provides a Web inter-face that enables a user to model planning prob-lems, select a planner, send a solving request, andinspect a found plan. It also provides login, mon-itoring and administration functionality, such asoverview of the system and states of capabilities.In case of errors, the Modelling capability providesthe stack trace and a reference to the correspond-ing service. The modelling of planning problems isenabled by a WEB IDE implemented using ACE with syntax highlighting and folding provided bythe WEB planner [65].
7. Qualitative Assessment
We now provide a qualitative assessment of ourapproach. We analyse the usability, interoper-ability, and reusability of the planning architec-ture/prototype in comparison with a typical AIplanning artefact. To visualise the comparisons ofthe quality data, we use radar charts. Each qualityattribute is divided into several indicators each ofwhich gets a score assigned. The score describesthe general suitability of the architecture/artefactwith respect to the indicator. We use {− , O, + } as a score range, where each score is correlatedwith a value as follows: “ − ” ≡ .
0; “ O ” ≡ .
5; and“+” ≡ . Since we are not completely interested in user in-terfaces, we focus on usability from a developer’spoint of view. We assess usability considering threeindicators: effectiveness, efficiency and user satis-faction. Figure 9 shows the scores of these usabilityindicators. It can be observed that our approachscores equally or better than a typical planningartefact. We discuss each usability indicator next.
Effectiveness.
We see the effectiveness as a com-position of task effectiveness, task completion anderror frequency [66]. Since we only require exist-ing planning artefacts to be distributed over corre-sponding planning capabilities, the operation andbehaviour of such artefacts would not be affected.As a consequence, the task effectiveness and taskcompletion of integrated planning artefacts are not https://ace.c9.io/ Effectiveness EfficiencyUser satisfaction
Our ApproachTypical Planning Artefact
Figure 9: Radar Chart of Usability Indicators compromised. If our planning services are dis-tributed over a network, the probability to have ahigh error frequency may grow due to service un-availability. This would not be the case with typicalplanning artefacts. However, our planning architec-ture and prototype support resilience by allowingmultiple service instances to run and using a mes-saging system. We can conclude that the generaleffectiveness of our approach is as high as a typ-ical planning artefact without network dependen-cies. Thus, both score “+”.
Efficiency.
We use two indicators for the efficiency.The first one is related to the first startup of a sys-tem. Since most planning artefacts have a largenumber of dependencies, the first startup is typi-cally time-consuming. On the other hand, our ap-proach is a platform solution that only requires aWeb browser available in any standard computingdevice.The second indicator is related to system run-time from the moment of submission of a planningrequest. Under the assumption of identical com-puting power, our approach might be slower thata typical planning artefact due to serialisation andmessaging, which may require additional comput-ing power. We should also consider that our archi-tecture design offers the possibility of parallelisa-tion. As a consequence, our approach and a typicalplanning artefact both score “+”.
User Satisfaction.
We can assume a high degreeof user satisfaction can be achieved by providingfront-end capabilities. However, due to the abilityto extend capabilities, our architecture offers a sig-nificant advantage over a typical planning artefact.16 .00.51.0
Connectivity SyntacticSemanticOrganisational
Our ApproachTypical Planning Artefact
Figure 10: Radar Chart of the Interoperability Indicators
So, the probability of being able to deliver a de-sired function is correspondingly higher than witha typical planner. Since most existing planners onlyprovide or require a command-line interface, the re-quired knowledge and user involvement is high, anderrors due to wrong interaction can occur more eas-ily. Therefore, our approach scores “+”, while atypical planning artefact scores “ O ” for user satis-faction. We assess interoperability using its four levels asindicators: organisational, semantic, syntactic andconnectivity level. Figure 10 shows the scores ofthe interoperability indicators. We can observe thatour approach has better scores than a typical plan-ning artefact. We discuss each indicator next.
Organisational.
Our approach achieves organisa-tional interoperability guaranteed by the architec-tural design and the clarity of purpose of each capa-bility. On the other hand, planning artefacts typ-ically are not associated with architecture designsand the purpose of a certain artefact and its com-ponents should be deduced either from a relevantpaper or code if available. As a consequence, ourapproach scores “+”, and a typical planning arte-fact scores “ O ”. Semantic.
Due to the distribution of capabilitiesin our service-oriented architecture, API documen-tation is necessary, which we accordingly provide. Our approach gives processing guarantees by spec-ifying the expected return type, but no mandatoryvalidation is performed. Thus, it is theoreticallypossible to misinterpret objects if they are misused.This can be further reduced if service interfaces aresufficiently documented. Therefore, we assign the“ O ” score to our approach. In a typical planningartefact, semantics are only provided in a corre-sponding scientific paper, while software documen-tations are rarely given if at all. As a consequence,the score for a typical planning artefact is “ − ”. Syntactic.
Since syntactic interoperability requiresan SOA, this indicator is not applicable to a typ-ical planning artefact. So, the score is “ − ”. Onthe other hand, our approach is based on SOA anduses a uniform communication format (i.e., JSON).Thus, the score is “+”. Connectivity.
Connectivity requires decentralisa-tion, a property uncharacteristic for typical plan-ning artefacts. We therefore assign the “ − ” score.On the other hand, our approach is decentralisedand supported by commonly used standards andtools. For the front-end, RESTful is used, which isbased on the HTTP protocol. The choice of MOMis RabbitMQ, which is based on the TCP protocol.Both protocols are supported in most programminglanguages. Finally, our approach does not restrictthe choice of MOM. Thus, we award the “+” score. We assess reusability as a composition of the fol-lowing indicators: portability, flexibility, and un-derstandability [60]. Figure 11 shows the scores ofthe reusability indicators. It can be observed thatour approach scores better in all indicators thana typical planning artefact. As before, we discusseach indicator next.
Portability.
Portability can be determined by hav-ing as few dependencies as possible. Our planningarchitecture uses services that encapsulate their de-pendencies. Although the services may have manydependencies to external libraries, the dependenciesare handled during compile-time. It is also possibleto use dependency handlers (e.g., Gradle, Maven)to minimise repository dependency. During run-time, the planning services are entirely decoupledfrom the communication interface. Therefore, weassign the “+” score to the proposed approach.17 .00.51.0
Portability FlexibilityUnderstandability
Our ApproachTypical Planning Artefact
Figure 11: Radar Chart of Reusability Indicators
Most of existing planning artefacts (e.g., Pan-daPIParser [26]) depend on operating system li-braries, which may be due to the programming lan-guage used (e.g., C++) and the design of the arte-fact’s architecture. Rare are the planning artefactsthat offer encapsulated solutions (e.g., virtual im-ages). Even runnable artefacts are often challengingto find, so one has to handle all build dependencies.As a consequence, we assign “ − ” for the portabilityof a typical planning artefact. Flexibility.
Flexibility consists of two components,namely generality and modularity. Our approachoffers a high degree of generality and modularity.This is mainly due to the encapsulation of plan-ning capabilities, which can be also interpreted asindividual modules. Generality is also achieved byusing standard communication. Finally, planningcapabilites are general enough to compose them invarious ways. Therefore, we assign the “+” score.When examining existing planning artefacts, onecan notice that most of them do not use any othermodular structures apart from the division intopackages. Also, the generality of most of the plan-ning artefacts as software systems is low. However,a set of utility functions is often provided, which canbe used independently from the application con-text. This allows a minimal degree of flexibility,thus, we assign the “ O ” score. Understandability.
Understandability also consistsof two components. The first one is documenta-tion. Our approach may have detailed code doc-umentation, however, there is no requirement thatenforces such a description. Complexity is the sec-ond component. Our system’s total complexity is distributed over several services, which decreasesthe functional complexity of the individual services.This should be taken with a grain of salt due tothe communication effort that may incur in a dis-tributed system. Since the functional complexityoutweighs the technical complexity in our context,we assign the “+” score.For existing planning artefacts, the documenta-tion is extremely rare. The behavior of the arte-facts is typically presented in a scientific paper withno guarantee for consistency. Since typical plan-ning artefacts bundle all their functionalities, theirbehavior is relatively complicated. Therefore, thecomprehensibility of their individual components isimpeded and worse than in a system with separateconcerns. Therefore, we assign the “ O ” score.
8. Discussion
The collection of planning capabilities is a resultof a qualitative analysis of a set of planning arte-facts. This is performed in a rigorous and system-atic way in which all steps and information are doc-umented, guaranteeing its validity. While the setof analysed planning artefacts is not exhaustive, itrepresents a relevant sample of software tools, ar-chitectures and frameworks in which AI planning isthe intervention. This ensures that the collection ofplanning capabilities can be generalisable to a widerpopulation of planning artefacts. The validity andgeneralisability allow us to qualify our analysis andits results as trustworthy.Instead of a decentralised approach for the designour planning architecture, we can go for the optionof a centralised approach that is realised through acentral capability service for pure process control.Since the central capability service would need tobe always adapted when changing a planning capa-bility or the process itself, a centralised architecturewould lack usability. In theory, such a service couldbe set up generically to be configured via its envi-ronment, but this would not be easy to maintainduring production. Besides, scalability would beendangered.Our planning architecture is designed around theconcepts of loose coupling and messaging to al-low for usability, interoperability and reusability ofplanning capabilities. This, however, does not en-tail specifications of standardised interfaces for thecapabilities. The reason for this lies in the currentstate of AI planning and interest of the AI planningcommunity. In particular, from a standardisation18oint of view, the community has so far focusedonly on developing standard modelling languages(PDDL for classical planning and HPDL/HDDL forhierarchical planning). As a consequence, no stan-dards are available for planning capabilities, mak-ing it extremely difficult to design standard inter-faces for planning capabilities such that will sup-port the available planning tools. These findingsare reflected in the planning architecture by allow-ing multiple instances per planning capability. Thiscircumvents the need to operate all planning toolsfor a single planning capability via one interface.In addition, it is a reasonable approach to createJSON-based interfaces for the modeling languages.This opportunity is only possible for the interfacesof the Parsing capability.Our planning architecture and prototype arebased on messaging, which involves forwarding ofobjects and requires their classes to be serialisable.This means that the capabilities of existing plan-ning artefacts need to be decomposable into sepa-rate serialisable classes. Existing planning capabil-ities are tightly coupled software systems, makingit extremely difficult, almost impossible, to extracttheir capabilities as separate classes. This is mainlydue to fact that the AI planning community has ne-glected software-engineering principles and focusedexclusively on the behaviour of the planning toolsand algorithms. So, the lack of serialisable classessignificantly complicates the integration task. It istherefore necessary to integrate every existing plan-ning implementation into a service using a wrapperwith a serialisable data structure. We tried to dothis for PDDL4J, JSHOP2 [67], KPlanning [68] andPANDA, especially to extract the data structure forthe Parsing capability. This proved also problem-atic, Many planners use grounding directly linkedto the parsing process. In some cases, we even gotin touch with the system developers to clarify theproblem of data interpretation during parsing. Inthe end, we successfully integrated only the func-tionality of the PDDL4J library.The Modelling service is implemented as a singlefront-end service. This makes the service complexand tightly coupled. A better approach would beto separate the front-end functionality into morediscrete capabilities and decouple it from the func-tionality used to provide results, login and admin-istration features. Grounding consists of listing and instantiating all possi-ble actions from the planning problem specification [46].
The high scores of usability, interoperability andreusability can be justified by the fact that the plan-ning architecture is the first planning artefact thatincorporates software-engineering principles, designpatterns and practices. There are also scores lowerthan the maximum possible. For usability, SOAmay cause some disadvantages, especially in plan-ning requests. At the same time, SOA offers manypossibilities to improve usability by allowing imple-mentation of multiple capabilities. For interoper-ability, our approach does not enforce equal seman-tic treatment of interacting capabilities. The highinteroperability increases the need to have stable orstandard interfaces. A correct connection to errormanagement is necessary to be able to create mean-ingful error messages. For reusability, the currentlyused JavaDocs might not be sufficient as documen-tation for such a platform planning architecture.Detailed documentation of each planning capabilityand corresponding interfaces might be necessary..In addition to usability, interoperability andreusability, our approach has the advantage of flex-ibility. The planning architecture can be easily ex-tended with other planning capabilities and also itcan support any data model provided its serialis-ability. So, the proposed approach can be seen asan ecosystem of existing planning capabilities andincubator of new planning services, having the po-tential to avoid many development and integrationproblems and to save time and effort. These advan-tages would become even more apparent when thesystem gets connected to a real-world application.
9. Conclusions
We put a software architecture at the core of theability to build, sustain and foster the use of AIplanning systems. We collected a set of planningcapabilities that we classified from an operationaland technical perspective. These two classificationsprovide initial support for designers and engineersof AI planning systems by allowing them to quicklyunderstand the objectives, features and propertiesof the numerous planning capabilities. Upon thesecapabilities, we designed a service-oriented plan-ning architecture that meets the requirements of us-ability, interoperability and reusability. The archi-tecture design incorporates appropriate software-engineering principles and design patterns.The developed system prototype is used todemonstrate the potential for rapid prototyping by19everaging the flexibility of the planning architec-ture, but also the possibility to integrate existingplanning tools when their complex internals allowfor it. We showed that our proposed approach hasqualitative attributes that go beyond those of typ-ical AI planning artefacts. While our planning ar-chitecture represents an initial effort and the proto-type offers only limited capabilities, we believe theymake a significant step towards bringing closer soft-ware architecture and AI planning.
References [1] S. Thi´ebaux, M.-O. Cordier, Supply Restoration inPower Distribution Systems - A Benchmark for Plan-ning under Uncertainty, in: European Conference onPlanning, 2001, pp. 196–202.[2] E. Kaldeli, A. Lazovik, M. Aiello, Continual Planningwith Sensing for Web Service Composition, in: AAAIConference on Artificial Intelligence, 2011, pp. 1198–1203.[3] J. Orkin, Applying goal-oriented action planning togames, AI game programming wisdom 2 (2003) 217–228.[4] N. Muscettola, P. P. Nayak, B. Pell, B. C. Williams,Remote Agent: To Boldly Go Where No AI SystemHas Gone Before, Artif. Intell. 103 (1998) 5–47.[5] I. Georgievski, M. Aiello, Automated Planning forUbiquitous Computing, ACM Computuing Surveys49 (4) (2016) 63:1–63:46.[6] J. Hoffmann, B. Nebel, The FF Planning System: FastPlan Generation Through Heuristic Search, Journal ofArtificial Intelligence Research 14 (27) (2001) 253–302.[7] M. Helmert, The Fast Downward Planning System,Journal of Artificial Intelligence Research 26 (2011)191–246.[8] Artificial Intelligence & Machine Learning Group,Universitat Pompeu Fabra, Universal PDDL parser(2016).URL https://github.com/aig-upf/universal-pddl-parser [9] T. S. Vaquero, J. R. Silva, F. Tonidandel, J. Christo-pher Beck, itSIMPLE: Towards an Integrated DesignSystem for Real Planning Applications, The KnowledgeEngineering Review 28 (2) (2013) 215–230.[10] R. Howey, D. Long, M. Fox, VAL: Automatic Plan Val-idation, Continuous Effects and Mixed Initiative Plan-ning Using PDDL, in: IEEE International Conferenceon Tools with Artificial Intelligence, 2004, pp. 294–301.[11] M. P. Papazoglou, D. Georgakopoulos, Introduction:Service-oriented computing, Commun. ACM 46 (10)(2003) 24–28.[12] N. J. Nilsson, Shakey the robot, Technical note, SRIInternational’s Artificial Intelligence Center (1984).[13] M. Ghallab, D. S. Nau, P. Traverso, Automated Plan-ning: Theory & Practice, Morgan Kaufmann PublishersInc., 2004.[14] E. Kaldeli, A. Lazovik, M. Aiello, Domain-IndependentPlanning for Services in Uncertain and Dynamic Envi-ronments, Artificial Intelligence 236 (C) (2016) 30–64.[15] P. Bertoli, A. Cimatti, M. Roveri, P. Traverso, Plan-ning in Nondeterministic Domains Under Partial Ob- servability via Symbolic Model Checking, in: Interna-tional Joint Conference on Artificial Intelligence, 2001,pp. 473–478.[16] E. Kaldeli, A. Lazovik, M. Aiello, Extended Goals forComposing Services, in: International Conference onAutomated Planning and Scheduling, 2009, pp. 362–365.[17] Mausam, D. S. Weld, Planning with Durative Actionsin Stochastic Domains, Journal of Artificial IntelligenceResearch 31 (1) (2008) 33–82.[18] I. Georgievski, M. Aiello, HTN Planning: Overview,Comparison, and Beyond, Artificial Intelligence 222 (0)(2015) 124–156.[19] P. Eyerich, R. Mattm¨uller, G. R¨oger, Using theContext-enhanced Additive Heuristic for Temporal andNumeric Planning, in: International Conference on Au-tomated Planning and Scheduling, 2009, pp. 130–137.[20] N. Lipovetzky, H. Geffner, Searching for Plans withCarefully Designed Probes, in: International Confer-ence on Automated Planning and Scheduling, 2011, pp.154–161.[21] D. Nau, Y. Cao, A. Lotem, H. Munoz-Avila, Shop: Sim-ple hierarchical ordered planner, in: International JointConference on Artificial Intelligence - Volume 2, 1999,pp. 968–973.[22] D. S. Nau, T. C. Au, O. Ilghami, U. Kuter, J. W. Mur-dock, D. Wu, F. Yaman, SHOP2: An HTN PlanningSystem, Journal of Artificial Intelligence Research 20(2003) 379–404.[23] S. Sohrabi, J. A. Baier, S. A. McIlraith, HTN PlanningWith Preferences, in: International Joint Conference onArtificial Intelligence, 2009, pp. 1790–1797.[24] J. Fern´adez-Olivares, L. Castillo, O. Garc´ıa-P´erez,F. Palao, Bringing users and planning technology to-gether. Experiences in SIADEX, in: International Con-ference on Automated Planning and Scheduling, 2006,pp. 11–20.[25] I. Georgievski, T. A. Nguyen, F. Nizamic, B. Setz,A. Lazovik, M. Aiello, Planning Meets Activity Recog-nition: Service Coordination for Intelligent Buildings,Pervasive and Mobile Computing 38 (1) (2017) 110–139.[26] D. H¨oller, G. Behnke, P. Bercher, S. Biundo, The pandaframework for hierarchical planning, KI-K¨unstliche In-telligenz (2021) 1–6.[27] D. McDermott, M. Ghallab, A. Howe, C. Knoblock,A. Ram, M. Veloso, D. Weld, D. Wilkins, PDDL - Theplanning domain definition language, Technical ReportCVC TR-98-003/DCS TR-1165, Yale Center for Com-putational Vision and Control (1998).[28] M. Fox, D. Long, PDDL2.1: An Extension to PDDLfor Expressing Temporal Planning Domains, Journal ofArtificial Intelligence Research 20 (1) (2003) 61–124.[29] A. Gerevini, D. Long, Plan Constraints and Preferencesin PDDL3, Technical Report 2005-08-07, Department ofElectronics for Automation, Yale University (2005).[30] H. L. Younes, M. L. Littman, PPDDL1.0: The Lan-guage for the Probabilistic Part of IPC-4, in: Interna-tional Planning Competition, 2004.[31] M. Fox, D. Long, Modelling Mixed Discrete-ContinuousDomains for Planning, Journal of Artificial IntelligenceResearch 27 (1) (2006) 235—-297.[32] I. Georgievski, HPDL: Hierarchical Planning DefinitionLanguage, Technical Report 2013-12-3, University ofGroningen (2013).
33] D. H¨oller, G. Behnke, P. Bercher, S. Biundo, H. Fiorino,D. Pellier, R. Alford, HDDL: An Extension to PDDL forExpressing Hierarchical Planning Problems, in: AAAIConference on Artificial Intelligence, 2020, pp. 9883–9891.[34] D. Kaye, Loosely Coupled: The Missing Pieces of WebServices, RDS Press, 2003.[35] C. Fehling, F. Leymann, R. Retter, W. Schupeck, P. Ar-bitter, Cloud Computing Patterns, Springer, 2014.[36] G. Hohpe, B. Woolf, Enterprise Integration Patterns:Designing, Building, and Deploying Messaging Solu-tions, Addison-Wesley Professional, 2004.[37] E. Curry, Message-oriented middleware, Middleware forcommunications (2004) 1–28.[38] K. L. Myers, CPEF: A Continuous Planning and Exe-cution Framework, AI Mag. 20 (4) (1999) 63.[39] C. Guzm´an Alvarez, V. Alc´azar, D. Prior, E. Onaindia,D. Borrajo, J. Fdez-Olivares, E. Quintero, PELEA: aDomain-Independent Architecture for Planning, Execu-tion and Learning, in: ICAPS Workshop on Schedulingand Planning Applications woRKshop (SPARK), 2012,pp. 38–45.[40] S. Fratini, N. Policella, A. Donati, A Service Orientedapproach for the Interoperability of Space Mission Plan-ning Systems, Workshop on Knowledge Engineering forPlanning and Scheduling.[41] I. Georgievski, Coordinating services embedded every-where via hierarchical planning, Ph.D. thesis, Univer-sity of Groningen (2015).[42] I. Georgievski, F. Nizamic, A. Lazovik, M. Aiello,Cloud ready applications composed via htn planning,in: IEEE International Conference on Service OrientedComputing and Applications, 2017, pp. 23–33.[43] C. Muise, Planning.Domains, International Conferenceon Automated Planning and Scheduling - Demonstra-tions (2016) 1–3.[44] A. V. Feljan, S. K. Mohalik, M. B. Jayaraman,R. Badrinath, SOA-PE: A Service-Oriented Architec-ture for Planning and Execution in Cyber-Physical Sys-tems, in: International Conference on Smart Sensorsand Systems, 2017, pp. 1–6.[45] F. Dvor´ak, R. Bart´ak, A. Bit-Monnot, F. Ingrand,M. Ghallab, Planning and Acting with Temporal andHierarchical Decomposition Models, in: IEEE Interna-tional Conference on Tools with Artificial Intelligence,2014, pp. 115–121.[46] A. Ramoul, D. Pellier, H. Fiorino, S. Pesty, Ground-ing of HTN Planning Domain, International Journal onArtificial Intelligence Tools 26 (05).[47] J. Rintanen, J. Hoffmann, An Overview of Recent Al-gorithms for AI Planning, K¨unstliche Intelligenz 15 (2)(2001) 5–11.[48] A. Tate, B. Drabble, R. Kirby, O-Plan2: An Open Ar-chitecture for Command, Planning and Control, in: In-telligent Scheduling, 1994, pp. 213–239.[49] P. Bercher, S. Keen, S. Biundo, Hybrid PlanningHeuristics Based on Task Decomposition Graphs, in:Annual Symposium on Combinatorial Search, 2014, pp.35–43.[50] M. Cashmore, M. Fox, D. Long, D. Magazzeni, B. Rid-der, A. Carrera, N. Palomeras, N. Hurt´os, M. Carreras,Rosplan: Planning in the Robot Operating System, in:International Conference on Automated Planning andScheduling, 2015, pp. 333–341.[51] D. S. Nau, Y. Cao, A. Lotem, H. Mu˜noz Avila, SHOP: Simple Hierarchical Ordered Planner, in: InternationalJoint Conference on Artificial Intelligence - Vol. 2, 1999,pp. 968–973.[52] R. P. Goldman, U. Kuter, Hierarchical Task NetworkPlanning in Common Lisp: the Case of SHOP3, in:European Lisp Symposium, 2019, pp. 73–80.[53] D. E. Wilkins, Using the SIPE-2 planning system - Amanual for SIPE-2 (2000).[54] K. Erol, J. A. Hendler, D. S. Nau, UMCP: A Soundand Complete Procedure for Hierarchical Task-networkPlanning, in: International Conference on AI PlanningSystems, 1994, pp. 249–254.[55] D. Leonard-Barton, Wellspring of Knowledge, HarvardBusiness School Press, Boston, MA.[56] C. K. Prahalad, G. Hamel, The Core Competence of theCorporation, Harvard Business Review 68 (3) (1990)295–336.[57] C. Alexander, The Timeless Way of Building, NewYork: Oxford University Press, 1979.[58] ISO 9241-11:2018, Ergonomics of Human-System Inter-action — Part 11: Usability: Definitions and Concepts,Standard, International Organization for Standardiza-tion (2018).[59] J. Delgado, Service Interoperability in the Internet ofThings, in: N. Bessis, F. Xhafa, D. Varvarigou, R. Hill,M. Li (Eds.), Internet of Things and Inter-cooperativeComputational Technologies for Collective Intelligence,Springer, 2013, pp. 51–87.[60] G. Cardino, F. Baruchelli, A. Valerio, The Evaluation ofFramework Reusability, ACM SIGAPP Applied Com-puting Review 5 (2) (1997) 21–27.[61] M. N. Huhns, M. P. Singh, Service-Oriented Comput-ing: Key Concepts and Principles, IEEE Internet Com-puting 9 (1) (2005) 75–81.[62] U. Breitenb¨ucher, F. Leymann, Cloud Computing(2019).[63] E. Lavieri, Hands-On Design Patterns with Java, Birm-ingham: Packt Publishing, 2019.[64] D. Pellier, H. Fiorino, PDDL4J: A Planning DomainDescription Library for Java, Journal of Experimentaland Theoretical Artificial Intelligence 30 (1) (2018) 143–176.[65] M. C. Magnaguagno, R. F. Pereira, M. D. M´ore,F. Meneguzzi, WEB PLANNER: A Tool to DevelopClassical Planning Domains and Visualize HeuristicState-Space Search, in: Workshop on User Interfacesand Scheduling and Planning, 2017, pp. 32–38.[66] A. Abran, R. Al-Qutaish, ISO 9126: Analysis of QualityModels and Measures, Wiley-IEEE Press, 2010, Ch. 10,pp. 205–228.[67] O. Ilghami, Documentation for jshop2, 2006.[68] G. Krzisch, Kplanning.URL https://github.com/guilhermekrz/KPlanninghttps://github.com/guilhermekrz/KPlanning