ADAPTIVE WORKFLOWS FOR SMART DEVICES

A Concrete Approach Towards Device Failures

Seng Loke

Department of Computer Science and Computer Engineering, La Trobe University, Australia

Sea Ling, Maria Indrawan, Suryani Kurniati

Faculty of Information Technology, Monash University, Australia

Keywords:

Pervasive systems, smart devices, adaptive workﬂow, device failures.

Abstract:

Smart devices in an environment (e.g., home, factory, military settings, in-vehicle, ofﬁce, etc) can be pro-

grammed and coordinated by a workﬂow in advance to achieve a user’s goal. No matter how advanced or

smart the devices are, devices can fail during workﬂow execution. In this paper, we describe an approach

to remedy such situations. We apply the existing concept of adaptive workﬂow management to a collection

of devices, called a device ecology. Information about the devices are kept in a device hierarchy so that a

suitable substitute device that can perform a similar task can be retrieved to replace a failed device in order to

ensure the workﬂow can continue execution. Similarity is deﬁned based on a device hierarchy in an ontology

language. A prototype has been implemented as proof of concept.

1 INTRODUCTION

Technology developments in the past decade have re-

sulted in “less for more”, intelligent devices. Com-

puters are built small enough and smart enough to be

embedded into devices and human daily appliances,

creating intelligent devices. Smart device or intelli-

gent device is “any type of equipment, instrument,

or machine that has its own computing capability”

(SearchExchange.com, 2006).

There has been signiﬁcant work in building the

networking and integrative infrastructure for such de-

vices, within the home, the ofﬁce, and other en-

vironments and linking them to the global Inter-

net. For example, UPnP (UPnP Forum, 2000),

SIDRAH (Durand et al., 2003) and Jini (Sun Mi-

crosystems, 2001) provide infrastructure for devices

to be inter-connected, ﬁnd each other, and utilize each

other’s capabilities. Embedded Web Servers (Ben-

tham, 2002) are able to expose the functionality of de-

vices as Web services. Approaches to modelling and

programming such devices for the home have been in-

vestigated, where devices have been modelled as soft-

ware components, collections of objects (Association

of Home Appliance Manufacturers, 2002), and Web

services (Matsuura et al., 2003).

Previous work (Loke, 2003; Loke et al., 2005)

provides a high-level device aggregation framework,

adopting service-oriented computing and business

process management in the form of device ecologies.

A device ecology is deﬁned as an environment con-

sisting of collections of devices interacting synergis-

tically with one another, with users, and with Inter-

net resources, undergirded by appropriate software

and communication infrastructures that range from

Internet-scale to very short range wireless networks

(Loke, 2003). To program these devices, we make

individual web service calls to these devices which

are coordinated by a workﬂow in BPEL4WS. A cen-

tral coordinator called device ecology workﬂow (de-

coﬂow) engine exists as the ”brain” of the group of de-

vices in this environment. Therefore, device ecology

is characterised by the idea of service-oriented com-

puting and workﬂow in a high-level device aggrega-

tion framework, which perceives devices as orches-

trated web services taking part in a service-oriented

workﬂow. Such coordinated execution of devices and

Internet services (including appliances, and embed-

ded processors and computers) have widepsread uses

in the home, factories, military environments, ofﬁce

environments, within cars, etc, wherever there is a

need for a collection of devices (hardware and soft-

191

Loke S., Ling S., Indrawan M. and Kurniati S. (2007).

ADAPTIVE WORKFLOWS FOR SMART DEVICES - A Concrete Approach Towards Device Failures.

In Proceedings of the Ninth International Conference on Enterprise Information Systems - SAIC, pages 191-197

DOI: 10.5220/0002368901910197

 SciTePress

ware) and Internet resources to work together to fulﬁll

a common user programmed task (e.g., in response to

the task of cooking a recent dish talked about in a pop-

ular TV program such as the IronChef, suitable Web

services are consulted to download the recipe and the

fridge is consulted to determine if suitable ingredients

are available before the appropriate kitchen utensils

are prepared and instructions displayed on suitable

devices for the user to take action and to take the user

through the whole cooking process, including setting

up suitable timings and alarms on appliances, in a co-

ordinated workﬂow manner).

