supporting adaptiveness of cyber-physical processes through … · 2019-03-19 · processes through...

1

Supporting adaptiveness of cyber-physicalprocesses through action-based formalisms

Andrea Marrella a* Massimo Mecella a

Sebastian Sardina b

a Sapienza Universita di Roma, Italyb RMIT University, Melbourne, Australia

Cyber Physical Processes (CPPs) refer to a new generationof business processes enacted in many application environ-ments (e.g., emergency management, smart manufacturing,etc.), in which the presence of Internet-of-Things devices andembedded ICT systems (e.g., smartphones, sensors, actua-tors) strongly influences the coordination of the real-worldentities (e.g., humans, robots, etc.) inhabitating such envi-ronments. A Process Management System (PMS) employedfor executing CPPs is required to automatically adapt its run-ning processes to anomalous situations and exogenous eventsby minimising any human intervention. In this paper, wetackle this issue by introducing an approach and an adap-tive Cognitive PMS, called SmartPM, which combines pro-cess execution monitoring, unanticipated exception detectionand automated resolution strategies leveraging on three well-established action-based formalisms developed for reasoningabout actions in Artificial Intelligence (AI), including the sit-uation calculus, IndiGolog and automated planning. Interest-ingly, the use of SmartPM does not require any expertise ofthe internal working of the AI tools involved in the system.

Keywords: Cyber-Physical Processes, Process Adaptationand Recovery, Situation Calculus, IndiGolog, AutomatedPlanning

1. Introduction

