A planning approach to the automated synthesis of template-based process models

Abstract

The design-time specification of flexible processes can be time-consuming and error-prone, due to the high number of tasks involved and their context-dependent nature. Such processes frequently suffer from potential interference among their constituents, since resources are usually shared by the process participants and it is difficult to foresee all the potential tasks interactions in advance. Concurrent tasks may not be independent from each other (e.g., they could operate on the same data at the same time), resulting in incorrect outcomes. To tackle these issues, we propose an approach for the automated synthesis of a library of template-based process models that achieve goals in dynamic and partially specified environments. The approach is based on a declarative problem definition and partial-order planning algorithms for template generation. The resulting templates guarantee sound concurrency in the execution of their activities and are reusable in a variety of partially specified contextual environments. As running example, a disaster response scenario is given. The approach is backed by a formal model and has been tested in experiments.

Appendix A: Translation algorithms

This appendix is focused primarily on presenting technical details concerning the translation algorithms introduced in Sect. 5.1. Specifically, in the following, we describe:

• The module PC2PR used for translating a domain theory D and a process case C into a planning domain PD and a planning problem PR;

• The module POP2PT used for converting a partially ordered plan P into a process template PT.

1.1 Appendix A.1: Representing domain theories and process cases in PDDL

To obtain a process template that handles a case $\textsf {C}$, a corresponding PDDL planning problem definition PR has to be specified. This can be done by mapping $init_\textsf {C}$ to $init_{\textsf {PR}}$ and $goal_\textsf {C}$ to $goal_{\textsf {PR}}$. The planning domain PD is built starting from the definition of ground atomic terms and data types as shown in Sect. 4, and by making explicit the actions associated with each annotated task $t \in \textsf {T}$, together with their preconditions, effects and input parameters. Basically, the planning domain describes how predicates and functions change after an action’s execution, and specifies the contextual properties constraining the execution of tasks stored in the tasks repository.

Our framework provides a software module named PC2PR in charge of performing such a translation, which makes use of PDDL version 2.1 (cf. [33]). In the following, we discuss how the domain theory $\textsf {D}$ can be translated into a PDDL file representing the planning domain PD:

• The name and the domain of a data type correspond to an object type in the planning domain;

• Boolean terms have a straightforward representation as relational predicates (templates for logical facts) in the planning domain;

• Integer terms correspond to PDDL numeric fluents and are used for modeling non-boolean resources (e.g., the battery charge level of a robot) in the planning domain;

• Functional terms do not have a direct representation in PDDL 2.1, but may be represented as relational predicates. Since a functional term is a function $f:Object^n \rightarrow Object$ that maps tuples of objects with domain types $D^n$ to objects with co-domain type U, it may be encoded in the planning domain as a relational predicate P of type $(D^n,U)$.

For example, let us consider the running example presented in Sect. 2 and its formalization with the domain theory $\textsf {D}$ as shown in Sect. 4. The module PC2PR converts $\textsf {D}$ into a PDDL planning domain $\textsf {PD}$ defined as follows:

The :types field is used to declare the relevant types of objects interacting in our contextual scenario. Specifically, three new types have been declared: participant, location and capability. The :predicates field consists of a list of declarations of relational predicates, reflecting the properties of the contextual scenario. Notice that in PDDL, variables are distinguished by an initial “?” character, for example ?prt and ?loc are two variables. The dash “−” is used to assign types to the variables. In the example above, ?prt is defined to be of type participant and ?loc is defined to be of type location. For example, the predicate at holds true if a participant ?prt is situated in location ?loc. The predicate provides is used for declaring if a capability ?cap is provided by the participant ?prt.

A given task, together with the associated preconditions, effects and input parameters, is translated into a PDDL action schema. An action schema describes how the relational predicates and/or numeric fluents change after the action’s execution. For example, given the following XML specification of the task $Go \in \textsf {T}$ (with respect to the language provided in Sect. 4):

The module PC2PR produces the following PDDL representation:

This task can be executed only if the actor denoted by ?prt is not currently located in the target location ?to (and is located in her/his starting location ?from) and is capable of moving into the area. The desired effect turns the value of the predicate (at ?prt ?to) to true and of (at ?prt ?loc) to false, where ?loc is any location different from the destination.