No matter how advanced or smart the devices are,

dynamic changes can occur during workﬂow execu-

tion. A device is prone to faults and failures. Several

realistic examples will be: accidental loss of electric-

ity, electrical spike or surge, thrown exceptions in task

failures, and loss of network connection. When one

of these changes occur, decoﬂow execution will be

affected. It will be halted or will totally fail, becom-

ing inexecutable. Although changes like these can be

resolved by manual effort, it is inefﬁcient and cumber-

some. As quoted from (Aalst, 2001), no matter how

temporary or permanent changes are, workﬂow has to

be able to support it by typically executing a “more or

less idealised version of the preferred process”, as an

effort to achieve the original objective. In Workﬂow

Management Systems, such effort is captured in the

concept of the adaptive workﬂow.

Overall the aims of this project are two-fold:

1. applying existing concepts of adaptive workﬂow

management to a collection of devices in a device

ecology, in particular to remedy situations of de-

vice failure; and

2. providing a basis, for future research by investi-

gating how device failures could be handled.

In this paper, we will report on the resulting

concepts and algorithms for adaptive device ecology

workﬂows that can still execute effectively despite de-

vice failures occurring during execution. Section 2

contains an overview of device ecology and the im-

pact of task dependencies towards providing adequate

workﬂow ﬂexibility. Section 3 explains the hierarchy

of devices used in our solution. This is followed by

a description of the remedy algorithm in section 4.

Section 5 describes our prototype implementation as

a proof of concept and section 6 is the conclusion.

2 WORKFLOW AND TASK

DEPENDENCIES

Workﬂows exist in areas from business management,

information system to computing in general. A work-

ﬂow consists of an arrangement of activities and tasks

to achieve a business objective. It is a business pro-

cess comprising operational logics for the coordina-

tion of resources, independent units that have the ca-

pability to perform speciﬁc tasks (Piccinelli et al.,

2004). The term resources include entities that act

autonomously and upon request, depending on its co-

ordination. Resources can take the form of devices,

applications and, most signiﬁcantly, web services.

In general, there are two types of workﬂow co-

ordination logic, orchestrated and choreographed. In

an orchestrated environment, a single local entity is

in charge of maintaining the state of the process, and

to request the resources to perform tasks (Piccinelli

et al., 2004). In a choreographed workﬂow, no cen-

tral entity organises order and request services. In-

teraction occurs between entities dynamically. It usu-

ally occurs in web service based workﬂows as in a

BPEL4WS speciﬁed workﬂow.

BPEL4WS (Microsoft et al., 2003) was devel-

oped to become the speciﬁcation language to support

the implementation of business processes with web

services. It was designed to support business pro-

cess speciﬁc issues like, the potential execution order

of operations from a collection of web services, the

data shared between these web services, which part-

ners are involved, joint exception handling for collec-

tions of web services and issues involving how mul-

tiple services and organisations participate (Leymann

et al., 2002). These capabilities are reﬂected in the

BPEL4WS speciﬁcation using XML-based tags like

<reply>

, etc. BPEL4WS has

to adopt, comply and able to make use of Web service

speciﬁc standards like Universal Discovery Descrip-

tion and Integration (UDDI), Web Service Descrip-

tion Language (WSDL) and Simple Object Access

Protocol (SOAP).

Our work attempts to develop a framework to al-

low users to program devices in terms of workﬂow

using a suitable programming language undergirded

by a formal model. At the highest level, we have

developed Eco, an English-like interaction language,

consisting of a collection of abbreviated commands to

make end-user workﬂow programming simpler. This

is mapped down to the lower-language BPEL4WS

which is executed by the workﬂow engine that con-

trols the devices. Figure 1 depicts the conceptual ar-

chitecture of our framework.

Two decoﬂow scenarios in a smart home environ-

ICEIS 2007 - International Conference on Enterprise Information Systems

192

Figure 1: Multilayered Conceptual Architecture for Device

Ecology Workﬂow Engine.