In the last years, we have witnessed the emer-gence of new computing paradigms, such as Health 2.0[69,13], Industry 4.0 [38] and mobile-based emergencymanagement (e.g., see [17] and the ISCRAM confer-ence on Information Systems for Crisis Response andManagement, http://www.iscram.org/), in whichthe interplay of Internet-of-Things (IoT) devices, i.e.,devices attached to the Internet, Artificial Intelligence(AI) based techniques, cloud computing, Software-as-

*Corresponding author: [email protected]

a-Service (SaaS), and Business Process Management(BPM) create the so-called cyber-physical environ-ments and give rise to the concept of Cyber-PhysicalSystems (CPSs). The role of CPSs is to monitor thephysical processes enacted in cyber-physical environ-ments, create a virtual copy of the physical world andmake decentralized decisions, by introducing methodsof self-optimization, self-configuration, self-diagnosis,and intelligent support of workers in their increasinglycomplex work [64].

A relevant aspect in these environments lies in thefundamental role played by the processes orchestrat-ing the different actors (software, humans, robots,etc.) involved in the CPS. We refer to these pro-cesses as cyber-physical processes (CPPs), whose en-actment is influenced by user decision making and cou-pled with contextual data and knowledge productioncoming from the cyber-physical environment. Accord-ing to [33], Cognitive Process Management Systems(CPMSs) are the key technology for supporting CPPs.

A conventional Process Management System (PMS)is a software system that manages and executes pro-cesses on the basis of process models [20]. The basicconstituents of a process model are tasks, describingthe various activities to be performed by process par-ticipants. The procedural rules to control such tasks,described by so-called “routing” constructs such as se-quences, loops, parallel, and alternative branches, de-fine the control flow of the process. A PMS, then, takesa process model (containing the process’ tasks andcontrol flow) and manages the process routing by de-ciding which tasks are enabled for execution. Once atask is ready for execution, the PMS assigns it to thoseparticipants capable of carrying it on. The representa-tion of a single execution of a process model is calleda process instance [19].

A PMS is said to be cognitive when it involves addi-tional processing constructs that are at a semantic levelhigher than those of conventional PMSs. These con-structs are called cognitive BPM constructs and tendto include data-driven activities and constraints, goals,and plans [33]. Their usage can open opportunities for

AI CommunicationsISSN 0921-7126, IOS Press. All rights reserved

2 Supporting Adaptiveness of CPPs through Action-based Formalisms

new levels of automation and support for CPPs, suchas - for example - the automated synthesis of adapta-tion strategies at run-time exploiting solely the processknowledge and its expected evolution.

During the enactment of CPPs, variations or di-vergence from structured reference models are com-mon due to exceptional circumstances arising (e.g., au-tonomous user decisions, exogenous events, or con-textual changes), thus requiring the ability to properlyadapt the process behavior. Process adaptation can beseen as the ability of a process to react to exceptionalcircumstances (that may or may not be foreseen) andto adapt/modify its structure accordingly. Exceptionscan be either anticipated or unanticipated. An antici-pated exception can be planned at design-time and in-corporated into the process model, i.e., a (human) pro-cess designer can provide an exception handler thatis invoked during run-time to cope with the excep-tion. Conversely, unanticipated exceptions refer to sit-uations, unplanned at design-time, that may emergeat run-time and can be detected only during the ex-ecution of a process instance, when a mismatch be-tween the computerized version of the process andthe corresponding real-world process occurs. To copewith those exceptions, a PMS is required to allow ad-hoc process changes for adapting running process in-stances in a situation- and context-dependent way.

The fact is that, in cyber-physical environments, thenumber of possible anticipated exceptions is often toolarge, and traditional manual implementation of excep-tion handlers at design-time is not feasible for the pro-cess designer, who has to anticipate all potential prob-lems and ways to overcome them in advance [58]. Fur-thermore, anticipated exceptions cover only partiallyrelevant situations, as in such scenarios many unantic-ipated exceptional circumstances may arise during theprocess instance execution. Therefore, the process de-signer often lacks the needed knowledge to model allthe possible exceptions at the outset, or this knowledgecan become obsolete as process instances are executedand evolve, by making useless her/his initial effort.

To tackle this issue, in this paper we present and re-view our ongoing work on SmartPM1, a CPMS ableto automatically adapt CPPs at run-time when unan-

1The technical content regarding SmartPM follows and im-proves our previous work [42] by introducing the multi-instance con-struct (cf. Section 5), whereas the real-world application scenario ofSection 2.1, the conceptual architecture of Section 2.2, the cyber-physical layer implemented in the SmartPM system to cope withCPPs of Section 3 and the usability evaluation of Section 6 are spe-cific to this contribution.

ticipated exceptions occur, thus requiring no specifica-tion of recovery policies at design-time. The generalidea builds on the dualism between an expected realityand a physical reality: process execution steps and ex-ogenous events have an impact on the physical realityand any deviation from the expected reality results in amismatch to be removed to allow process progression.

To that end, we resort to three popular action-basedformalisms and technologies from the field of Knowl-edge Representation and Reasoning (KR&R): situa-tion calculus [60], IndiGolog [14], and automated plan-ning [49,28]. We use the situation calculus logical for-malism to model the underlying domain in which pro-cesses are to be executed, including the description ofavailable tasks, contextual properties, tasks’ precondi-tions and effects, and the initial state. On top of suchmodel, we use the IndiGolog high-level agent program-ming language for the specification of the structure andcontrol flow of processes. Importantly, we customizeIndiGolog to monitor the online execution of processesand detect potential mismatches between the modeland the actual execution. If an exception invalidates theenactment of the processes being executed, an externalstate-of-the-art planner is invoked to synthesise a re-covery procedure to adapt the faulty process instance.

The choice of adopting action-based formalismsfrom the KR&R field is motivated by their ability toprovide the right cognitive level needed when dealingwith dynamic situations in which data (values) play arelevant role in system enactment and automated rea-soning over the system progress. In the field of BPM,many other formalisms (in particular Petri Nets-basedand process algebras) have been successfully adoptedfor process management, but all of them are some-how based on synthesis techniques of the control-flow,when considering their automated reasoning capabili-ties. This implies the level of abstraction over dealingwith data and dynamic situations is fairly “raw”, whencompared with KR&R methods in which automatedreasoning over data values and situations is much moredeveloped [59,5,60]. As we will see below, the choiceof KR&R technologies allows us to develop a princi-pled, clean and simple-to-manage framework for pro-cess adaptation based on relevant data manipulated bythe process, without compromising efficiency and ef-fectiveness of the proposed solution.

The rest of the paper is organized as follow. In Sec-tion 2, after presenting an overview of our applicationscenario, i.e., a real CPP enacted in an Italian ceramic-ware factory, we provide a conceptual architecture forimplementing adaptive CPMSs for CPPs. In Section 3

Supporting Adaptiveness of CPPs through Action-based Formalisms 3

Fig. 1. Overview of the production process of a ceramic sanitary ware factory.

we introduce the general SmartPM approach to han-dle unanticipated exceptions in CPPs, and we presentthe architecture of the implemented SmartPM system.Then, in Sections 4 and 5, we provide the formaliza-tion of the SmartPM approach through action-basedformalisms. In Section 6, we investigate the practi-cal applicability of SmartPM from the user perspectivethrough a set of experiments performed with real users.Finally, in Section 7, we discuss the state-of-the-art ap-proaches to process adaptation, while in Section 8 weconclude the article by drawing conclusions and dis-cussing limitations and future work.

2. Cyber-Physical Processes

CPSs are having widespread applicability andproven impact in multiple areas [53], like aerospace,automotive, traffic management, healthcare, manufac-turing, emergency management, entertainments. Ac-cording to [39], any physical environment which con-tains computing-enabled devices can be considered asa cyber-physical environment.

The trend of managing CPPs, i.e., processes enactedin cyber-physical environments, has been fueled bytwo main factors. On the one hand, the recent develop-ment of powerful mobile computing devices providingwireless communication capabilities have become use-ful to support mobile workers to execute tasks in suchdynamic settings. On the other hand, the increasedavailability of sensors disseminated in the world haslead to the possibility to monitor in detail the evolutionof several real-world objects of interest. The knowledgeextracted from such objects allows to depict the con-tingencies and the context in which processes are car-ried out, by providing a fine-grained monitoring, min-ing, and decision support for them.

In this section, we first present a real-world appli-cation scenario that comes from the smart manufactur-ing domain to motivate the need of designing an adap-tive CPMS in cyber-physical environments (cf. Sec-tion 2.1). Then, we devise a conceptual architecture toconcretely build such a CPMS (cf. Section 2.2).

2.1. Application Scenario

Smart manufacturing is rapidly transforming howproducts are invented and manufactured. A modernmanufacturing plant uses sensors, actuators and com-puterized controls to manage each specific stage ofa manufacturing process. The challenge is to inte-grate individual stages of manufacturing productionenabling data sharing throughout the plant, with thepurpose to allow complete production lines to runwith real-time flexibility in order to ensure trouble-freemanufacturing and optimize outputs [9].

In a modern ceramic factory, a new product (e.g.a sanitary item) is first designed with the help ofComputer-Aided Design (CAD) tools, and then passedto the production line. Fig. 1 shows a fragment of thereal production process of an Italian ceramic sanitary-ware factory. Each element of the factory is attachedto sensors and actuators, and a process-oriented sys-tem is used to coordinate the working of the robot armsand the machinery employed in the various steps of theproduction process.

Specifically, starting from a CAD model, an initialmould model of a ceramic product is generated througha rotomoulding step. A mould model has an higher vol-ume (of about 11%-12%) if compared to the final prod-uct’s volume, since in the subsequent steps of the pro-duction process, which are the drying, glazing and fir-ing steps, it will lose part of its volume and will be af-


fected by deformation influenced by different factors(gravity, humidity, glazing temperature, etc.).

The BPMN process in Fig. 2(a) describes (in a sim-plified way) the underlying workflow of such a produc-tion process. Notice that the process is a sequence ofmulti-instance tasks. The purpose of a multi-instancetask is to generate multiple independent instances ofthe task that run sequentially (if the task marker in-cludes three horizontal lines) or concurrently (if thetask marker includes three vertical lines). In our exam-ple, the number of generated instances for any task isdetermined by the number of ceramic elements that arenot broken at the moment of the task execution.

The initial collection of ceramic elements (for thesake of simplicity we are considering three elements,denoted as obj1, obj2 and obj3) is delivered through aspecific conveyor belt to the first step of the produc-tion process, that is rotomoulding, from a starting loca-tion (denoted as loc start). The same conveyor belt willalso move the ceramic elements between each step ofthe production line. After the firing step, each elementis moved in a final location (denoted as loc end).

Each of the steps of the production process is per-formed by a different static robotic arm or specializedmachinery located in a fixed position of the factory:

– the rotomoulding step is performed by the roboticarm rb arm 1 that is located in loc rotomoulding;

– the drying step is performed by the drying systemdryer 1 that is located in loc drying;

– the glazing step is performed by the robotic armrb arm 2 that is located in loc glazing;

– the firing step is performed by the oven systemoven 1 that is located in loc firing.

When the task associated to any of the steps com-pletes, a quality check is performed by activating a dig-ital 3D scanner that analyzes the surface of the ceramicelements to identify the presence of ruptures or defects.

Finally, a maintenance crew composed by twoskilled technicians, called actors, and a moving robotrb mv 1, initially all located in a warehouse con-taining ceramic elements with defects (situated inloc warehouse), is ready to intervene if somethingwrong happens during the enactment of the productionprocess. For example, actor act1 is able to fix the work-ing environment parameters of a machinery during themanipulation of a ceramic element if they may causedefects to the element itself, while act2 is in charge ofremoving debris of broken ceramic elements to keepthe conveyer belt clean. The moving robot rb mv 1, inturn, is designed to pick up ceramic elements with de-

fects from the conveyor belt and deposit them in thewarehouse. Notice that it is required that at least oneactor is always present in the warehouse for guarantee-ing a correct coordination of the operations of deposit.When the battery of a moving robot is discharged, ac-tor act2 can charge it.

During the enactment of the production process,there is a wide range of exceptions that can ensue.Some of these exceptions may be caused by the de-formation of ceramic materials during the drying andglazing steps [35], where an incorrect thermal expan-sion of the body of the ceramic elements may causetheir rupture. While nowadays the data collected by 3Dscanning during the CHECKQUALITY tasks are used forthe optimization of the design of the CAD model off-line, an intelligent adaptive CPMS could act on-line byrepairing the production process through one or morerecovery procedures that possibly mitigate the conse-quences of the deformation on the performances of thewhole production process.

For example, in Fig. 2(b), the outcome of theCHECKQUALITY task denotes that obj3 is broken.Therefore, if a deformation after the glazing step isevaluated as critic and not anymore “adjustable”, itis useless to proceed to the next step of the process,i.e., to fire the ceramic element. To that end, providedthat rb mv 1 has enough battery charge, the CPMSmay first instruct rb mv 1 to reach loc glazing in or-der to pick up obj3, and then to move back towardsloc warehouse to deposit obj3 in the warehouse. Then,actor act2, if free from any other task assignment, maybe instructed to reach loc glazing and clean the con-veyor belt from possible debris. The corresponding up-dated process is shown in Fig. 2(b), with the encircledsection being the recovery (adaptation) procedure. No-tice that after the recovery procedure, the enactment ofthe original process can be resumed to its normal flow.

The execution of a manufacturing process can alsobe jeopardized by the occurrence of exogenous events.Indeed, exogenous events could change, in asyn-chronous manner, some contextual properties of theenvironment in which the process is under execution,hence possibly requiring the process to be adapted ac-cordingly. In our example, since any step of the pro-duction process is monitored through the usage of spe-cific sensors that allow the online tracking of the rele-vant environmental parameters (temperature, humidity,pressure, etc.), it may happen that an incorrect valueof one of such parameters affects the quality of thetransformations of the ceramic material. For example,suppose that during the firing step the environmental


(a) Main production process

(b) Failed CHECKQUALITY(obj3,loc glazing)

(c) Fix temperature of the oven machine to deal with the exogenous event HIGHTEMP(obj2,loc firing)

Fig. 2. The production process of a ceramic sanitary ware factory and its adaptation.

temperature of obj2 reaches a dangerous value (seeFig. 2(c)). In such a case, the CPMS needs first tostop all the running tasks, and then to find a recov-ery procedure that allows to “normalize” the situationbefore it causes defects to the ceramic materials un-der firing. The corresponding adapted process is shownin Fig. 2(c), and consists of instructing act1 to reachloc firing for configuring the oven system to modify itstemperature to a reasonable value (see task FIXTEMP),for a correct firing of obj2.

The idea underlying the two above (simple) exam-ples of adaptation is therefore to reason over the bigdata generated by the 3D scanners and the sensors andleave an adaptive CPMS to detect and resolve distur-bances at run-time before they escalate and result inproduct defects, with the target to optimize the wholeproduction process by reducing the time to production.

The point is that it is not adequate to assume thatthe process designer can pre-define all possible recov-ery activities for dealing with unanticipated exceptionsand exogenous events in environments that are cyber-physical as the one just described: the recovery pro-

cedure will depend on the actual context (e.g., the po-sitions of actors and robots, robot’s battery levels, therange of the sensors, whether a location has becomedangerous to get it, etc.) and there are too many ofthem to be considered. Because of that, there is not al-ways a clear anticipated correlation between a changein the context and a change in the process.

2.2. A Conceptual Architecture for CPPs

The previous application scenario emphasizes thatthe management of a CPP requires additional chal-lenges to be considered if compared with a traditional“static” business process. On the one hand, there isthe need of representing explicitly real-world objectsand technical aspects like device capability constraints,sensors range, actors and robots mobility, etc. On theother hand, since cyber-physical environments are in-trinsically “dynamic”, a CPMS providing real-timemonitoring and automated adaptation features duringprocess execution is required.

To this end, the role of the data perspective be-comes fundamental. Data, including information pro-


Fig. 3. A conceptual architecture for CPPs.

cessed by process tasks as well as contextual informa-tion, are the main driver for triggering process adapta-tion, as focusing on the control flow perspective only -as traditional PMSs do - would be insufficient.

In fact, in a cyber-physical environment, a CPP isgenuinely knowledge and data centric: its control flowmust be coupled with contextual data and knowledgeproduction and process progression may be influencedby user decision making. This means that traditionalimperative models have to be extended and comple-mented with the introduction of specific cognitive con-structs such as data-driven activities and declarativeelements (e.g., tasks preconditions and effects) whichenable a precise description of data elements and theirrelations, so as to go beyond simple process variables,and allow establishing a link between the control flowand the data perspective.

Starting from the above considerations, coupledwith the experience gained in the area and lessonslearned from several projects involving CPSs (a par-tial list of such projects is detailed in the Acknowl-edgments), we have devised a conceptual architec-ture to build a CPMS for the management of CPPs,which supports the so-called Plan-Act-Learn cyclefor cognitively-enabled processes [33]. As shown inFig. 3, we identified 5 main architectural layers that wepresent in a bottom-up fashion.

The cyber-physical layer consists mainly of twoclasses of physical components: (i) sensors (suchas GPS receivers, RFID chips, 3D scanners, cam-eras, etc.) that collect data from the physical environ-ment by monitoring real-world objects and (ii) actua-

tors (robotic arms, 3D printers, electric pistons, etc.),whose effects affect the state of the physical envi-ronment. The cyber-physical layer is also in chargeof providing a physical-to-digital interface, which isused to transform raw data collected by the sensorsinto machine-readable events, and to convert high-levelcommands sent by the upper layers into raw instruc-tions readable by the actuators. The cyber-physicallayer does not provide any intelligent mechanism nei-ther to clean, analyse or correlate data, nor to composehigh-level commands into more complex ones; suchtasks are in charge of the upper layers.

On top of the cyber-physical layer lies the servicelayer, which contains the set of services offered bythe real-world entities (software components, robots,agents, humans, etc.) to perform specific process tasks.In the service layer, available data can be aggregatedand correlated, and high-level commands can be or-chestrated to provide higher abstractions to the upperlayers. For example, a smartphone equipped with anapplication allowing to sense the position and the pos-ture of a user is at this layer, as it collects the raw GPS,accellerometer and motion sensor data and correlatesthem to provide discrete and meaningful information.

On top of the service layer, there are two further lay-ers interacting with each other. The enactment layer isin charge of (i) enacting complex processes by decid-ing which tasks are enabled for execution, (ii) orches-trating the different available services to perform thosetasks and (iii) providing an execution monitor to detectthe anomalous situations that can possibly prevent thecorrect execution of process instances. The executionmonitor is responsible for deciding if process adapta-tion is required. If this is the case, the adaptation layerwill provide the required algorithms to (i) reason onthe available process tasks and contextual data and to(ii) find a recovery procedure for adapting the processinstance under consideration, i.e., to re-align the pro-cess to its expected behaviour. Once a recovery pro-cedure has been synthesized, it is passed back to theenactment layer for being executed.

Finally, the design layer provides a GUI-based toolto define new process specifications. A process de-signer must be allowed not only to build the pro-cess control flow, but also to explicitly formalize thedata reflecting the contextual knowledge of the cyber-physical environment under observation. It is impor-tant to underline that data formalization must be per-formed without any knowledge of the internal workingof the physical components that collect/affect data inthe cyber-physical layer. In order to link tasks to con-


textual data, the GUI-based tool must go beyond theclassical “task model” as known in the literature, byallowing the process designer to explicitly state whatdata may constrain a task execution or may be affectedafter a task completion. Finally, besides specifying theprocess, configuration files should also be produced toproperly configure the enactment, the services and thesensors/actuators in the bottom layers.

Based on this conceptual architecture, we realizedan approach – called SmartPM – and an implementedCPMS for adapting CPPs at run-time, whose detailswill be discussed in the next section.

3. The SmartPM Approach and System

SmartPM (Smart Process Management) is an ap-proach and an adaptive CPMS implementing a set oftechniques that enable to automatically adapt processinstances at run-time in the presence of unanticipatedexceptions, without requiring an explicit definition ofhandlers/policies to recover from tasks failures and ex-ogenous events. SmartPM adopts a layered service-based approach to process management, i.e., tasks areexecuted by services, such as software applications, hu-mans, robots, etc. Each task can be thus seen as a singlestep consuming input data and producing output data.

To monitor and deal with exceptions, the SmartPMapproach leverages on [16]’s technique of adaptationfrom the field of agent-oriented programming, by spe-cializing it to our CPP setting (see Fig. 4). We consideradaptation as reducing the gap between the expectedreality EXP, the (idealized) model of reality used bythe CPMS to reason, and the physical reality PHY, thereal world with the actual conditions and outcomes.While PHY records what is concretely happening inthe real environment during a process execution, EXPreflects what it is expected to happen in the environ-ment. Process execution steps and exogenous eventshave an impact on PHY and any deviation from EXPresults in a mismatch to be removed to allow processprogression. At this point, a state-of-the-art automatedplanner is invoked to synthesise a recovery procedurethat adapts the faulty process instance by removing thegap between the two realities.

To realize the above approach, the implementationof SmartPM covers the modeling, execution and mon-itoring stages of the CPP life-cycle. To that end, on thebasis of the conceptual architecture for building CPMSpresented in Section 2.2, the architecture of SmartPMrelies on five architectural layers.

The design layer provides a graphical editor devel-oped in Java that assists the process designer in thedefinition of the process model at design-time. Processknowledge is represented as a domain theory that in-cludes all the contextual information of the domain ofconcern, such as the people/services that may be in-volved in performing the process, the tasks, the dataand so forth. Data are represented through some atomicterms that range over a set of data objects, which depictentities of interest (e.g., capabilities, services, etc.),while atomic terms can be used to express propertiesof domain objects (and relations over objects). Tasksare collected in a repository and are described in termsof preconditions - defined over atomic terms - andeffects, which establish their expected outcomes. Fi-nally, a process designer can specify which exogenousevents may be caught at run-time and which atomicterms will be modified after their occurrence. Once avalid domain theory is ready, the process designer usesthe graphical editor to define the process control flowthrough the standard BPMN notation among a set oftasks selected from the tasks repository.

The enactment layer is in charge of managingthe process execution. First of all, the domain the-ory specification and the BPMN process are automat-ically translated into situation calculus [60] and In-diGolog [14] readable formats. Situation calculus isused for providing a declarative specification of the do-main of interest (i.e., available tasks, contextual prop-erties, tasks preconditions and effects, what is knownabout the initial state). Then, an executable model isobtained in the form of an IndiGolog program to be ex-ecuted through an IndiGolog engine. To that end, wecustomized an existing IndiGolog engine2 to (i) builda physical/expected reality by taking the initial contextfrom the external environment; (ii) manage the processrouting; (iii) collect exogenous events from the exter-nal environment; (iv) monitor contextual data to iden-tify changes or events which may affect process exe-cution. Once a task is ready for being executed, the In-diGolog engine assigns it to a proper process partici-pant (that could be a software, a human actor, a robot,etc.) that provides all the required capabilities for taskexecution.

The service layer acts as a middleware between pro-cess participants, the enactment layer and the cyber-physical layer. Specifically, in the service layer, pro-cess participants interact with the engine through aTask Handler, an interactive GUI-based software ap-

2http://sourceforge.net/projects/indigolog/


Phy

Exp

Fig. 4. An overview of the SmartPM approach.

plication realized for Android devices that supports thevisualization/execution of assigned tasks by selectingan appropriate outcome. Possibly such an Android ap-plication can exploit sensors and actuators (e.g., an Ar-duino board connected through Bluetooth, as currentlyrealized in our implementation), thus effectively offer-ing services over the cyber-physical layer. Every stepof the task life cycle - ranging from the assignment tothe release of a task - requires an interaction betweenthe IndiGolog engine and the task handlers. The com-munication between the IndiGolog engine and the taskhandlers is mediated by the Communicator Managercomponent (which is essentially a web server) and es-tablished using the Google Cloud Messaging service.

To enable the automated synthesis of a recoveryprocedure, the adaptation layer relies on the capabil-ities provided by a PDDL-based planner component(the LPG-td planner [29]), which assumes the avail-ability of a planning problem, i.e., an initial state anda goal to be achieved, and of a planning domain def-inition that includes the actions to be composed toachieve the goal, the domain predicates and data types.Specifically, if process adaptation is required, we trans-late (i) the domain theory defined at design-time intoa planning domain, (ii) the physical reality into theinitial state of the planning problem and (iii) the ex-pected reality into the goal state of the planning prob-lem. The planning domain and problem are the inputfor the planner component. If the planner is able tosynthesize a recovery procedure δa, the Synchroniza-tion component combines δ′ (which is the remainingpart of the faulty process instance δ still to be exe-cuted), with the recovery plan δa, builds an adaptedprocess δ′′ = (δa;δ′) and converts it into an executableIndiGolog program so that it can be enacted by the In-diGolog engine. Otherwise, if no plan exists for the cur-

rent planning problem, the control passes back to theprocess designer, who can try to manually adapt theprocess instance.

The cyber-physical layer is tightly coupled with thephysical components available in the domain of inter-est. Since the IndiGolog engine can only work with de-fined discrete values, while data gathered from physi-cal sensors have naturally continuous values, the sys-tem provides several web tools that allow process de-signers to associate some of the data objects defined inthe domain theory with the continuous data values col-lected from the environment. For example, we devel-oped several web tools to associate the data collectedfrom sensors (GPS, temperature, noise level, etc.) todiscrete values. In Section 6.1, we provide a concreteexample of a location web tool that allows processdesigners to mark areas of interest from a real mapand associate them to discrete locations. The mappingrules generated are then saved into the CommunicationManager and retrieved at run-time to allow the match-ing of the continuous data values collected by the spe-cific sensor into discrete data objects.

In the following sections, we will first presentthe formal approach of SmartPM developed throughaction-based formalisms for covering the enactmentand adaptation layers of the architecture, and we thenprovide some technical details of the tools and of theplugins employed in the design and service layers forconcretely interacting with the system.

4. AI Agent Programming and Planning

Before describing the theoretical framework under-lying SmartPM, we first provide some preliminary no-tions required to understand the rest of the paper.


4.1. Situation Calculus and Basic Action Theories

The situation calculus is a logical language de-signed for representing and reasoning about dynamicdomains [60]. The dynamic world is seen as progress-ing through a series of situations as a result of variousactions being performed. A situation s is a first-orderterm denoting the sequence of actions performed so far.The special constant S0 stands for the initial situation,where no action has yet occurred, whereas a binaryfunction symbol do(a,s) denotes the situation resultingfrom the performance of action a in situation s. A situ-ation s is a sub-situation of s′, denoted s v s′, iff s is aprefix of s′. Formally, the relation is axiomatized as fol-lows: sv s′ ≡ [s = s′∨ (∃a,s′′).s′ = do(a,s′′)∧ sv s′′].

In situation calculus, relations and functions whosevalue may change from one situation to the next aremodeled by means of so-called relational fluents andfunctional fluents. They are denoted by predicate andfunction symbols (respectively) taking a situation termas their last argument. A special predicate Poss(a,s)is used to state that action a is executable in situa-tion s, whereas special (situation-independent) predi-cate Exog(a) is used to denote that a is an exogenousevent originated from the external environment. Wewrite φ(~x) to denote a formula whose free variables areamong variables~x. A fluent-formula is one whose onlysituation term mentioned is situation variable s.

Within this language, one can formulate action the-ories describing how the world changes as the result ofthe available actions. A basic action theory (BAT) [60]D = Σ∪DS0 ∪D poss∪Dssa∪Duna includes:

Σ domain-independent foundational axioms to de-scribe the structure of situations and some auxil-iary relations like v and Executable(s);

Dssa one successor state axiom per fluent capturing theeffects and non-effects (i.e., frame) of actions;

D poss one precondition axiom per action specifyingwhen the action is executable;

Duna unique name axioms for actions;DS0 initial state axioms describing what is true ini-

tially in S0, and auxiliary situation independentaxioms for predicate Exog(a).

In particular, the successor state axiom (SSA)for a relational fluent F(~x,s) is an axiom of theform F(~x,do(a,s)) ≡ ΨF(~x,a,s),3 where ΨF(~x,a,s)is a fluent-formula characterizing the dynamicsof fluent F(~x,s). When F(~x,s) is a functional

3Free variables are assumed to be universally quantified.

fluent, its successor state axiom has the form[F(~x,do(a,s)) = v] ≡ ΓF(~x,a,v,s), where ΓF(~x,a,v,s)states that the fluent takes value v when ac-tion a is executed in situation s and satisfiesthe functional constraint |= (∀~x,a,s)∃v.ΓF(~x,a,v,s)∧(∀v′).v′ 6= v ⊃ ¬ΓF(~x,a,v′,s). Importantly, ΨF(~x,a,s)and ΓF(~x,a,v,s) can accommodate Reiter’s solutionto the frame problem [60], avoiding to represent ex-plicitly a large number of intuitively obvious non-effects. In addition, precondition axioms are of theform Poss(a(~x),s) ≡ Πa(~x,s), where Πa(~x,s) is afluent-formula defining the conditions under which ac-tion a can be legally executed in situation s. UsingPoss, we can define what it means for a situation s tobe executable, using the following definition:

Executable(s)≡ s = S0∨ (∃a,s′).s = do(a,s′)∧Poss(a,s′)∧Executable(s′).

4.2. The IndiGolog high-level language

On top of situation calculus action theories, logic-based programming languages can be defined, which,in addition to the primitive actions, allow the defini-tion of complex actions. In particular, we focus on In-diGolog [14], the latest in the Golog-like family of pro-gramming languages for autonomous agents provid-ing a formal account of interleaved action, sensing,and planning. IndiGolog programs are meant to be ex-ecuted online, in that, at every step, a legal next ac-tion is selected for execution, performed in the world,and its sensing outcome gathered. To account for plan-ning, a special look-ahead construct Σ(δ)—the searchoperator—is provided to encode the need for solving(i.e., finding a complete execution) program δ offline.

IndiGolog allows us to define every well-structuredprocess as defined in [70]; it is equipped with all stan-dard imperative constructs (e.g., sequence, conditional,iteration, etc.) to be used on top of situation calculusprimitives actions. An IndiGolog program is meant torun relative to a BAT. Here we concentrate on the frag-ment defined by the following constructs:

a atomic actionφ? test for a conditionδ1;δ2 sequenceπx.δ(x) nondeterministic choice of argumentδ∗ nondeterministic iterationif φ then δ1 else δ2 endIf conditionalwhile φ do δ endWhile while loopproc P(~x) do δ(x) endProc procedureδ1‖δ2 concurrency


δ1〉〉δ2 prioritized concurrency〈φ→ δ〉 interruptΣ(δ) lookahead search

Test program φ? can be executed if condition φ holdstrue, whereas program πx.δ(x) executes program δ(x)for some nondeterministic choice of a binding for vari-able x, and δ∗ executes δ zero, one, or more times. Theinterleaved concurrent execution of two programs isrepresented with constructs δ1‖δ2 and δ1〉〉δ2; the lat-ter considering δ1 at higher priority level (i.e., δ2 canperform a step only if δ1 is blocked or completed). Theinterrupt construct 〈φ→ δ〉 states that program δ oughtto be executed to completion if φ happens to becometrue. Let’s focus on it:

〈 φ→ δ 〉 def= while Interrupts running do

if φ then δ else false? endIfendWhile

To see how this works, first assume that the specialfluent Interrupts running is true. When an interrupt〈φ → δ〉 gets control from higher priority processes,suspending any lower priority processes that may havebeen advancing, it repeatedly executes δ until φ be-comes false. Once the interrupt body δ completes itsexecution, the suspended lower priority processes mayresume. The control release also occurs if φ cannotprogress (e.g., since no action meets its precondition).Finally, IndiGolog incorporates the so-called searchconstruct Σ(δ), which performs lookahead reasoningon δ to guarantee that a full, terminating, execution ofδ will be eventually achieved. Concretely, every stepperformed on δ will be one that is part of a terminatingexecution (see [14] for its formal semantics).

By properly combining prioritized concurrency andinterrupts, together with IndiGolog’s default online ex-ecution style, it is possible to design processes thatare sufficiently open and reactive to dynamic environ-ments. Furthermore, by resorting to the search oper-ator, one can specify local places in programs wherelookahead reasoning is required. Both aspects will endup being fundamental for our adaptive process man-agement framework in the next sections.

4.3. AI Automated Planning

Planning systems are problem-solving algorithmsthat operate on explicit representations of states andactions [49,28]. PDDL [43] is the standard planningrepresentation language; it allows one to formulate aplanning problem P = 〈I,G,P D〉, where I is the ini-

tial state, G is the goal state, and P D is the planningdomain. In turn, a planning domain P D is built froma set of propositions describing the state of the world(a state is characterized by the set of propositions thatare true) and a set of actions that can be executed inthe domain. An action schema a ∈ Ω is of the forma = 〈Para,Prea,Eff a〉, where Para is the list of inputparameters for a, Prea defines the preconditions underwhich a can be executed, and Eff a specifies the effectsof a on the state of the world. Both preconditions andeffects are stated in terms of the propositions in PD .Propositions can be represented through boolean pred-icates and numeric fluents.

There exist several forms of planning in the AI lit-erature. In this paper, we focus on planning techniquescharacterized by fully observable, static and determin-istic domains, i.e., we rely on the classical planningassumption of a “perfect world description” [74]. Un-der this assumption, a solution for a planning prob-lem P is a sequence of actions—a plan—whose exe-cution transforms the initial state I into a state satis-fying the goal G. Such a plan is computed in advanceand then carried out (unconditionally). The field of au-tomated planning has experienced huge advances inthe last twenty years, leading to a variety of concretesolvers (i.e., planning systems) that are able to createplans with thousands of actions for problems contain-ing hundreds of propositions. In this work, we repre-sent planning domains and planning problems usingPDDL 2.2 [21] (see Section 5.3 for a discussion onwhich specific features of the language we employedin our system).

5. The SmartPM approach through action-basedformalisms

In this section we show how one can put togetherthe three action-based formalisms and frameworks de-scribed above to build our adaptive CPMS. Specif-ically, we first describe how to explicitly formalizeprocesses in situation calculus, which will be used tomodel the contextual information in which the processis meant to run. Then, starting from this formalization,we discuss how SmartPM has been coded by the inter-preter of IndiGolog for devising a technique that auto-matically detect and recover from failures, and finallywe show how planning systems will support the auto-mated adaptation of a process when needed.


5.1. The Framework

5.1.1. SmartPM Basic Action TheoryFollowing [42], a situation calculus BAT DSmartPM

for a SmartPM application specifies:

1. the tasks and services of the domain of concern;2. the framework for managing the task life-cycle;3. the contextual setting in which processes operate;4. the framework for the monitoring of processes.

To encode tasks and services, we use some non-fluent “rigid” predicates, i.e., their truth values do notdepend on a situation term:

– Service(srv): srv is a service (i.e., a pro-cess participant). The predicate can be special-ized into further predicates, e.g., Actor(srv),MovingRobot(srv), etc., describing the specificservices’ roles;

– Task(t): t is a task, e.g., GO or CHECKQUALITY,may denote the tasks of navigating or checkingthe quality of ceramic material after a manipula-tion;

– Capability(c): c is a capability, e.g., camera maydenote the ability to perform a 3D scanning of thesurface of ceramic material;

– Provides(srv,c): service srv provides capability c;– Requires(t,c): task t requires the capability c.

A service srv is able to perform certain task t iff srvprovides all capabilities required by the task t. This iscaptured formally using the following abbreviation:4

Capable(srv, t) def=

Service(srv)∧Task(t)∧∀c.Requires(t,c)⊃ Provides(srv,c).

To talk about concrete runs of tasks, we associatethem with unique identifiers. A task instance is then atuple t : id, where t is a task and id is an identifier.

The life-cycle of a generic task t involves the exe-cution of four primitive actions executed by the CPMSand two external actions arising from services:

1. First, the CPMS assigns task instance t : id toa service srv by performing primitive actionASSIGN(srv, id, t,~i, ~oe), where~i is an input datavector associated to t : id and ~oe is a vector of ex-pected (sensing result) outputs.

4An abbreviation is a predicate (with situation argument s) de-fined by means of a formula uniform in s. Abbreviations, unlike flu-ents, are not directly affected by actions.

2. When a service is ready for task exe-cution, it generates the external actionREADYTOSTART(srv, id, t).

3. Next, the CPMS performs primitive actionSTART(srv, id, t) to authorize the service in ques-tion to start carrying out the task instance.

4. When the service completes the task, it generatesthe external action FINISHED(srv, id, t,~i,~or), with~or representing a vector of physical actual out-comes returned by the task execution (we use ε

to denote the empty output).5. At this point, the CPMS updates the properties

(i.e., the fluents) to reflect the effects of the taskjust completed.

6. Finally, the CPMS acknowledges the completionof the task and releases the task from the servicevia primitive actions ACKCOMPL(srv, id, t) andRELEASE(srv, id, t).

Note that we suppose that in all application domainsservices, tasks, input and output data vectors rangeover finite values.

The above protocol for the life-cycle of tasks is cap-tured by means of a set of domain-independent fluentsand actions. For example, fluent Free(srv,s) denoteswhether a service srv is available for task assignmentsin situation s.

Free(srv,do(a,s)) def=

(∃t, id)a = RELEASE(srv, id, t)∨[Free(srv,s)∧ (∀t, id,~i,~o)a 6= ASSIGN(srv, id, t,~i,~o)];

That is, a service is free (for task assignment) afterthe execution of an action a iff a releases the servicefrom some task assignment, or it was free before theexecution of a and a does not assign a task to it.

Observe that SmartPM employs a push-based ap-proach to task assignment. Specifically, the system dy-namically selects an available service qualified for ex-ecuting a given task and directly allocates the task itemto the selected service. Conversely, traditional PMSstypically adopt a pull-based approach, with the sys-tem that offers each task to one or more services qual-ified for it and a service chooses one task for execu-tion among the offered items. However, a pull-basedapproach to task assignment is not suitable for CPPs[58], which are usually highly critical and time de-manding, and the risk exists to have some task(s) wait-ing indefinitely for being selected and executed. There-fore, in SmartPM each task is directly assigned to onlyone available service at a time, and each service getsassigned at most one task.


To record the expected output of task instance t : idwhen assigned to a service, we define a functional flu-ent ExOut(id, t,s), whose SSA is as follows:

ExOut(id, t,do(a,s)) =~o≡(∃srv,~i)a = ASSIGN(srv, id, t,~i,~o)∨ExOut(id, t,s) =~o.

That is, the expected output of a task instance is deter-mined by the assignment step (and never changes). Ini-tial expected outcomes are initialized to “no value” (ε)via an axiom (∀t, id).ExOut(id, t,S0) = ε in the set ofaxioms DS0 . Other similar fluents are used to managethe life-cycle of tasks.

The BAT shall also contain a set of domain-dependent fluents, together with their correspondingprecondition and SSAs, capturing the contextual sce-nario in which the process is meant to be executed. Wecall such fluents data fluents. They can be seen as fea-tures of the world whose value may change from sit-uation to situation. In general, data fluents will be af-fected upon the release of an assignment task, that is,whenever a task is considered fully executed. In addi-tion, the actual outcome result of a task is used to de-fine the fluent in question. Importantly, the SSAs willfollow the following template:

F(~x,do(a,s)) = v≡γF (~x,a,v,s)∨ [F(~x,s) = v∧ (¬∃v)γF (~x,a,v,s)],

(1)

where γF(~x,a,v,s) states the conditions under whichaction a executed in situation s will cause datafluent F(~x,s) to take value v. In the context ofour setting, two type of actions will be mentionedin γF(~x,a,v,s), namely, (i) actions of the formFINISHED(srv, id,Tk,~i,~or) reporting the completion ofsome task instance Tk : id that would affect the data flu-ent and (ii) exogenous events that would also affect thevalue of the data fluent.

Example 5.1. Suppose that, in our manufacturing sce-nario, functional data fluent At(srv,s) is used to keeptrack of the location of service srv in the domain. Thefluent is affected by tasks GO and MOVE. Hence, theSSA for the fluent follows the template (1) above withγF(~x,a,v,s) being instantiated as follows:

γAt(srv,a,v,s) def=

(∃id, ls, ld , t)(a = FINISHED(srv, id, t, [ls, ld ], [v])∧t ∈ GO,MOVE∧ (Actor(srv)∨MovingRobot(srv)))∨(a = PUSHED(srv)∧Actor(srv)∧ v = “lost”).

In words, actor/robot srv is in location v if srv has justcompleted the task GO or MOVE whose actual physical

outcome result is v, or if human service actor srv hasjust been unexpectedly pushed away from the factoryduring her/his working time (with the exogenous eventPUSHED) and v records the fact that we lost track ofits position. Observe that even when a navigation taskhas just been finished, the new location v of srv mayhappen to be different to the expected (destination) lo-cation ld .

Besides data fluents, an application will generallyrequire further domain-dependent rigid predicates torepresent the static properties of a contextual scenario.Such predicates do not change their value during pro-cess execution. For example, our application scenariorequires to define a predicate Neigh(loc1,loc2) to ex-presses the neighborhood property between two loca-tions of the factory.

Using the core data fluents and static predicates, onecan also define helpful abbreviations, such as the fol-lowing ones to capture that at least an actor must bealways present (at any point in time) in the warehousecontaining the ceramic materials with defects.

Example 5.2. The abbreviation atLeastOne(s) de-notes that in any situation at least an actor is presentin the warehouse. This abbreviation will be used forexception monitoring and is defined as follows:

atLeastOne(s) def=

∃srv.At(srv,s) = loc warehouse∧Actor(srv).

The abbreviation atLeastAnotherOne(srv,s) is usedto check that at least an actor different from srv ispresent in the warehouse. This abbreviation will beused in the precondition of the navigation tasks for hu-man actors, and is defined as follows:

atLeastAnotherOne(srv,s) def=

∃srv2.At(srv2,s) = loc warehouse∧Actor(srv2)∧ (srv 6= srv2).

Data fluents and abbreviations will be used for defin-ing the preconditions of domain tasks. By doing so, theCPMS can reason, at run-time, about the active processinstance relative to the current context. For example,while we have given above a generic precondition forassigning tasks to services, one can also incorporatedomain-specific restrictions for task assignment.

Example 5.3. The following precondition axiom de-fines when the CPMS can assign a navigation task to ahuman actor and robot services:


Poss(ASSIGN(srv, id,GO, [ls, ld ], [le]),s)≡Free(srv,s)∧Capable(srv,GO)∧Actor(srv)∧ (At(srv,s) = ls)∧atLeastAnotherOne(srv,s)∧ (le = ld);

Poss(ASSIGN(srv, id,MOVE, [ls, ld ], [le]),s)≡Free(srv,s)∧Capable(srv,MOVE)∧MovingRobot(srv)∧ (At(srv,s) = ls)∧ (le = ld)∧EnoughBattery(BatteryLevel(srv,s),MoveStep(ls, ld)).

So, besides the service being available and capable ofcarrying out the navigation task, it also needs to be anactor located at the source location ls and another dif-ferent actor located in the warehouse. In addition, theexpected outcome of the task instance ought to be thedestination location ld . A similar MOVE action can beused to instruct robots to move between two locations,though it is also required the robot’s current batterylevel is enough to move from source ls to destinationld . This latter “constraint” is represented through theabbreviation EnoughBattery, which is defined over thefluent BatteryLevel (it records the battery charge levelof a robot in a specific situation) and the static predi-cate MoveStep (it indicates the cost for a robot to movebetween two specific locations).

Before addressing the issue of how monitoring ismodeled in CPPs, we provide the full successor stateaxiom of another data fluent which is affected by bothactions and asynchronous exogenous events.

Example 5.4. Data fluent Status(ob j,s), which de-notes the state of ceramic element ob j at situation s,is affected by three domain tasks as well as by the ex-ogenous event HIGHTEMP(ob j, l). The latter indicatesthat the temperature of ob j during the enactment of oneof the step of the production process (situated at loca-tion l) is too high if compared with its normal expectedvalue.

Status(ob j,do(a,s)) = v≡[(∃srv, id, t, l)a = FINISHED(srv, id, t, [ob j, l], [v])∧

t ∈ CHECKQUALITY,DEPOSIT, FIXTEMP]∨[(∃l)a = HIGHTEMP(ob j, l)∧ v = ’high temperature’]∨[Status(ob j,s) = v∧¬(∃srv, id, t, l,v′)(a = FINISHED(srv, id, t, [l], [v′])∧

t ∈ CHECKQUALITY,DEPOSIT, FIXTEMP)∧a 6= HIGHTEMP(ob j, l)].

In words, tasks CHECKQUALITY, DEPOSIT andFIXTEMP are all meant to report the status of theceramic element they operate on, upon completion.Moreover, high temperature events also change the sta-tus of the corresponding ceramic element.

This concludes the exposition of the first three as-pects of a SmartPM action theory. Now we will focuson how our framework is able to deal with exceptionmonitoring and management.

5.1.2. Exception MonitoringWe now turn our attention to the mechanism for au-

tomatically detecting failures/exceptions. In a nutshell,an exception occurs when a task does not produce theexpected outcomes or an exogenous event arises.

The “physical” reality captures the actual value offluents (and abbreviations) as observed in the sys-tem, and is encoded via the data fluents (and abbre-viations), as described above, e.g., fluents At(srv,s),Status(ob j,s) and abbreviation atLeastOne(srv,s).

The “expected” reality, in turn, is captured with an-other set of fluents and abbreviations, one for each onein the physical reality. So, for every data fluent F(~x,s),a new fluent Fexp(~x,s) (F-expected) is used to representthe value of F(~x,s) in the “expected” (or “desired”)execution. Technically, if F(~x,do(a,s)) is a relationaldata fluent with successor state axiom F(~x,do(a,s))≡ΨF(~x,a,s), then we build Fexp(~x,s)’s counterpart asfollows (the one for functional fluent is built in analo-gous way):

Fexp(~x,do(a,s))≡[a = ALIGN ⊃ F(~x,s)]∨[(∃srv, id, t,~i, ~or)a = FINISHED(srv, id, t,~i, ~or)⊃

Ψ∗F (~x, FINISHED(srv, id, t,~i,ExOut(id, t,s)),s)]∨[a 6∈ ALIGN, FINISHED ⊃ Fexp(~x,s)].

(2)

where Ψ∗F(~x,a,s) is obtained by replacing every flu-ent X mentioned in ΨF(~x,a,s) (the right-hand-side for-mula of F’s successor state axioms) with its expectedversion Xexp.

The first disjunct states that the special actionALIGN, whose execution is always possible, assignsthe actual value of the fluent to its expected value, thusproviding a synchronization mechanism between theexpected and physical realities.

The second condition states that the expected valueof the fluent is the value that the fluent would get ifall tasks executed so far since the last alignment pointend with their expected output (denoted with termExOut(id, t,s)). Basically, when a FINISHED action isinvoked, the F’s successor state axiom is used with theexpected outcome in place of the real outcome (i.e., ~oris replaced with ExOut(id, t,s)).

Finally, the third condition states that for all othercases, the expected fluent keeps the value it had before(i.e., inertia law is applicable).


Similarly, for each abbreviation A(s) def= Ψ(s), an ex-

tra abbreviation Aexp(s) is defined as Aexp(s)def= Ψ∗(s),

where Ψ∗(s) is obtained by replacing each fluent (orabbreviation) X in Ψ(s) with its expected version Xexp.

Observe that the value of the expected version of afluent is predicated on the assumption that exogenousaction FINISHED will carry the expected output of thetask of concern. This may indeed deviate from the ac-tual output, thus yielding a mismatch between physicaland expected reality.

Therefore, given a physical reality, an expected re-ality can be seen as the collection of values of the ex-pected versions of data fluents and abbreviations.

Example 5.5. Upon (syntactic and semantic) simpli-fication, the expected version for fluent Atexp(srv,s) isas follows:

Atexp(srv,do(a,s)) = l ≡a = ALIGN ⊃ At(srv,s)∨[(∃id,~i, t, ~or)a = FINISHED(srv, id, t,~i, ~or)⊃

t ∈ GO,MOVE∧ (Actor(srv)∨MovingRobot(srv))⊃l = ExOut(id, t,s))]∨