The planning problem PR can be seen as an instance of the planning domain $\textsf {PD}$. It first declares the constant symbols in the initial state of the planning problem, then defines the initial state $init_\textsf {PR}$ and finally specifies a goal condition $goal_\textsf {PR}$ for the planning problem. Specifically, the module PC2PR converts the case $\textsf {C}$ into a PDDL file representing the planning problem PR as follows:

• For each data type defined in the planning domain, all the possible object instances of that particular data type are explicitly instantiated as constant symbols in the initial state of the planning problem (e.g., the fact that act1, act2, act3, act4, rb1 and rb2 are Participants, and that loc00, ..., loc33 are Locations);

• A representation of the initial state of the planning problem is generated; basically, the initial state of the planning problem $init_{\textsf {PR}}$ is composed of a conjunction of relational predicates (representing functional and boolean terms in $init_{\textsf {C}}$) and the initial value of each numeric fluent (e.g., the value of the battery charge level for each robot), corresponding to the values of integer terms in $init_{\textsf {C}}$;

• The goal condition of the planning problem is a logical expression over facts, which partially specifies the state to be reached after the execution of the process template; it is a condition represented as a conjunction of relational predicates and numeric fluent atoms representing the specific boolean, functional and integer terms we want to make true through the correct execution of the process template (as defined in $goal_\textsf {C}$).

Notice that the description of the planning problem $\textsf {PR}$ derived from the case $\textsf {C}$ of our running example roughly corresponds to the contextual information available on the dynamic environment described in Fig. 1b:

1.2 Appendix A.2: Translating a partially ordered plan P into a process template PT

Once the plan $\textsf {P}$ has been synthesized, it needs to be translated in a process template PT. As explained in Sect. 3.2, a solution plan is a three-tuple $\textsf {P} = (A,O,CL)$, where A is the set of actions appearing in the plan, O and CL are, respectively, the set of ordering constraints and of causal links over A. Since the set of actions A composing the plan and the set of ordering constraints O over A must be explicitly expressed as nodes and transitions of the template’s control flow (as well as their intrinsic ordering), we have implemented a module named POP2PT that takes as input a solution plan $\textsf {P}$ and converts it into a process template $\textsf {PT}$.

We provide two algorithms—named, respectively, “${Find}_{\texttt {PREC/NEXT}}$” (cf. Algorithm 1) and “${Build}_\textsf {PT}$” (cf. Algorithm 2)—to be executed sequentially for automatically computing a process template $\textsf {PT}$. For each planning action $a_i \in A$, Algorithm 1 is in charge of detecting which actions “directly” precede and follow $a_i$ in the plan. This information will be crucial for instantiating the transitions between the flow objects of the process template. However, this knowledge is not directly available in O. In fact, an ordering constraint $a \prec b$ between two actions $a \in A$ and $b \in A$ indicates that a must be executed sometime before action b, but not necessarily immediately before. Algorithm 1, for each action $a_i \in A$, builds two sets containing the actions that immediately precede $a_i$ (the set $PREC(a_i)$) and immediately follow $a_i$ (the set $NEXT(a_i)$).

Definition 10

Given an ordering constraint $(a \prec b) \in O$ between two actions $a \in A$ and $b \in A$, we say that a directly precedes b and b directly follows a iff no further action $c \in A$ exists such that $a \prec c$ and $c \prec b$.

Basically, for each ordering constraint $o_k = (a_i \prec a_j) \in O$,⁴ the algorithm $Find_{PREC/NEXT}$ works as follows:

• If there does not exist any planning action $a_h \ne a_j$ that precedes $a_i$—i.e., such that $(a_h \prec a_i) \in O$—then the only predecessor of $a_i$ is the dummy start action $a_0$. Therefore, $a_0$ is added to the set of predecessors of $a_i$ (i.e., $PREC(a_i) = PREC(a_i) \cup \{a_0\}$) and $a_i$ is added to the set of successors of $a_0$ (i.e., $NEXT(a_0) = NEXT(a_0) \cup \{a_i\}$).