ment are provided in Figure 2 and Figure 3. Following

the dashed arrows which depict the ﬂow of workﬂow

execution and ignoring the dark arrows, we describe

the scenarios as follows:

Wake-Up Scenario: Decoﬂow execution starts upon

receiving a bed alarm clock notice, signifying the be-

ginning of the wake up decoﬂow. A sequence of ac-

tivities starts right after. The next activity initiated is

switching on television. After television has success-

fully changed its state, the following activities take

place concurrently: mute television; display favourite

channel on television and, switch on bedroom lights.

Following the muting of television, the volume is then

increased. Once the television is set, and two other

activities have successfully completed, a message of

decoﬂow completion is displayed in a control panel.

Morning Kitchen Scenario: This scenario takes

place in the kitchen area. It starts by receiving a user

response on the alarm clock (setting the alarm to the

off state). This is then followed by three concurrent

activities: activating coffee maker; activating kitchen

hall sensors and, retrieving ’to do’ list from the PDA.

After the kitchen hall sensors state turns to active,

kitchen lights are switched on. After retrieving ’to

do’ list on the PDA, the list is displayed on the refrig-

erator monitor, to remind user of his/her duties for the

day.

3 TASK DEPENDENCIES IN

DECOFLOW

The dependency between tasks has an impact towards

providing adequate workﬂow ﬂexibility. Currently,

most task dependency studies focus on task primitives

and operations, particularly in the ﬁeld of database

management. Generalised views of dependency mod-

Figure 2: Wake Up Scenario.

els has been reviewed to provide a background.

Kim (Kim, 2003) categorised workﬂow depen-

dency into three different models: procedure-driven

model; dependency-driven model and condition-

driven model, while in (Ray et al., 2004; Zhu et al.,

2005), task dependencies are classiﬁed based on task

primitives (task’s execution states: begin, abort, com-

mit), task operations and task input/outputs perspec-

tives, which resulted in three different types of de-

pendencies: control-ﬂow dependencies, data-ﬂow de-

pendencies and read-write dependency. Control-ﬂow

dependencies and read-write dependencies focus on

task internal mechanism, particularly dependencies

from one task’s state to another in the same workﬂow.

Hence, these dependencies do not apply to task de-

pendencies for devices in our work. However, data-

ﬂow dependencies is applicable.

A task T1 produces an output x that will be used as

the input to another task, say T2. Hence, the ability to

execute T2 depends on the success of executing T1.

If T1 and T2 are tasks performed by the same device,

their relationship is considered as same device task

dependency. The dark arrows in Figure 2 depict same

device task dependencies, e.g. turning up TV volume

depends on the successful execution of switching on

the TV ﬁrst.

The dark arrow in Figure 3 shows a different de-

vice task dependency relationship. PDA and refriger-

ator monitor are two different devices but they share

the same data - the “to do” list.

To provide adaptiveness towards device failures in

the above scenarios, the decoﬂow engine which ex-

ecutes the workﬂow needs to be aware of the device

description, the types of failure and the available re-

covery techniques. Intuitively, when a task or a de-

vice is going to fail, a substitute or replacement needs

to be found. A listing of the device and its descrip-

tion is maintained through a device hierarchy. Figure

4 shows how devices are modelled as object-oriented

ADAPTIVE WORKFLOWS FOR SMART DEVICES - A Concrete Approach Towards Device Failures

193

Figure 4: Device Hierarchy.

Figure 3: Morning Kitchen Scenario.

abstract and concrete classes in such a hierarchy.

A device can also be seen as a collection of atomic

devices where appropriate. Although inspired by

UPnP MediaRenderer (Intel Research & Develop-

ment, 2003) which viewed device aggregation at low-

level framework, the hierarchy also represents a high-

level view of devices with the focus on tasks and sub-

tasks. For example, in the hierarchy, television con-

sists of the components: a monitor, a TV tuner and a

pair of speakers. The composite task

switch on TV

means switching on the three component devices, i.e.,

a composition of three subtasks (child tasks)

switch

on monitor

switch on TV tuner

and