[a 6= ALIGN ∧ ¬(∃id,~i, t, ~or)a = FINISHED(srv, id, t,~i, ~or)∧t ∈ GO,MOVE ⊃ Atexp(srv,s) = l].

For abbreviation atLeastOne(s), however, we wantto force the constraint/expectation that at least one ac-tor is always located in the warehouse, and hence wesimply take atLeastOneexp(s)

def= true.

Next, using the data fluents and their expected ver-sions, a misalignment can be recognized and a recov-ery procedure may be needed. However, it may only beimportant to check for mismatches among some prop-erties of the world. So, a data fluent (or abbreviation) isconsidered relevant by the process designer if its evo-lution should be monitored during process enactment.We assume then that the designer specifies abbrevia-tion Misaligned(s) to characterize misalignment situa-tions that would require process adaptation. The gen-eral form of such an abbreviation is as follows:

Misaligned(s) def=

∃~x1.ΦF1(~x1,s)⊃ ¬[F1(~x1,s)≡ F1exp(~x1,s)]∨

...∃~xn.ΦFn(~xn,s)⊃ ¬[Fn(~xn,s)≡ Fn

exp(~xn,s)],

where F i(~xi,s), with i ∈ 1, . . . ,n, are all the data flu-ents and abbreviations used in the SmartPM applica-tion. Each condition ΦF i(~xi,s) states the conditions un-der which data fluent F i(~xi,s) is relevant and needs tobe traced for “misalignment.”