• If there does not exist any planning action $a_h \ne a_i$ that follows $a_j$—i.e., such that $(a_j \prec {a_h}) \in O$—then the only successor of $a_j$ is the dummy end action $a_\infty$. Therefore, $a_j$ is added to the set of predecessors of $a_\infty$ (i.e., $PREC(a_\infty ) = PREC(a_\infty ) \cup \{a_j\}$) and $a_\infty$ is added to the set of successors of $a_j$ (i.e., $NEXT(a_j) = NEXT(a_j) \cup \{a_\infty \}$).

• If there does not exist any planning action $a_h \ne a_i$ that precedes $a_j$—i.e., such that $(a_h \prec a_j) \in O$—then $a_i$ directly precedes $a_j$ (and $a_j$ directly follows $a_i$), meaning that $PREC(a_j) = PREC(a_j) \cup \{a_i\}$ and $NEXT(a_i) = NEXT(a_i) \cup \{a_j\}$.

• If there exists a planning action $a_h \ne a_i$ that precedes $a_j$—i.e., such that $(a_h \prec a_j) \in O$—but there does not exist any finite sequence of actions $a_1, a_2, \ldots , a_n$ such that $(a_i \prec \ldots \prec a_1 \prec a_2 \prec \ldots \prec a_n \prec \ldots \prec a_h)$, then $a_i$ directly precedes $a_j$ (and $a_j$ directly follows $a_i$), meaning that $PREC(a_j) = PREC(a_j) \cup \{a_i\}$ and $NEXT(a_i) = NEXT(a_i) \cup \{a_j\}$.

Fig. 9

Overview of the working of the algorithm $\texttt {Find}_{\texttt {PREC/NEXT}}$

Starting from the two sets just computed, the algorithm $\texttt {Build}_\textsf {PT}$ is in charge of building the process template $\textsf {PT}$, by instantiating the tasks, gateways, events and transitions between them. For every action $a \in A$, a corresponding task instance $t_a \in T$ (basically, a task instance is an occurrence of a specific task $t \in \textsf {T}$) is generated (cf. the function taskify in Algorithm 2). Transitions between tasks depend on the number of predecessors/successors contained in PREC(a)/NEXT(a). In particular, if an action $b \in A$ is such that $b \in PREC(a)$ or $b \in NEXT(a)$, it is clear that there must be some kind of transition between $t_a$ and $t_b$ in $\textsf {PT}$:

• If b is the only successor of a, and a is the only predecessor of b (cf. Fig. 9a), then $(t_a \rightarrow t_b) \in L_T$ (cf. Fig. 9b);

• If a is the only predecessor of b, but b is not the only successor of a (cf. Fig. 9c), then a parallel split $w_\mathrm{PS} \in W_\mathrm{PS}$ is needed between $t_a$ and $t_b$. Hence $(t_a \rightarrow w_\mathrm{PS}) \in L_T$ and $(w_\mathrm{PS} \rightarrow t_b) \in L_{W_\mathrm{PS}}$ (cf. Fig. 9d);

• If b is the only successor of a, but a is not the only predecessor of b (cf. Fig. 9e), then a parallel join $w_\mathrm{PJ} \in W_\mathrm{PJ}$ is needed between $t_a$ and $t_b$. Hence $(t_a \rightarrow w_\mathrm{PJ}) \in L_T$ and $(w_\mathrm{PJ} \rightarrow t_b) \in L_{W_\mathrm{PJ}}$ (cf. Fig. 9f);

• If $t_a$ is not the only predecessor of $t_b$ and $t_b$ is not the only successor of $t_a$ (cf. Fig. 9g), then a parallel split $w_\mathrm{PS} \in W_\mathrm{PS}$ and a parallel join $w_\mathrm{PJ} \in W_\mathrm{PJ}$ are needed between $t_a$ and $t_b$. Hence $(t_a \rightarrow w_\mathrm{PS}) \in L_T$, $(w_\mathrm{PS} \rightarrow w_\mathrm{PJ}) \in L_{W_\mathrm{PS}}$ and $(w_\mathrm{PJ} \rightarrow t_b) \in L_{W_\mathrm{PJ}}$ (cf. Fig. 9h).

Finally, if an action $a \in A$ has no predecessors/successors (i.e., the set PREC(a)/NEXT(a) is empty), this means that $t_a$ must be connected with the start event /end event $\odot$.

A stand-alone software implementation of the module POP2PT is available for testing at: https://goo.gl/z8uJ8S.