switch on

speakers

. The composite task and its component

(atomic) tasks are shown in the task hierarchy in Fig-

ure 5.

Figure 5: Composite Tasks of a Composite Device.

4 REMEDYING

DEVICE-ORIENTED TASK

FAILURES

Previous works on task failures in workﬂows (Aalst

et al., 1999; Aalst and Jablonski, 2000; Ellis and Ked-

dara, 2000; Elder and Liebhart, 1996) have provided

ideas on how to resolve device-oriented task failures

in decoﬂow. While some works (Aalst et al., 1999;

Aalst and Jablonski, 2000; Ellis and Keddara, 2000)

generalise failures as process change including work-

ﬂow changes as a result of handling modiﬁcations,

other works (Elder and Liebhart, 1996), upon de-

tecting a task failure, propose a recovery mechanism

which includes a combination of forward execution

and backward recovery. Forward execution is a deci-

ICEIS 2007 - International Conference on Enterprise Information Systems

194

sion to ignore failed task and proceed to the next task.

This can only be carried out if failed task has no vital

relationship (i.e., no dependencies) with other tasks,

especially for consistency measures (Elder and Lieb-

hart, 1996). Backward recovery involves effort to roll

back the whole workﬂow, undoing successful termi-

nated tasks, which in the end resulted in unsuccess-

ful execution of the workﬂow as a whole. Hence, we

adopt a combination of forward execution and back-

ward recovery. When a potential failure is detected,

this means to proceed to the following tasks where no

consistency measures need to be satisﬁed and undo

tasks that have vital relationships.

By applying the above mechanism to device ecol-

ogy, the steps for forward recovery by the decoﬂow

engine are:

1. To eliminate previous successfully terminated

tasks that utilises the same failed device;

2. To substitute the failed device with a working de-

vice, available for the job (not utilised by other

decoﬂow executing in the same time frame) and

capable of executing the task;

3. To make necessary changes towards the following

tasks that use the same device and other tasks that

has consistency measures (dependency) with the

changed and rolled back tasks.

4. If no substitute device found, skip the task and

move on.

We categorised device failures into two types: to-

tal device failure and partial device failure. Depend-

ing on the type of failed device, single device can only

result in total failure whilst composite device may re-

sult in either partial or total failure.

Total Device Failure. This type of failure exists when

all device components of a single device instance are

unable to carry out any function. For the case of

atomic device (with no components), it can only ex-

hibit this type of failure. Ultimately these are device

instances whose classes reside on the top level of the

concrete part of device hierarchy in Figure 4. They

include devices such as lights, sensor, printer, moni-

tor and speaker. In a composite device situation, total

device failure can only occur when all device compo-

nent instances refuse to function.

Partial Device Failure. Partial device failure occurs

when a device is able to execute only some of its

listed operations while the rest are not executable due

to some fault. An example will be failed television’s

tuner while television’s monitor and speakers are still

functioning. This type of failure can only affect com-

posite devices.

By considering the type of device failure, the num-

ber of tasks affected in decoﬂow, the dependencies

between them and the number of component devices

affected (if any), we have developed an algorithm to

recover from failures. Essentially, before executing

the algorithm, a device failure status needs to be deter-

mined. This is done by a

checkDeviceStatus

pro-

cedure, initiated just before the task is executed, (in

sequence), or before a series of tasks is executed con-

currently, (in ﬂows).

The purpose of the algorithm is to look for a sub-

stitute device or a combination of devices for a failed

device in a failed task, if any. In summary, the algo-

rithm consists of the following steps:

1. Identify device failure type (total or partial).

2. Identify task failure (single or composite).

3. Get all available substitute device.

4. Obtain the best substitute devices. The criteria of

selection is based on the number of tasks its com-

ponent devices can cover.

5. Replace executable task, either single or compos-

ite.

6. Replace prior tasks that use the same failed de-

vice.

7. Replace following tasks that use the same failed

device.

5 DECOFLOW ENGINE

IMPLEMENTATION

In our previous work, we have developed an engine

which accepts a decoﬂow speciﬁcation in BPEL4WS