Example 5.6. In our case study, we are interested,among other things, in monitoring the correct locationof human actors, the good “status” of ceramic elementsunder transformation and the presence in any momentof at least one actor in the warehouse. Technically, wemodel that as follows:

Misaligned(s) def=

∃x1.Actor(x1)⊃ ¬[At(x1,s)≡ Atexp(x1,s)]∨∃ob1.CeramicElement(ob1)⊃¬[Status(ob1,s)≡ Statusexp(ob1,s)]∨¬[atLeastOne(s)≡ atLeastOneexp(s)]∨

...

Observe the definition is not concerned about excep-tions on the location of moving robots, for example.

This concludes the explanation on what type of sit-uation calculus BAT we shall use in a SmartPM appli-cation. Let us call such a theory DSmartPM.

5.2. SmartPM High-Level Program

A SmartPM application involves the online execu-tion of IndiGolog program (SmartPM‖δexog) model-ing the concurrent execution of the specific applica-tion with special program δexog = (πa.Exog(a)?;a)∗

accounting for all potential exogenous events thatmay arise from the external environment. Algorithm 1shows a fragment of the IndiGolog program for aSmartPM application. The program, as any high-levelprogram, is meant to be executed relative to a DSmartPM

BAT as developed above, which shall give meaningto conditions and primitive statements in the program(i.e., actions). We note that the only domain-dependentpart in Algorithm 1 is procedure Process–all other pro-cedures remain unchanged across applications.