and simulates the execution of the speciﬁcation. An

execution manager reads the necessary tasks to form

a decoﬂow execution script, based on the task’s script

template whilst a graph manager forms the graphical

representation of the process elements derived from

the decoﬂow analysis by the engine.

We extend the decoﬂow engine to facilitate adap-

tiveness towards device failures. Hence, to implement

the algorithm described in the previous section, the

engine needs to incorporate the following functional-

ities: failure detection, task manipulation, decoﬂow

manipulation and device recording and tasks conﬁgu-

ration. The extension is shown in Figure 6. It accepts

Deco Hierarchy as an additional input to keep track

of devices that exist in the ecology as well as the va-

riety of tasks that the devices can perform. It consists

of the device hierarchy and the task hierarchy, men-

tioned previously.

The engine itself consists of:

ADAPTIVE WORKFLOWS FOR SMART DEVICES - A Concrete Approach Towards Device Failures

195

Figure 7: Deco Hierarchy Snapshot.

Figure 6: Decoﬂow Engine.

• Execution Manager. The manager checks tasks

for their abilities to execute. If a device is not ca-

pable of carrying out the designated task, the re-

covery algorithm is called.

• Task Manager. This entity deals with failure

ﬁrsthand. Once a task is detected as incapable

of execution, the task needs to be manipulated

in accordance with the best possible resolution

suggested by recovery algorithm. Speciﬁcally,

the task manager alters the decoﬂow executable

script, not the original decoﬂow speciﬁcation in

BPEL4WS (Loke et al., 2005).

• Device Manager. Its main function is to ﬁnd

a substitute device, using the device hierarchy

through the device hierarchy manager. The de-

vice manager queries and searches the device hi-

erarchy, for failed device substitutes. Similar to

the task manager, the device manager is designed

to support proposed failure recovery.

• Device Hierarchy Manager. This serves as the

interface between the device hierarchy and the de-

coﬂow engine. Its main function is to query the hi-

erarchy. It relies heavily on the structural design

of the device hierarchy in carrying out its activi-

ties.

As proof of concept, a prototype for the engine

was developed in Java with the deco hierarchy de-

ﬁned by the Web Ontology Language OWL. Access

to the hierarchy from the engine is provided by Jena

(Seaborne, 2004) utilising RDQL (RDF Data Query

Language) for the query statements. A snapshot of

the deco hierarchy using Prot

e and OWL Viz plug-

in is shown in Figure 7. The prototype has been tested

using various workﬂow scenarios on device failures.

6 CONCLUSION

Pervasive systems have seen intelligent devices com-

municating and interacting with one another. Our

work attempts to develop a framework to program

these devices in terms of workﬂow which is called a

device ecology workﬂow. Problems set in when one

ICEIS 2007 - International Conference on Enterprise Information Systems

196

or more devices fail. We have described an approach

by which we can remedy such situations by searching

for substitute devices before the workﬂow is being ex-

ecuted.

While other work exists in modelling, develop-

ing and conﬁguring smart home systems (Norbisrath

et al., 2006), our work focuses on the workﬂow execu-

tion and control of these devices and providing a con-

crete solution to remedy device failures by adopting

existing concepts in the literature on adaptive work-

ﬂows.

REFERENCES

Aalst, W. (2001). Exterminating the dynamic change bug:

A concrete approach to support workﬂow change.

3(3):297–317.

Aalst, W., Basten, T., Verbeek, H., Verkoulen, P., and

Voorhoeve, M. (1999). Adaptive workﬂow: On the

interplay between ﬂexibility and support. In Proc. 1st

Int’l conference on Enterprise Information Systems,

Vol 2, pages 353–60.

Aalst, W. and Jablonski, S. (2000). Dealing with workﬂow

change: Identiﬁcation of issues and solutions. Int’l

Journal of Computer Systems Science and Engineer-

ing, 15(5):267–76.

Association of Home Appliance Manufacturers (2002).

Connected Home Appliances Object Modelling, CHA-

1-2002. Available at http://www.aham.org/.

Bentham, J. (2002). TCP/IP Lean: Web Servers for Embed-