The top-level part of the CPMS involves five in-terrupts running at different priorities, as long as thedomain process is not yet finished. The highest threepriority programs deal with automated process adap-tation; the fourth deals with actual process execution;and the last one forces the system to wait for furtherchanges.

First, if the system has just been adapted, then thetwo realities—expected and actual—must be aligned,as a new repair plan has been found and a new syn-chronization point has been reached.

Second, the system checks for a misalignment be-tween the actual reality and the expected one, as ex-plained above. If a mismatch is recognized, process


adaptation is initiated by calling procedure Adapt (seesubsection 5.3 below).

The third interrupt triggers whenever there is a mis-alignment but the adaptation procedure (in the secondpriority interrupt) was not able to find a successful planto repair such misalignment. In that case, the whole ex-ecution waits, for some exogenous events that can al-low the system to adapt. Though outside the scope ofthis paper, another possibility in such cases would be toresort to alternative orthogonal adaptation techniques,such as planning from first-principles (as done in [68])or just require human intervention.

Whenever there is no adaptation process in place,the CPMS runs the IndiGolog program reflecting theactual process (fourth interrupt), by executing proce-dure Process. Recall that the actual CPP (cf.Fig. 2(a))is indeed modelled as yet another IndiGolog program.Managing the life-cycle of a task instance—procedureManageExec—involves selecting a free service capa-ble of carrying it out, assigning the task to the chosenservice, allowing the start of the service, acknowledg-ing its completion and fully releasing the service fromthe task. Note the use of the non-deterministic choiceof argument πsrv.δ(srv) to select (any) appropriate ser-vice, that is, one capable and free to be assigned thetask. Also, the sub-program πid.GETID(id) selects a“fresh” id, that is, an id not used so far, that will serveas the process id for the remaining part of the programManageExec so that for each task-related action exe-cution there is a unique id. To keep track of fresh iden-tifiers, a fluent FreshId(id) is used. The execution ofGETID(id) has the effect of setting FreshId(id) to false.As expected, the action can only be executed on freshids, that is:

Poss(GETID(id),s)≡ Fresh(id,s).

Finally, at the lowest priority (when the process can-not advance) the CPMS just waits for an external ac-tion to arrive from one of the services, e.g., a FINISHEDaction signaling the completion of a running task. Wenote that, while waiting, the (human) process designercould also manually intervene (for example, by addingnew services or updating the capabilities of existingservices).

5.2.1. Multi-instance ProcessesWhen modeling a business process, a commonly

used control flow mechanism is multi-instance execu-tion of sub-processes. Intuitively, the idea is to spawnthe execution of the same process on each object in agiven set. For example, in our domain, a process may

Proc SmartPM〈¬Finished∧MustAlign→ ALIGN〉〉〉〈¬Finished∧Misaligned→ Adapt〉〉〉〈¬Finished∧Misaligned→ WAIT〉〉〉〈¬Finished→ Process; FINISH〉〉〉〈¬Finished→ WAIT〉.

Proc AdaptΣ[SETMUSTALIGN;(πa.a)∗;¬Misaligned?];

Proc ManageExec(Task, Input,ExpOut)(π id).

GETID(id);(π srv).

(Capable(srv,Task)∧Free(srv))?;ASSIGN(srv, id,Task, Input,ExpOut);START(srv, id,Task);ACKCOMPL(srv, id, task);RELEASE(srv, id, task).

Proc ProcessSeq-MultiInstance-1;Conc-MultiInstance-2;Conc-MultiInstance-3;

...Seq-MultiInstance-13.

Proc Seq-MultiInstance-1for each x in CeramicElement(x)∧Status(x) = ok do∗

ManageExec(CONVEY, [x, loc start,loc rotomoulding], [loc rotomoulding])

endForProc Conc-MultiInstance-2

for each x in CeramicElement(x)∧Status(x) = ok do‖ManageExec(MOULD, [x, loc rotomoulding], [ok])

endForProc Conc-MultiInstance-3

for each x in CeramicElement(x)∧Status(x) = ok do‖

ManageExec(CHECKQUALITY, [x, loc rotomoulding], [ok])endFor.....

Proc Seq-MultiInstance-13for each x in CeramicElement(x)∧Status(x) = ok do∗

ManageExec(CONVEY, [x, loc f iring,loc end], [loc end])

endFor

Algorithm 1. IndiGolog high-level program for CPMS.

instruct every idle robot to navigate to a given location.There are two versions that are commonly used. In thesequential case, a given subprocess is executed on eachobject one at a time. In turn, in the non-sequential case,multiple instances of the subprocess, one per relevantobject, are concurrently executed. More concretely, if


o1,o2, · · · ,on are the objects of interest (e.g., all cur-rently idle robots) and δ(x) is the subprocess to be car-ried out (e.g., navigate to emergency location), a se-quential multi-instance execution would amount to ex-ecuting, for example, program δ(o1);δ(o2); · · · ;δ(on),whereas the non-sequential version would amount toany execution of program δ(o1)‖ δ(o2)‖ · · ·‖ δ(on).

Unfortunately, while common in business processeslanguages, this control flow construct is not providedby any of the languages in the Golog family. It turnsout, however, that we can realize such control flowby combining existing constructs together with extrabookkeeping information in the underlying action the-ory. Concretely, we first introduce a new construct de-fined as follows for the sequential version:

for each x in φ(~x) do∗ δ(~x) endFor def=

πid.STOREφ(id);[π~x.REMOVEφ(~x, id); δ(~x)]∗;?(¬∃~xMφ(id,~x))

Here, action STOREφ(id) is used to “save” every in-stance for which φ(~x) holds true into a distinguishedfluent Mφ(id,~x). By doing this, we are able to then ex-ecute process δ on each of those instances, regardlessof how formula φ(~x) changes its truth value as actionsare performed. The id’s is used in the auxiliary fluentMφ to make sure that different instances of the samefor-loop can be executed without clashing. To achievethat, the preconditions of the auxiliary actions are asfollows:

Poss(STOREφ(id),s)≡ FreshId(id,s);Poss(REMOVEφ(id,~x),s)≡Mφ(id,~x,s).

As with action GETID(id), the SSA for FreshId(id) en-codes the negative effect of action STOREφ(id) on idobject id (i.e., id is not available anymore), and theSSA for fluent Mφ(id,~x,s) encodes the negative effectof action REMOVEφ(id,~x) on (id,~x) (i.e., object ~x infor-each process id has been processed).

Finally, the non-sequential version can be defined asfollows:

for each x in φ(~x) do‖ δ(~x) endFor def=

πid.STOREφ(id);[π~x.REMOVEφ(~x, id); δ(~x)]‖;?(¬∃~xMφ(id,~x))

The last test step in the program is used to enforcethat any execution should process every (complex) ob-

ject ~t for which φ(~x) holds (i.e., any tuple ~t that hasbeen stored into fluent Mφ).

5.3. CPP Adaptation via Automated Planning

The most interesting part of the procedure involvesprocedure Adapt. An adaptation allows to find a se-quence of actions that will resolve the misalignment.This is exactly what the code inside the search op-erator Σ does: pick and execute actions zero, one, ormore times such that abbreviation Misaligned(s) be-comes false. The action SETMUSTALIGN at the frontof the search construct will just make MustAlign(s)true, which will trigger (provided an actual adaptationplan is found) the top-priority program in the main pro-cedure, where the action ALIGN (whose execution is al-ways possible) forces an alignment of the two realities,thus providing a synchronization mechanism betweenthem. Observe that because the adaptation mechanismruns at higher priority than the actual process, the re-covery plan found will be run before whatever part ofthe domain process remains to be executed.

Putting it all together, let us formally capture thetype of adaptation realized by our approach.

Definition 5.1. Let S be a ground situation termsuch that DSmartPM |= Misaligned(S). We say thatsituation S is recoverable if and only if it is thecase that DSmartPM |= ∃s′.S < s′ ∧ Executable(s′) ∧¬Misaligned(s′).

That is, a given situation can be recovered if thereis an executable sequence of actions from it that willeventually resolve the misalignment between the phys-ical and expected realities. Specifically, when the ex-ecution reaches a misalignment, the SmartPM proce-dure (i) will not execute the main process (encoded inprocedure Process and running at the fourth prioritylevel); and (ii) will execute the first action of a planto recover the current situation from misalignment, ifsuch a plan exists (otherwise, the system just waits; seeabove).

Importantly, the above result also makes explicitthe limits of our adaptation framework: if there is noplan able to resolve the existing mismatch, the systemjust waits (third point) and other orthogonal adaptationtechniques would need to be used, see discussion inSection 8.

While this specification of the automated adaptationprocedure turns out to be extremely clean and simple,the direct use of the native search operator provided bythe IndiGolog architecture [14] poses serious problems


in terms of efficiency. The fact is that the search opera-tor provided by IndiGolog amounts to a generic and in-cremental (i.e., done at every step) search; as a result,direct implementations are not able to cope with evenextremely easy adaptation tasks.

But, while the search operator is meant to handleany IndiGolog high-level program (including ones con-taining nested search operators), our SmartPM systemuses a specific type of program that turns out to encodea (classical) planning problem. So, leveraging on therecent progress of classical planning systems, we im-plement the search operator call in procedure Adapt,by using an off-the-shelf planner to synthesise the re-covery plan, and then fit such a plan back into the In-diGolog framework. Specifically, we used the LPG-tdsystem [29], one of the many state-of-the-art planningsystems available. The basic search scheme of LPG-tdis inspired by Walksat [65], an efficient procedure forsolving SAT-problems; as expected, it outperforms theblind search operator by several orders of magnitudes(cf. [42]). Nonetheless, our approach is orthogonal toother planning systems.

Since the integration of PDDL planning with situ-ation calculus and Golog-like languages has been al-ready analysed in several research works, such as [12,11,25], we just go over the main ingredients on how werealized the interface between IndiGolog and LPG-td.

First of all, given a BAT DSmartPM for a CPP applica-tion, the corresponding PDDL planning domain is built(and stored) offline. Because we are not concernedwith the external actions generated by services to ac-knowledge the start and termination of assigned pro-cesses (i.e., actions READYTOSTART and FINISHED),we do not model the full assign-start-acknowledge-release task life-cycle, but just encapsulates them all inthe actual name of the task being handled, e.g., GO. Bydoing that, we assume that the life-cycle of a task in-stance will follow its expected evolution. The SmartPMBAT will define a form of tasks and services reposi-tory, which may include entities not used in the currentrunning process. So, the PDDL domain for our casestudy will contain, among others, the following actionschema modeling the GO task:5

(:action go:parameters (?srv - actor ?from - location

?to - location):precondition

(and (provides ?srv movement) (free ?srv)(at ?srv ?from) (atLeastAnotherOne))

5In PDDL, the variables are distinguished by a ’?’ character atfront, for example ?x1 represents a variable. The dash ’–’ is used toassign types to the variables.

:effect (and (not (at ?srv ?from))(at ?srv ?to)))

Note that the task-action in the planning system willcontain the service in charge and its expected effects.

In this work we represent planning domains andproblems making use of the STRIPS fragment ofPDDL 2.2, enhanced with derived predicates and nu-meric features provided by the level 2 of the samelanguage. Specifically, derived predicates are em-ployed to encode all the required user-defined ab-breviations (for example, see the derived predicateatLeastAnotherOne used in the preconditions of theplanning action go), whereas numeric features are usedto model non-binary resources (such as, for example,the battery level of a robot), to keep track of the costsof planning actions and to synthesize plans satisfyingpre-specified metrics.

Whenever the adaptation program is called in pro-cedure Adapt, the current physical reality is encodedas the planning problem initial state (as the set of flu-ents that are true) and the expected reality is encodedas the problem goal state (by taking the collection ofrelevant fluents to be as their expected versions). Thosetwo states, together with the planning domain alreadypre-computed, are then passed to the LPG-td system.

Finally, if the planner finds a plan that bringsabout the (desired) expected reality, such a plan—built from task names only—is translated into the typi-cal assign-start-acknowledge-release task life-cycle In-diGolog program. As stated above, such a plan will runbefore the actual domain process, which shall resumethen, hopefully from the expected reality. In our run-ning example, the full IndiGolog program would en-code the CPP depicted in Fig. 2(a).

6. Evaluating SmartPM

While the framework presented in Section 5 focuseson the formalization of the approach through action-based formalisms (basically, we covered the enactmentand adaptation layers of the SmartPM architecture), inthis section we aim at providing some technical de-tails on the design and service layers, which consist oftools and plugins that allow human process designersto concretely interact with the SmartPM system (seeSection 6.1). Then, we show the results of some ex-periments performed with real users to investigate thepractical applicability of the SmartPM system to modelreal-world CPPs (see Section 6.2).


(a) The workspace provided by the SmartPM Definition Tool.

(b) The wizard-based editor to build tasks specifications.

(c) The location web tool to mark areas of interest.

Fig. 5. Some screenshots of the SmartPM Definition Tool.


6.1. Interacting with the SmartPM System

One of the main obstacles in applying AI techniquesto real problems is the difficulty to model the complex-ity of real-world domains. Let us take, for example,our SmartPM approach. It is evident that it would beextremely complex for a process designer to encode a(even simple) CPP in SmartPM by using directly ourframework based on action-based formalisms.

In the SmartPM system, we have tackled this issueby developing a GUI-based tool in the range of thedesign layer, which is called the SmartPM DefinitionTool. It supports the process design activity by provid-ing (i) several wizard-based editors that assist the pro-cess designer in the definition of the process knowl-edge (i.e., data objects, atomic terms, tasks with pre-conditions and effects, etc.), and (ii) a graphical editorto design the control flow of a CPP using a relevantsubset of the BPMN 2.0 notation. The SmartPM Defini-tion Tool has been developed using the Java SE 7 Plat-form, and the JGraphX open source graphical library.6

While a screenshot of the workspace of the SmartPMDefinition Tool is provided in Fig. 5(a), in Fig. 5(b)we show one of the wizard-based editor provided bySmartPM, specifically the one to build a task specifi-cation by defining the single conditions composing thetask preconditions and effects.

The SmartPM Definition Tool allows also to make ex-plicit the connection of implemented processes withthe real-world objects of the cyber-physical environ-ment of interest. For example, we developed a web toolthat allows a process designer to mark areas of interestfrom a real map (by selecting latidude/longitude val-ues) and associate them to the discrete locations (e.g.,loc00, loc01, etc.) defined during the design stage ofa process. Fig. 5(c) shows a screenshot of the locationweb tool. Similarly, we developed further web toolsfor the other developed sensors (temperature, humid-ity, noise level, etc.).

The interaction between process participants and theSmartPM system during the enactment of a CPP is per-formed through a Task Handler that supports the visu-alization of assigned tasks and enables starting task ex-ecution and notifying of task completion by selectingan appropriate outcome. The SmartPM Task Handler isrealized for Android devices from version 4.0 and up.Each device has an unique ID that matches the servicename defined in the domain theory by the designer. Ascreenshot of the Task Handler is shown in Fig. 6.

6http://www.jgraph.com/

Fig. 6. Screenshot of the Task Handler of SmartPM. In the figure,it is described how the data fluent At(act1) can be used to representthe effect of the task GO. We show that the output value for At(act1)(in the example ’loc03’, different from the task’s expected outcome,that is ’loc33’) can be produced by a sensor (i.e., a GPS device)supporting the Task Handler.

We created several plugins for the Task Handler toobtain, for example, location data using built-in GPSsensors or get the current noise level near the deviceusing its microphone. In addition, external sensors canbe taken into use to gather automatic measurements -for prototyping purposes, the Arduino platform7 canbe used. The Task Handler can take advantage of thistechnology for gathering environmental data. In fact,Arduino has a large variety of sensors available tomeasure different environmental values, for exampledifferent gas levels in the air, water quality, radiationlevel, etc. Arduino can be connected with Android viaBluetooth for transferring the data.

6.2. Investigating the practical applicability of theSmartPM system

The SmartPM System has been extensively vali-dated in our previous work [42] through empiricalexperiments based on 3600 different process modelshaving control flows with different structures and do-main theories associated to them. On the one hand,the experiments have confirmed the feasibility of the

7Arduino is an open-source physical computing platform basedon a simple microcontroller board, and a development environmentfor writing software for the board, cf. http://arduino.cc/en/guide/introduction


planning-based approach of SmartPM for adaptingprocesses in medium-sized cyber-physical environ-ments from the timing performance perspective. Onthe other hand, SmartPM was able to complete 2537process instances without any domain expert interven-tion, corresponding to an effectiveness of about 70,5%(see [42] for a discussion of such results).

Conversely, in this paper we focused our attention onevaluating if the SmartPM system is easy to be learntand used from non expert users in AI. The final pur-pose was to demonstrate that the modeling of CPPsat design-time and their execution with SmartPM doesnot require any specific expertise of the internal work-ing of the AI tools involved in the system. Therefore,we performed experiments to assess the learnability ofthe SmartPM Definition Tool.

In the Human-Computer Interaction community,learnability is recognized as one of the most relevantcomponents of usability [18]. Learnability is addressedin ISO 9126-1 as the capability of the software productto enable the user to learn its application and appliesto the nature of the performance change of a user wheninteracting with a system. The more learnable a systemis, the less time a user takes in order to understand howto do a specific task without having been previouslytrained and without using any documentation.

To measure the learnability of the SmartPM Defi-nition Tool, we leveraged on the approach developedin [32], which allows to identify quantitatively howmuch the user actions that take place during a run ofthe system for achieving a specific objective (for ex-ample, the creation of a new data object) deviate fromthe expected way of achieving the same objective asforeseen by the system. The weight of such deviationsis quantified through a fitness value, which estimateshow much the actions performed by the users adhere tothe expected way of using the system. The fitness valuecan vary from 0 to 1. A value equals to 1 means that theuser was able to achieve perfectly her/his objective asforeseen by the system. According to [32], the learn-ability of the system can be estimated by analyzing therate of the fitness values corresponding to subsequentexecutions of the system over time. An increasing ratewill correspond to a system that is easy to be learnt.

To assess the learnability of SmartPM against thecomplexity of realistic cyber-physical environments,we performed a usability tests with 23 Master studentsin Engineering in Computer Science during the univer-sity course of Seminars in Software and Services forthe Information Society8 (Academic Year 2015-2016),

8https://sites.google.com/a/dis.uniroma1.it/s4i-ss/

held at Sapienza - University of Rome. After a pre-liminary training session to describe the usage of theSmartPM Definition Tool, we provided to the students 4different homeworks of growing complexity in 4 con-secutive weeks (one homework per week); each home-work was targeted to model the domain theory and thecontrol flow of a realistic CPP through the SmartPMDefinition Tool. The students were requested to com-plete the homework assigned to them in a specific weekwithin the end of the week itself. Before the assign-ment of a new homework, we shown to the studentsthe optimal solution to perform correctly the previoushomework.

To apply the approach described in [32], werecorded in a specific log all the user actions per-formed by the students during their interaction with theSmartPM Definition Tool. Then, to assess the learnabil-ity of the system, we replayed such logs over three in-teraction models of the system describing the expectedways to achieve three relevant objectives: (i) definitionof a new data object, (ii) generation a new atomic termand (iii) creation of a new task specification.

The results of the experiments are provided in Fig. 7.Collected data are organized in 3 diagrams related tothe achievement of the three above objectives. For anydiagram, the x-axis indicates the specific homeworkconsidered, while the y-axis indicates the average fit-ness value obtained to achieve the specific objective.Notice that for each homework we represent two barsfor separating the students that performed correctly thewhole homework from the students that were not ableto complete it or to compute a correct solution.

The analysis of the performed experiments pointsout some interesting aspects. For example, let us con-sider the first diagram in Fig. 7, that shows the fitnessvalues related to the definition of a new data object.First of all, it is evident that both the rate of the fit-ness values and the number of students able to cor-rectly complete an homework increases over time, i.e.,homework after homework. In fact, while 6 studentsout of 23 were not able to complete the first home-work (around 26% of failure), the third and the fourthhomework were correctly completed by 20 and 21 stu-dents (percentage of success of 86.95% and 91.3%). Itis interesting to notice a “discontinuity” of this trendbetween the first and the second homework, probablycaused by the first relevant increase of complexity.

Concerning the fitness value, we can notice that itis always higher for those students that completed cor-rectly the whole homework, even if this gap slightlydecreases in the subsequent homeworks.


1st HomeworkOK 18 studentsNOK 5 students

2nd HomeworkOK 16 studentsNOK 7 students

3rd HomeworkOK 20 studentsNOK 3 students

4th HomeworkOK 21 studentsNOK 2 students

0

0.2

0.4

0.6

0.8

1

0.82 0.830.87

0.91

0.690.73

0.790.84

Definition of a data object





0

0.2

0.4

0.6

0.8

1

0.690.73

0.810.85

0.540.59

0.690.74

Generation of an atomic term





0

0.2

0.4

0.6

0.8

1

0.670.71

0.810.89

0.530.58

0.740.83

Creation of a task specification

Successful completion of the homework Not successful completion of the homework

Fig. 7. Analysis of the learnability of the SmartPM Definition Tool.

The above considerations are valid also for the otherdiagrams, even if the fitness values emphasize that thedefinition of a data object is a simpler task if comparedwith the generation of an atomic term or the creationof a task specification. However, also in this case, this“complexity gap” seems to decrease over time.

To sum up, the results obtained allow to observe anincreasing rate of the fitness value over time, whichindicates that the students performing the homeworkswere able to efficiently learn the usage of the SmartPMDefinition Tool, without any knowledge of the AI tech-nologies employed in the system.

7. Related work

Initial research efforts addressing the need for pro-cess adaptation in PMSs can be traced back to the latenineties and early two thousands [7,8,22,23,31,36,41].Although possible sources of exceptions are different(as outlined in [8,22], they can be attributed to ac-tivity failures, deadline expirations, resource unavail-abilities, constraint violations and external events) andgo beyond technical failures, not surprisingly processadaptation approaches provided by academic proto-types and commercial PMSs trace and resemble excep-tion handling mechanisms in programming languages(e.g., try-catch blocks) [1,10,67].

Typical strategies applied when defining exceptionhandlers for anticipated exceptions have been system-atized in the form of exception handling patterns [7,31,63,40,58], i.e., for any given exception, a predefinedexplicit handling logic is defined as a sequence of cor-rective actions to resolve the issue.

Conversely, the handling of unanticipated excep-tions does not assume the availability of predefined ex-ception handlers and relies on the possibility of per-

forming ad hoc changes over process instances at run-time [73,58]. This requires structural adaptation of thecorresponding process model. As in the case of ex-ception handling, structural adaptation techniques havebeen systematized through the identification of adap-tation patterns [71], i.e., predefined change operationsfor adding, deleting or replacing process activities.

Strong support for structural adaptation is providedby the ADEPT system and its evolutions [55,47,56,57,37]. However, while a good level of support can beprovided to ensure correctness and compliance whenstructural adaptation is performed, the degree of au-tomation is generally limited to manual ad hoc changesperformed by experienced users [61].

In an attempt to increase the level of user support,semi-automated approaches have been proposed [62].They aim at storing and exploiting available knowl-edge about previously performed changes, so that userscan retrieve and apply it when adapting a process. Suchan approach has been concretely put into practice usingcase-based reasoning techniques [72,45].

When compared with traditional exception handlingapproaches, we notice that adaptive PMSs deal withunanticipated exceptions by automatically deriving thetry block as the situation in which the PMS does notadequately reflect the real-world process anymore. Thecatch block is defined manually or semi-automaticallyat run-time and includes those recovery procedures re-quired for realigning the computerized processes withthe real-world ones. However, in cyber-physical work-ing environments, analyzing and defining these adapta-tions “manually” becomes time-demanding and error-prone. Indeed, the designer should have a global visionof the application and its context to define appropriaterecovery actions, which becomes complicated whenthe number of relevant context features and their inter-leaving increases. Conversely, our SmartPM approach


is able to automatically synthesizing at run-time thecatch block, without the need of any manual interven-tion at run-time, and increases the level of “automa-tion” in process adaptation.

The issue of having software systems automaticallyand autonomously adapt to changing conditions hasbeen also addressed in the last years under the auto-nomic and self-healing systems literature [30,52]. Insuch research contexts, SmartPM can be consideredas a specific kind of self-healing system addressingthe management of processes through AI-based tech-niques. In particular, according to what was presentedin [52], its main peculiarities are the use of a context-and data-aware process engine and the ability to reasonover dynamic contexts, for which the adopted KR&Rtechniques are particularly suitable.

A further research area related to process adaptationis the one of Web service composition [44,4,50,51,2,66,15]. Notably, most of the approaches to Web ser-vice composition adopt planning-based techniques, asthe SmartPM approach does. However, there exists anotable difference in what SmartPM and Web servicecomposition techniques synthesize through planning.In Web service composition, given a a set of availableservices and a target service, the challenge is to synthe-size a possible composition (a.k.a. orchestration) of theavailable services by preserving their behaviors (whichare in general quite rich, often modeled as transitionsystems) in order to obtain the target service. Con-versely, in the SmartPM approach, the aim is to syn-thesize a recovery process that repairs the original onein a specific situation of the world by using a set oftasks stored in a tasks repository. The main issue hereis to preserve as much as possible the original process,considering that process tasks are atomic and do notpresent rich behaviors to be preserved.