ded Systems (2nd Edition). CMP Books.

Durand, Y., Vincent, S., Marchand, C., Ottogalli, F., Olive,

V., Martin, S., Dumant, B., and Chambon, S. (2003).

SIDRAH: A Software Infrastructure for a Resilient

Community of Wireless Devices. In Proceedings of

the Smart Objects Conference (SOC’03), Grenoble.

Elder, J. and Liebhart, W. (1996). Workﬂow recovery. In

Proc. 1st IFCIS Int’l Conference on Cooperative In-

formation Systems, pages 124–34.

Ellis, C. A. and Keddara, K. (2000). A workﬂow change is a

workﬂow. In Business Process Management: Models,

Techniques and Empirical Studies, pages 201–17.

Intel Research & Development (2003). Designing a

UPnP AV MediaRenderer. Available at http://cache-

www.intel.com/cd/00/00/21/87/218761

218761.pdf,

accessed on 30 Nov 2006.

Kim, K. (2003). Workﬂow dependency analysis and its

implications on distributed workﬂow systems. In

Proceedings of the 17th Intenational Conference on

Advanced Information Networking and Applications

(AINA’03).

Leymann, F., , and Roller, D. (2002). Business Processes in

a Web Services World, IBM developerWorks.

Loke, S. (2003). Service-Oriented Device Ecology Work-

ﬂows. In Orlowska, M., Weerawarana, S., Papa-

zoglou, M., and Yang, J., editors, Proceedings of the

International Conference on Service-Oriented Com-

puting, Lecture Notes in Computer Science 2910,

pages 559–574, Trento, Italy. Springer-Verlag.

Loke, S., Ling, S., Butler, G., and Gillick, B. (2005). Levels

of abstraction in programming device ecology work-

ﬂows. In Proceedings 7th International Conference

on Enterprise Information Sytems (ICEIS2005), pages

137–44, Miami, USA.

Matsuura, K., Haraa, T., Watanabe, A., and Nakajima, T.

(2003). A New Architecture for Home Computing. In

Proceedings of the IEEE Workshop on Software Tech-

nologies for Future Embedded Systems (WSTFES03),

pages 71–74.

Microsoft, IBM, Siebel, BEA, and SAP (2003). Business

Process Execution Language for Web Services Version

1.1. Available at http://www-106.ibm.com/

developerworks/library/ws-bpel/.

Norbisrath, U., Armac, I., Retkowitz, D., and Salumaa, P.

(2006). Modeling eHome systems. In Proc. 4th Int’l

Workshop on Middleware for Pervasive and Ad-Hoc

Computing (MPAC 2006).

Piccinelli, G., Finkelstein, A., and Williams, S. (2004).

Service-oriented workﬂow: The dysco framework.

In Proceedings of the 29th EUROMICRO conference

(New Waves in System Architecture), pages 291–7.

Ray, I., Xin, T., and Zhu, Y. (2004). Ensuring task depen-

dencies during workﬂow recovery. In Proc. 15th Int’l

Conference on Database and Expert Systems (DEXA

2004), pages 24–33.

Seaborne, A. (2004). Jena tutorial: A program-

mer’s introduction to rdql. Available at

http://jena.sourceforge.net/tutorial/RDQL/, accessed

on 14th November 2006.

SearchExchange.com (2006). Deﬁnition of in-

telligent devices. Available at Whatis.com -

http://whatis.techtarget.com/deﬁnition/

0,,sid9

gci812508,00.html,accessed on 10 Oct 2006.

Sun Microsystems (2001). Jini Network Technology. Avail-

able at http://wwws.sun.com/software/jini/.

UPnP Forum (2000). UPnP Device Architecture. Available

at http://www.upnp.org/.

Zhu, Y., Xin, T., and Ray, I. (2005). Recovering from mali-

cious attacks in workﬂow systems. In Proc. 16th Int’l

Conference on Database and Expert Systems (DEXA

2005).

ADAPTIVE WORKFLOWS FOR SMART DEVICES - A Concrete Approach Towards Device Failures

197