Finally, a number of techniques from the field of AIhave been applied to BPM with the aim of increas-ing the degree of automated process adaptation at run-time. One of the first works dealing with this researchchallenge is [3], which discusses at high level howthe use of an intelligent assistant based on planningtechniques may suggest compensation procedures orthe re-execution of activities if some anticipated fail-ure arises during the process execution. In [34] the au-thors describe how planning can be interleaved withprocess execution and plan refinement, and investigateplan patching and plan repair as means to enhance flex-ibility and responsiveness.

A goal-based approach for enabling automated pro-cess instance change in case of exceptions is shown

in [27]. If a task failure occurs at run-time and leads toa process goal violation, a multi-step procedure is acti-vated. It includes the termination of the failed task, thesound suspension of the process, the automatic gener-ation (through the use of a partial-order planner) of anew complete process definition that complies with theprocess goal and the adequate process resumption. Asimilar approach is proposed in [24]. The approach isbased on learning business activities as planning op-erators and feeding them to a planner that generatesa candidate process model that is able of achievingsome business goals. If an activity fails during processexecution at run-time, an alternative candidate plan isprovided on the same business goals. The major issueof [27,24] lies in the replanning stage used for adapt-ing a faulty process instance. In fact, it forces to com-pletely redefine the process specification at run-timewhen the process goal changes (due to some activityfailure), by completely revolutionizing the work-list oftasks assigned to the process participants (that are oftenhumans). On the contrary, our approach adapts a run-ning process instance by modifying only those parts ofthe process that need to be changed/adapted and keepsother parts stable.

The works [26] and [46] provide a formalization anda regression-based approach to identify when a givenplan, developed for an ultimate specified goal, does notwork anymore and replanning may be required. Suchworks adopt a traditional notion of plan, either sequen-tial [26] or partial-order [46]. Conversely, in SmartPMplans are seen as recovery processes and we do notassume the presence of pre-specified goals associatedto the main process under execution. This makes theregression-based approach of [26] and [46] not di-rectly applicable to our approach.

In the work [6] the authors propose a goal-driven ap-proach for service-based applications to automaticallyadapt business processes to run-time context changes.Process models include service annotations describinghow services contribute to the intended goal. Contex-tual properties are modeled as state transition systemscapturing possible values and evolutions in the case ofprecondition violations or external events. Process andcontext evolution are continuously monitored and con-text changes that prevent goal achievement are man-aged through an adaptation mechanism based on ser-vice composition via automated planning techniques.However, this work requires that the process designerexplicitly defines the policies for detecting the excep-tions at design-time, while in SmartPM the recoveryprocedure is synthesized at run-time, without the needto define any recovery policy at design-time.


A work dealing with process interference is that of[68]. Process interference is a situation that happenswhen several concurrent business processes depend-ing on some common data are executed in a highlydistributed environment. During the processes execu-tion, it may happen that some of these data are mod-ified causing unanticipated or wrong business out-comes. To overcome this limitation, the work [68]proposes a run-time mechanism which uses (i) De-pendency Scopes for identifying critical parts of theprocesses whose correct execution depends on someshared variables; and (ii) Intervention Processes forsolving the potential inconsistencies generated fromthe interference, which are automatically synthesisedthrough a domain independent planner based on CSPtechniques. While closely related to van Beest’s work,our account deals with changes in a more abstract anddomain-independent way, by just checking misalign-ment between expected/physical realities. Conversely,van Beest’s work requires specification of a (domain-dependent) adaptation policy, based on volatile vari-ables and when changes to them become relevant.

8. Concluding Remarks

We are at the beginning of a profound transfor-mation of BPM due to advances in AI and Cogni-tive Computing [33]. Cognitive systems offer compu-tational capabilities typically based on large amount ofdata, which provide cognition power that augment andscale human expertise. The aim of the emergent fieldof cognitive BPM is to offer the computational capa-bility of a cognitive system to provide analytical sup-port for processes over structured and unstructured in-formation sources. The target is to provide proactiv-ity and self-adaptation of the running processes againstthe evolving conditions of the application domains inwhich they are enacted.

In this direction, our paper has been devoted to de-fine a general approach, a concrete framework anda CPMS implementation, called SmartPM, for auto-mated adaptation of CPPs. Our purpose was to demon-strate that the combination of procedural and imper-ative models with cognitive BPM constructs such asdata-driven activities and declarative elements, alongwith the exploitation of techniques from the field ofAI such as situation calculus, IndiGolog and classicalplanning, can increase the ability of existing PMSs ofsupporting and adapting CPPs in case of unanticipatedexceptions.

Existing approaches dealing with unanticipated ex-ceptions typically rely on the involvement of processparticipants at run-time, so that authorized users are al-lowed to manually perform structural process modeladaptation and ad-hoc changes at the instance level.However, CPPs demand a more flexible approach rec-ognizing the fact that in real-world environments pro-cess models quickly become outdated and hence re-quire closer interweaving of modeling and execution.To this end, the adaptation mechanism provided bySmartPM is based on execution monitoring for detect-ing failures and context changes at run-time, withoutrequiring to predefine any specific adaptation policy orexception handler at design-time (as most of the cur-rent approaches do).

From a general perspective, our planning-based au-tomated exception handling approach should be con-sidered as complementary with respect to existingtechniques, acting as a “bridge” between approachesdealing with anticipated exceptions and approachesdealing with unanticipated exceptions. When an excep-tion is detected, the run-time engine may first checkthe availability of a predefined exception handler, andif no handler was defined it can rely on an automatedsynthesis of the recovery process. In the case that ourplanning-based approach fails in synthesizing a suit-able handler (or an handler is generated but its exe-cution does not solve the exception), other adaptationtechniques need to be used. For example, if the run-ning process provides a well-defined intended goal as-sociated to its execution, we could resort to the vanBeest’s work [68] and do planning from first-principleto achieve such a goal. Conversely, if no intended goalis associated to the process, a human participant can beinvolved, leaving her/him the task of manually adapt-ing the process instance.

We notice that the SmartPM approach is predicatedon two (strong) assumptions:

– postconditions or intended goals of programsare not explicitly available/specified. This comesfrom the traditional BPM domain where all thefocus is on the structure of the business process.While the process itself intends to achieve somegoal, this remains implicit and non-specified.Moreover, the process specified generally en-codes non-functional requirements that go beyondthe goal being achieved, which means that thegoal needs to be achieved by executing the pro-cess as specified (cf. [19]);


– the exogenous events are always considered as“dangerous”. This also comes from the BPM do-main, where what is expected is modeled in theprocess and everything else is considered “dan-gerous” (or erroneous). Of course, there exist realworld cases where an exogenous event could be“helpful” for the final goal.

However, the fact that the SmartPM approach relieson well founded KR&R formalisms opens the doorfor many advanced reasoning tasks upon failure andamounts to very promising future work, e.g., to as-sociate goals with processes and subprocesses andchecks that such goals are fulfilled, to exploit “help-ful” exogenous events that make smarter the synthe-sis of recovery procedures, or to investigate what partsof the process can not be repaired or abduce what hasgone wrong in the past, in order to assists the user inthe manual definition of the recovery plan.

Future work will include an extension of our ap-proach to “stress” the above assumptions and all thoseone imposed by the usage of automated classical plan-ning techniques for the synthesis of the recovery pro-cedure, which frame the scope of applicability of theapproach for addressing more expressive problems, in-cluding incomplete information, preferences and mul-tiple task effects.

We also notice that, even if the SmartPM approachis able to adapt a process instance at run-time, it doesnot allow either to support hierarchical processes or toevolve the original process model on the basis of ex-ceptions captured. Therefore, a second future directionof this work is to provide support for executing hier-archical processes, with high-level processes achiev-ing more general goals that can invoke simpler pro-cesses to achieve some of their subgoals. We arguethat agent-technology (for example, BDI [54], whichstands for “beliefe-desire-intensions”) and hierarchicalplanners [48] can provide promising approaches andmethods to address this challenge. In addition, a thirdmain future work concerns to avoid to consider all de-viations from the process as errors, but as a natural andvaluable part of the work activity, which provides theopportunity for learning and thus evolving the processmodel for future instantiations. Finally, a further in-teresting future work is to devise a set of design-timeguidelines that may help the process designer in choos-ing what fluents/abbreviations should be (or not be)monitored for misalignment.

The current implementation of SmartPM is devel-oped to be effectively used by process designers and

practitioners.9 Users define processes in the well-known BPMN language, enriched with semantic anno-tations for expressing properties of tasks, which allowour interpreter to derive the IndiGolog program repre-senting the process. Interfaces with human actors (suchas specific graphical user applications in Java) and soft-ware services (through Web service technologies) al-low the core system to be effectively used for enactingprocesses. Although the need to explicitly model pro-cess execution context and annotate tasks with precon-ditions and effects may require some extra modelingeffort at design-time (also considering that traditionalprocess modeling efforts are often mainly directed tothe sole control flow perspective), the overhead is com-pensated at run-time by the possibility of automatingexception handling procedures. While, in general, suchmodeling effort may seem significant, in practice it iscomparable to the effort needed to encode the adap-tation logic using alternative methodologies like hap-pens, for example, in rule-based approaches.

Acknowledgements

This work has been partly supported over theyears by the following projects: EU FP-6 WORK-PAD, EU FP-7 SM4All, Italian Sapienza grantsDAKIP, TESTMED and SUPER, Italian Sapienzaaward SPIRITLETS, Italian projects Social Museumand Smart Tourism (CTN01 00034 23154), NEP-TIS (PON03PE 00214 3), and RoMA - Resilence ofMetropolitan Areas (SCN 00064). The authors wouldlike to thanks the many persons involved over the yearsin the SmartPM conception and development, namelyGiuseppe De Giacomo, Massimiliano de Leoni, PatrisHalapuu, Arthur H.M. ter Hofstede, Alessandro Russo.

References

[1] M. J. Adams. Facilitating dynamic flexibility and exceptionhandling for workflows. PhD thesis, Queensland University ofTechnology Brisbane, Australia, 2007.

[2] V. Agarwal, G. Chafle, K. Dasgupta, N. M. Karnik, A. Kumar,S. Mittal, and B. Srivastava. Synthy: A system for end to endcomposition of web services. Journal on Web Semantics: Sci-ence, Services and Agents on the World Wide Web, 3(4):311–339, 2005.

9More information about the system is available at http://www.dis.uniroma1.it/˜smartpm


[3] C. Beckstein and J. Klausner. A Meta Level Architecture forWorkflow Management. Journal of Integrated Design and Pro-cess Science, 3(1):15–26, 1999.

[4] D. Berardi, D. Calvanese, G. De Giacomo, M. Lenzerini, andM. Mecella. Automatic Composition of E-services That ExportTheir Behavior. In Proceedings of the First International Con-ference on Service-Oriented Computing, ICSOC 2003, pages43–58. Springer, 2003.

[5] R. Brachman and H. Levesque. Knowledge Representation andReasoning. Elsevier, 2004.

[6] A. Bucchiarone, M. Pistore, H. Raik, and R. Kazhamiakin.Adaptation of service-based business processes by context-aware replanning. In Proceedings of the 4th InternationalConference on Service-Oriented Computing and Applications,SOCA 2011, pages 1–8. IEEE, 2011.

[7] F. Casati, S. Ceri, S. Paraboschi, and G. Pozzi. Specificationand implementation of exceptions in workflow managementsystems. ACM Transactions on Database Systems (TODS),24(3):405–451, 1999.

[8] F. Casati and G. Cugola. Error Handling in Process Sup-port Systems. In Advances in Exception Handling Techniques,pages 251–270. Springer-Verlag, 2001.

[9] S. Chand and J. Davis. What is smart manufacturing. TimeMagazine Wrapper, pages 28–33, 2010.

[10] D. K. W. Chiu, Q. Li, and K. Karlapalem. A Logical Frame-work for Exception Handling in ADOME Workflow Manage-ment System. In Proccedings of the 12th International Con-ference on Advanced Information Systems Engineering, CAiSE’00, pages 110–125. Springer-Verlag, 2000.

[11] J. Claßen, P. Eyerich, G. Lakemeyer, and B. Nebel. Towardsan Integration of Golog and Planning. In Proceedings of the20th International Joint Conference on Artificial Intelligence,IJCAI 2007, pages 1846–1851, 2007.

[12] J. Claßen, Y. Hu, and G. Lakemeyer. A Situation-CalculusSemantics for an Expressive Fragment of PDDL. In Pro-ceedings of the Twenty-Second Conference on Artificial Intelli-gence, AAAI-07, pages 956–961, 2007.

[13] F. Cossu, A. Marrella, M. Mecella, A. Russo, G. Bertazzoni,M. Suppa, and F. Grasso. Improving operational support in hos-pital wards through vocal interfaces and process-awareness. In25th Int. Symp. on Computer-Based Medical Systems (CBMS).IEEE, 2012.

[14] G. De Giacomo, Y. Lesperance, H. Levesque, and S. Sardina.IndiGolog: A High-Level Programming Language for Em-bedded Reasoning Agents. Multi-Agent Programming: Lan-guages, Tools and Applications, pages 31–72, 2009.

[15] G. De Giacomo, M. Mecella, and F. Patrizi. Automated ServiceComposition Based on Behaviors: The Roman Model. In WebServices Foundations, pages 189–214. Springer, 2014.

[16] G. De Giacomo, R. Reiter, and M. Soutchanski. ExecutionMonitoring of High-Level Robot Programs. In Proceedings ofthe Sixth International Conference on Principles of KnowledgeRepresentation and Reasoning, KR’98, pages 453–465, 1998.

[17] M. de Leoni, A. Marrella, and A. Russo. Process-aware infor-mation systems for emergency management. In European Con-ference on a Service-Based Internet, pages 50–58. Springer,2010.

[18] A. Dix, J. Finlay, G. Abowd, and R. Beale. Human-ComputerInteraction. Pearson, 2004.

[19] M. Dumas, M. La Rosa, J. Mendling, and H. A. Reijers. Fun-damentals of Business Process Management. Springer-VerlagBerlin Heidelberg, 1st edition, 2013.

[20] M. Dumas, W. M. van der Aalst, and A. H. ter Hofstede.Process-Aware Information Systems: Bridging People and Soft-ware through Process Technology. John Wiley & Sons, 1st edi-tion, 2005.

[21] S. Edelkamp and J. Hoffmann. PDDL2.2: The Language forthe Classical Part of the 4th International Planning Competi-tion. Technical report, Albert-Ludwigs-Universitat Freiburg,Institut fur Informatik, 2004.

[22] J. Eder and W. Liebhart. The Workflow Activity ModelWAMO. In Proceedings of the 3rd International Conferenceon Cooperative Information Systems, CoopIS-95, pages 87–98,1995.

[23] J. Eder and W. Liebhart. Workflow recovery. In Proceedings ofthe First IFCIS International Conference on Cooperative Infor-mation Systems, CoopIS’96, pages 124–134. IEEE ComputerSociety, 1996.

[24] H. M. Ferreira and D. R. Ferreira. An Integrated Life Cyclefor Workflow Management Based on Learning and Planning.International Journal on Cooperative Information Systems, 15,2006.

[25] C. Fritz, J. A. Baier, and S. A. McIlraith. ConGolog, Sin Trans:Compiling ConGolog into Basic Action Theories for Planningand Beyond. In Proceedings of the Eleventh International Con-ference on Principles of Knowledge Representation and Rea-soning, KR’08, pages 600–610, 2008.

[26] C. Fritz and S. A. McIlraith. Monitoring Plan Optimality Dur-ing Execution. In ICAPS, pages 144–151, 2007.

[27] M. Gajewski, H. Meyer, M. Momotko, H. Schuschel, andM. Weske. Dynamic Failure Recovery of Generated Work-flows. In Proceedings of the 16th International Workshopon Database and Expert Systems Applications, DEXA 2005,pages 982–986. IEEE Computer Society Press, 2005.

[28] H. Geffner and B. Bonet. A Concise Introduction to Modelsand Methods for Automated Planning. Morgan & ClaypoolPublishers, 2013.

[29] A. Gerevini, A. Saetti, I. Serina, and P. Toninelli. LPG-TD: aFully Automated Planner for PDDL2.2 Domains. In Proceed-ings of the 14th International Conference on Automated Plan-ning and Scheduling, ICAPS-04, 2004.

[30] D. Ghosh, R. Sharman, H. R. Rao, and S. J. Upadhyaya. Self-healing systems - survey and synthesis. Decision Support Sys-tems, 42(4):2164–2185, 2007.

[31] C. Hagen and G. Alonso. Exception handling in workflow man-agement systems. IEEE Transactions on Software Engineering,26(10):943–958, 2000.

[32] O. Hanteer, A. Marrella, M. Mecella, and T. Catarci. A petri-net based approach to measure the learnability of interactivesystems. In Proceedings of the International Working Confer-ence on Advanced Visual Interfaces, AVI 2016, Bari, Italy, June7-10, 2016, pages 312–313, 2016.

[33] R. Hull and H. R. Motahari Nezhad. Rethinking BPM in a cog-nitive world: Transforming how we learn and perform businessprocesses. In Business Process Management - 14th Interna-tional Conference, BPM 2016, Rio de Janeiro, Brazil, Septem-ber 18-22, 2016. Proceedings, volume 9850 of Lecture Notesin Computer Science, pages 3–19. Springer, 2016.


[34] P. Jarvis, J. Moore, J. S. , A. Macintosh, A. C. du Mont, andP. Chung. Exploiting AI Technologies to Realise AdaptiveWorkflow Systems. In Proceedings of the AAAI Workshop onAgent-Based Systems in the Business Context, 1999.

[35] W. D. Kingery. Introduction to ceramics. 1960.[36] M. Klein and C. Dellarocas. A Knowledge-based Approach

to Handling Exceptions in Workflow Systems. Computer Sup-ported Cooperative Work (CSCW), 9(3-4):399–412, 2000.

[37] A. Lanz, M. Reichert, and P. Dadam. Robust and Flexible ErrorHandling in the AristaFlow BPM Suite. In Information Sys-tems Evolution: CAiSE Forum 2010, pages 174–189. SpringerBerlin Heidelberg, 2011.

[38] H. Lasi, P. Fettke, H.-G. Kemper, T. Feld, and M. Hoffmann.Industry 4.0. Business & Information Systems Engineering,6(4):239–242, 2014.

[39] E. A. Lee. Cyber Physical Systems: Design Challenges. InProceedings of the 11th IEEE International Symposium on Ob-ject and Component-Oriented Real-Time Distributed Comput-ing, ISORC 2008, pages 363–369. IEEE, 2008.

[40] B. S. Lerner, S. Christov, L. J. Osterweil, R. Bendraou, U. Kan-nengiesser, and A. Wise. Exception Handling Patterns for Pro-cess Modeling. IEEE Transactions on Software Engineering,36(2):162–183, 2010.

[41] Z. Luo, A. Sheth, K. Kochut, and J. Miller. Exception Han-dling in Workflow Systems. Applied Intelligence, 13(2):125–147, 2000.

[42] A. Marrella, M. Mecella, and S. Sardina. SmartPM: An Adap-tive Process Management System through Situation Calculus,IndiGolog, and Classical Planning. In Proceedings of the 14thInternational Conference on Principles of Knowledge Repre-sentation and Reasoning, KR’14, 2014.

[43] D. McDermott, M. Ghallab, A. Howe, C. Knoblock, A. Ram,M. Veloso, D. Weld, and D. Wilkins. PDDL - The PlanningDomain Definition Language. Technical report, 1998.

[44] S. A. McIlraith and T. C. Son. Adapting golog for compositionof semantic web services. In Proceedings of the Eights Inter-national Conference on Principles and Knowledge Represen-tation and Reasoning (KR-02), Toulouse, France, April 22-25,2002, pages 482–496, 2002.

[45] M. Minor, R. Bergmann, and S. Gorg. Case-based adaptationof workflows. Information Systems, 40:142–152, 2014.

[46] C. Muise, S. A. McIlraith, and J. C. Beck. Monitoring theexecution of partial-order plans via regression. In IJCAIProceedings-International Joint Conference on Artificial Intel-ligence, volume 22, 2011.

[47] R. Muller, U. Greiner, and E. Rahm. AGENT WORK: AWorkflow System Supporting Rule-based Workflow Adapta-tion. Data & Knowledge Engineering, 51(2):223–256, Nov.2004.

[48] D. Nau, T.-C. Au, O. Ilghami, U. Kuter, W. Murdock, D. Wu,and F. Yaman. Shop2: An htn planning system. Journal ofArtificial Intelligence Research(JAIR), 20:379–404, 2003.

[49] D. Nau, M. Ghallab, and P. Traverso. Automated Planning:Theory & Practice. Morgan Kaufmann Publishers Inc., SanFrancisco, CA, USA, 2004.

[50] M. Pistore, P. Traverso, P. Bertoli, and A. Marconi. AutomatedSynthesis of Composite BPEL4WS Web Services. In Pro-ceedings of the 2005 IEEE International Conference on WebServices, ICWS’05, pages 293–301. IEEE Computer Society,2005.

[51] M. Pistore, P. Traverso, P. Bertoli, and A. Marconi. Auto-mated synthesis of executable web service compositions fromBPEL4WS processes. In Proceedings of the 14th InternationalConference on World Wide Web, WWW 2005, pages 1186–1187. ACM, 2005.

[52] H. Psaier and S. Dustdar. A survey on self-healing systems:approaches and systems. Computing, 91(1):43–73, 2011.

[53] R. R. Rajkumar, I. Lee, L. Sha, and J. Stankovic. Cyber-Physical Systems: The Next Computing Revolution. In Pro-ceedings of the 47th Design Automation Conference, DAC2010, pages 731–736. IEEE, 2010.

[54] A. S. Rao and M. P. Georgeff. BDI Agents: From Theory toPractice. In Proceedings of the First International Conferenceon Multiagent Systems, ICMAS 95, pages 312–319, 1995.

[55] M. Reichert and P. Dadam. ADEPTflex – Supporting DynamicChanges of Workflows Without Losing Control. Journal ofIntelligent Information Systems, 10(2):93–129, 1998.

[56] M. Reichert, S. Rinderle, and P. Dadam. ADEPT WorkflowManagement System. In Proceedings of the 1st InternationalConference on Business Process Management, BPM 2003,pages 370–379. Springer Berlin Heidelberg, 2003.

[57] M. Reichert, S. Rinderle, U. Kreher, and P. Dadam. AdaptiveProcess Management with ADEPT2. In Proceedings of the21st International Conference on Data Engineering, ICDE ’05,pages 1113–1114, 2005.

[58] M. Reichert and B. Weber. Enabling Flexibility in Process-Aware Information Systems - Challenges, Methods, Technolo-gies. Springer Berlin Heidelberg, 2012.

[59] H. Reichgelt. Knowledge Representation: An AI perspective.Greenwood Publishing Group Inc., 1991.

[60] R. Reiter. Knowledge in Action: Logical Foundations for Spec-ifying and Implementing Dynamical Systems. MIT Press, 2001.

[61] S. Rinderle, M. Reichert, and P. Dadam. Correctness Criteriafor Dynamic Changes in Workflow Systems: A Survey. Data& Knowledge Engineering, 50(1):9–34, 2004.

[62] S. Rinderle, B. Weber, M. Reichert, and W. Wild. IntegratingProcess Learning and Process Evolution – A Semantics BasedApproach. In Proccedings of the Third International Con-ference on Business Process Management, BPM 2005, pages252–267. Springer Berlin Heidelberg, 2005.

[63] N. Russell, W. M. van der Aalst, and A. H. ter Hofstede. Work-flow exception patterns. In Proceedings of the 18th Interna-tional Conference on Advanced Information Systems Engineer-ing, CAiSE 2006, pages 288–302. Springer Berlin Heidelberg,2006.

[64] R. Seiger, C. Keller, F. Niebling, and T. Schlegel. Modellingcomplex and flexible processes for smart cyber-physical envi-ronments. Journal of Computational Science, pages 137–148,2014.

[65] B. Selman, H. A. Kautz, and B. Cohen. Noise strategies forimproving local search. In Proceedings of the Twelfth In-ternational Conference on Artificial intelligence, AAAI ’94,pages 337–343. American Association for Artificial Intelli-gence, 1994.

[66] S. Sohrabi and S. A. McIlraith. Preference-based web servicecomposition: A middle ground between execution and search.In The Semantic Web - ISWC 2010 - 9th International Seman-tic Web Conference, ISWC 2010, Shanghai, China, November7-11, 2010, Revised Selected Papers, Part I, pages 713–729,2010.


[67] A. H. ter Hofstede, W. M. van der Aalst, M. Adams, andN. Russell. Modern Business Process Automation: YAWL andits Support Environment. Springer, 2009.

[68] N. R. van Beest, E. Kaldeli, P. Bulanov, J. C. Wortmann, andA. Lazovik. Automated runtime repair of business processes.Information Systems, 39:45–79, 2014.

[69] T. H. Van De Belt, L. J. Engelen, S. A. Berben, andL. Schoonhoven. Definition of Health 2.0 and Medicine 2.0: asystematic review. Journal of medical Internet research, 12(2),2010.

[70] W. M. van der Aalst, A. H. ter Hofstede, B. Kiepuszewski,and A. P. Barros. Workflow Patterns. Distributed ParallelDatabases, 14(1), 2003.

[71] B. Weber, M. Reichert, and S. Rinderle. Change Patterns andChange Support Features - Enhancing Flexibility in Process-aware Information Systems. Data & knowledge engineering,66(3):438–466, 2008.

[72] B. Weber, W. Wild, and R. Breu. CBRFlow: Enabling AdaptiveWorkflow Management Through Conversational Case-BasedReasoning. ECCBR 2004. Springer Berlin Heidelberg, 2004.

[73] M. Weske. Formal foundation and conceptual design of dy-namic adaptations in a workflow management system. In Pro-ceedings of the 34th Annual Hawaii International Conferenceon System Sciences, HICSS 2001. IEEE, 2001.

[74] D. E. Wilkins. Practical planning: extending the classical AIplanning paradigm. Morgan Kaufmann, 1988.

supporting adaptiveness of cyber-physical processes through … · 2019-03-19 · processes through...

Documents