ANALYZING OBSERVABLE BEHAVIOURS OF

DEVICE ECOLOGY WORKFLOWS

Seng W. Loke and Sea Ling

School of Computer Science and Software Engineering

Monash University, Caulﬁeld East, VIC 3145, Australia

Keywords:

Device ecology, workﬂow, Petri net modelling, analysis.

Abstract:

We envision an Internet computational platform of the 21st century that will include device ecologies con-

sisting of collections of devices interacting synergistically with one another, with users, and with Internet

resources. We consider device ecology workﬂows as a type of workﬂow describing how such devices work

together. It would be ideal if one can model the devices in a computer and analyze the effects when such

workﬂows are executed in the device ecology. This paper provides a Petri Net model in terms of workﬂow

nets for analyzing the observable effects of device ecology workﬂows.

1 INTRODUCTION

A new era of Internet Computing is emerging where

not just every person has the potential of being net-

worked with every other person but even devices and

things might be networked. New devices and things

are emerging that will be capable of interacting mean-

ingfully, exhibiting smart behaviour. Such smart de-

vices will need to work effectively with each other

and with Web services. The devices might interact

across the living room or across nations in order to

fulﬁll the goals of users. The American Heritage

Dictionary deﬁnes the word “ecology” as “the rela-

tionship between organisms and their environment.”

We envision a computing platform of the 21st cen-

tury that takes the form of device ecologies consist-

ing of collections of devices (in the environment and

on users) interacting synergistically with one another,

with users, and with Internet resources, undergirded

by appropriate software and communication infras-

tructures that range from Internet-scale to very short

range wireless networks. These devices will perform

tasks and work together perhaps autonomously but

will need to interact with the user from time to time.

There has been signiﬁcant work in building the net-

working and integrative infrastructure for such de-

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

ments and linking them to the global Internet. For

example, AutoHan (Saif et al., 2001), UPnP (Cor-

poration, 2002), OSGI (Marples and Kriens, 2001),

Jini (Waldo, 1999), and SIDRAH (with short range

networking and failure detection) (Durand et al.,

2003) deﬁne infrastructure and mechanisms at differ-

ent levels (from networking to services) 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

devices as Web services. Embedding micro-servers

into physical objects is considered in (Nakajima,

2003). Approaches to modelling and programming

such devices for the home have been investigated,

where devices have been modelled as software com-

ponents (Jahnke et al., 2002), as collections of ob-

jects (AHAM, 2002), as Web services (Matsuura

et al., 2003), and as agents (Ramparany et al., 2003;

Carabelea and O.Boissier, 2003). However, there has

been little work on specifying at a high level of ab-

straction (and representing this speciﬁcation explic-

itly) how such devices would work together at the

user-task or application level, and how such work can

be managed.

Our earlier work (Loke, 2003) explored the work-

ﬂow (which we call device ecology workﬂows) as a

metaphor for thinking about how collections of these

devices (or devices in a device ecology) can work to-

gether to accomplish a purpose. It would be ideal if

one can model (and simulate aspects of) the devices

in a computer and analyze the effects when workﬂows

are executed in the device ecology. Such analysis is

useful in order to predict the effects of workﬂows be-

W. Loke S. and Ling S. (2004).

ANALYZING OBSERVABLE BEHAVIOURS OF DEVICE ECOLOGY WORKFLOWS.

In Proceedings of the Sixth International Conference on Enterprise Information Systems, pages 78-83

DOI: 10.5220/0002625800780083

 SciTePress

fore they are actually executed (e.g., to see if too much

resources will be used or undesirable effects will oc-

cur) which will then feedback into the design of the

workﬂow. In order to predict the behaviours of these

workﬂows, we might require detailed knowledge of

the device. Realistically, we can only assume some

knowledge about the device such as some of their ob-

servable properties. Our more recent work (Loke,

2004) provided a formalization of what it means to

say that the behaviour of devices and device ecology

workﬂows are predictable: the behaviour of a device

ecology workﬂow is predictable if the behaviour of

the individual devices are predictable, and the more

predictable each device is, the more predictable the

device ecology workﬂow will be - our formaliza-

tion tells us precisely how much more predictable the

workﬂow will be. However, we have not considered

in detail how properties of these workﬂows can be

represented and analyzed.

In this paper, we investigate an alternative mod-

elling using Petri nets for the observable states of de-

vices and device ecology workﬂows. We show how

existing Petri net theory can be used to analyze the

behaviour of the devices and their workﬂows.

The next section explains the notion of workﬂows

in device ecologies. Then, section 3 explains a Petri

net model of devices and device ecology workﬂows.

In section 4, we identify useful properties of device

ecology workﬂows and then consider how Petri net

analysis techniques can be applied to analyse these

properties. We conclude in section 5 with future

work.

2 WORKFLOWS IN DEVICE

ECOLOGY

The environment of a device is not only other devices

but also human users and the Web resources that it can

connect to. We consider several examples of devices

working together and interacting with Web resources

(e.g., Web services).

Mentioned in the UPnP whitepaper is a script that,

on detecting that a master switch has changed to “on”,

will turn the heater on to a preset temperature, start

the answering machine playing new messages, turn

the stereo system on set to a favourite station, raise

the window blinds, turn the TV to the news station,

and turn on the light in the foyer. In this case, the

devices effectively work together, as orchestrated by

some central coordinator, in order to create the right

atmosphere and provide the right services (of inform-

ing the user of the new phone messages and news),

even though the individual devices might not be aware

of this global goal.

Devices might interact directly with one another

and with the user. An example is quoted from Berger

concerning Thalia appliances, short for Thinking and

Linking Intelligent Appliances: “When you set your

Thalia alarm clock to wake you at a certain time, it

will notify the coffee maker to adjust the time for

your morning cup of java. The alarm clock will let

you know if you forgot to put the water in the cof-

fee maker. It will also tell the blanket with a brain

when to turn off. In the morning, the alarm clock will

greet you with the current news and weather. As you

are making the pancakes, the kitchen console will au-

tomatically adjust the recipe for the number of por-

tions you need. Your HomeHelper kitchen console

will store shopping lists, calendars, and telephone

numbers that can be downloaded to your HandHelper

PDA.”

Smart appliances might interact with applications

and services across the Internet. For example, the

fridge can order food that has run out by connect-

ing to a Web service or negotiate with other appli-

ances about resource (e.g., power and networking)

consumption. Devices might seek human approval for

more critical tasks.

Devices can work together with other devices, the

user or Web resources in accomplishing its goals, ei-

ther as initiated by users or by proactive smart de-

vices. Such workﬂows might or might not involve

devices, users and Web resources, depending on the

application semantics. The simpler workﬂows might

involve only one device or two devices, but larger

workﬂows can involve a larger number of devices, as

we saw in the examples above.

As an illustration, we consider a workﬂow device

ecology workﬂow involving a television, a coffee-

boiler, bedroom lights, bathroom lights, and a news

Web service accessed over the Internet. Figure 1 de-

scribes this workﬂow. The dashed arrows represent

sequencing, the boxes are tasks, the solid arrow rep-

resents a control link for synchronization across con-

current activities, and free grouping of sequences (i.e.,

the boxes grouped into the large box) represents con-

current sequences.

This workﬂow is initiated by a wake-up notice from

Janes alarm clock which we assume here is issued

to the Device Ecology Workﬂow Engine (which we

call the Decoﬂow Engine) when the alarm clock rings.

This notice initiates the entire workﬂow. Subsequent

to receiving this notice, ﬁve activities are concurrently

started: retrieve news from the Internet and display is

on the television, switch on the television, boil coffee,

switch on the bedroom lights, and switch on the bath-

room lights. Note the synchronization arrow from

Switch On TV to Display News on TV, which en-

http://www.aarp.org/computers-

features/Articles/a2002-07-10-

computers

features appliances.html

ANALYZING OBSERVABLE BEHAVIOURS OF DEVICE ECOLOGY WORKFLOWS

Figure 1: An Example Device Ecology Workﬂow

sures that the television must be switched on before

the news can be displayed on it. After all the concur-

rent activities have completed, the ﬁnal task is to blink

the bedroom lights, in order to indicate to Jane that the

workﬂow tasks have completed. This scenario was in-

spired by and extends that by Berger. This workﬂow

can be described using BPEL4WS and executed us-

ing a corresponding workﬂow engine as outlined in

(Loke, 2003).

3 PETRI NET MODELLING OF

DEVICES’S OBSERVABLE

STATES AND DEVICE

ECOLOGY WORKFLOWS

Device ecology workﬂows can be decentralized (ad

hoc and peer-to-peer between devices), coordinated

by a central engine or hybrid, initiated by a user or a

device. Regardless of the architecture or the language

used to express the workﬂow, we have, in essence, a

workﬂow and a device ecology in which the workﬂow

is executed. Before describing the Petri net model of

devices and device ecology workﬂows, we ﬁrst pro-

vide some background on Petri nets.

3.1 Preliminaries

Petri Nets. Petri nets (Murata, 1989) have been

widely used for process speciﬁcation and veriﬁcation.

A standard Petri net graph consists of places (repre-

sented by circles), transitions (represented by rectan-

gles) and arcs (represented by arrows). Given a set of

identiﬁers U, a Petri net structure or simply net N is

a triple (P, T, F), where P ⊆ U and T ⊆ U are non-

empty, ﬁnite disjoint sets of places and transitions re-

spectively, and F ⊆ (P × T) ∪ (T × P), is the set of

arcs (ﬂow relation). The components of a net N are

also denoted by P

, T

and F

. A path of a net is

a nonempty sequence x

. . x

(k ∈ N) of net ele-

ments which satisﬁes (x

, x

), . ., (x

k−1

, x

) ∈ F. It is

strongly connected iff for every two net elements x, y

there is a path leading from x to y. For some x ∈ P∪T,

the set

•

x = {y | (y, x) ∈ F} is the preset of x and the

set x

•

= {y | (x, y) ∈ F} is the postset of x.

We can view places as describing the possible lo-

cal system states or conditions, transitions as events

which may modify the system state and arcs simply

link a place to a transition or a transition to a place. In

other words, an arc linking a place to a transition indi-

cates from which local state can the event occur next,

and an arc linking a transition to a place indicates the

local state transformation induced by the event occur-

rence, if any.

At any time, a place contains zero or more tokens,

drawn as black dots. The state M, referred to as mark-

ing, is the distribution of tokens over places. It is a

mapping M : P → N. It will be represented as fol-

lows: for example, 2p

+ p

+ 3p

denotes the state

with 2 tokens in place p

, 1 token in place p

and 3

tokens in p

. If a place (condition) is marked with a

token, the condition is true. A Petri net system is a

pair (N, M

) where N is a net structure and M

is a

marking called the initial marking (initial state) of the

system.

The dynamic behaviour of a Petri net is controlled

by the ﬁring rule. A transition can ﬁre or an event can

occur if there is at least one token in each of the tran-

sition’s input places (i.e. the event’s pre-conditions

are true). This transition is then said to be enabled.

An enabled transition ﬁres by removing one token

from all of its input places (pre-conditions) and de-

positing one token in each of its output places (post-

conditions). This movement of tokens from place(s)

to place(s) indicates a change of system states after

the occurrence of the event. The notation M

→ M

denotes a transition t enabled in state M

and ﬁring t

in M

results in a new state M

. If M

→ M

→ · · ·

→

are transition occurrences, then σ = t

· · · t

an occurrence sequence leading from M to M

and we

write M

→ M

. M

is reachable from M (we write

M →

∗

) iff there is some ﬁring sequence σ such

that M

→ M

. [Mi represents the set of all reachable

markings from M.

Some useful system properties have also been de-

ﬁned for Petri nets. A Petri net system is live if, for ev-

ery marking M and every transition t, there is a mark-

ing M

∈ [Mi which enables t. The system is bounded

if for every place p, there is a natural number n such

that M(p) ≤ n for every reachable marking M. The

system is 1-bounded or safe if n = 1. Petri net analy-

sis methods (Murata, 1989; Desel and Esparza, 1995)

have been devised to check for these properties in sys-

tem modelling.

ICEIS 2004 - SOFTWARE AGENTS AND INTERNET COMPUTING

Workﬂow Nets A workﬂow (or business process) is

a set of coordinated tasks to fulﬁll a speciﬁc business

purpose (Workﬂow Management Coalition, 1999).

Figure 1 is an example of a workﬂow. In a spe-

cial class of Petri nets, called Workﬂow nets (WF-

nets) (Aalst, 1998), workﬂow concepts are modelled

by Petri net elements: workﬂow activities or tasks

are modelled by the transitions, conditions (prece-

dence relations) modelled by the places, ﬂow direc-

tions modelled by ﬂow relations (directed arcs) and

cases modelled by tokens.

A Petri net N = (P, T, F) is a Workﬂow net (WF-

net) if and only if N has two special places i called

source and o called sink, where

•

i = ∅ and o

•

= ∅;

and by adding a transition t

∗

to N, the short-circuited

net (P, T ∪{t

∗

}, F ∪{(o, t

∗

), (t

∗

, i)}) must be strongly

connected (Aalst, 1998).

Using the WF-net model, the behavioural correct-

ness of the workﬂow can be analysed by examining

its soundness (Aalst, 1998), which is deﬁned based

on the following expected behaviour: that a workﬂow

should always be able to complete a case; every case

should be completed properly, with no more work in

progress after completion; and every task should be

executed by the workﬂow execution of some case. In

essence, a case starting in the initial state i must be

able to reach the only ﬁnal state o in the model. The

soundness property can then be expressed in terms of

Petri net’s liveness and boundedness properties: that

the workﬂow is sound if and only if the short-circuited

net is live and bounded. Hence, existing Petri net

analysis methods can be employed to check for work-

ﬂow soundness (Aalst, 1998). In (Aalst, 1999), the

concepts of WF-nets have been extended to interorga-

nizational workﬂows, in which several business part-

ners are involved in shared workﬂow processes.

3.2 Modelling Devices: Describing

Observable Effects of Device

Ecology Workﬂows

The observable states of each device and how a device

transitions between such states in response to opera-

tions can be represented by a Petri net. For example,

ﬁgure 2 depicts the minimal behaviour of the devices

participating in the ecology workﬂow in Figure 1. The

TV, bath room light and the kettle can exist in the on

or off state while the bedroom light has an additional

blinking state. Note that the behavioural models are

effectively ﬁnite state machines.

Recalling the deﬁnition of state machine S-net (De-

sel and Esparza, 1995), an S-net is a Petri net (P, T, F)

such that each transition t ∈ T has exactly one input

and output S-element, i.e., |

•

t |=| t

•

|= 1. It is also

a well-known fact that a Petri net system, called S-

system (N, M

) is live if and only if N is a strongly

connected S-net and M

marks at least one token. In

our approach, we assume that every device behaves

like a strongly connected S-system marked by exactly

one token, (i.e., at any time, the device can only exists

in exactly one single (ﬁnite) state) and it is assumed

to be correct at all times (i.e., the S-system is live).

off

turn

off

Behavioural Model

of TV, kettle or bathroom light

Behavioural Model

of the bedroom light

off

turn

off

blinking

stop

blinking

start

Figure 2: S-systems for Devices

Each device will also have an internal state - we are

only concern with the observable properties of the de-

vices here. Moreover, we assume that each device has

a set of operations which can be performed on it, each

of which might update the device’s observable state

(and internal state). The choice of properties mod-

elled of the device might depend on the application

at hand and so, it is meant to be an abstraction of the

device.

3.3 Describing Device Ecology

Workﬂows

Any device ecology workﬂow can be transformed into

a WF-net. The dashed box in Figure 3 shows a WF-

net equivalent of the device ecology workﬂow exam-

ple of Figure 1. The WF-net is synchronizing with the

observable behavioural (ﬁnite state machine) models

of the devices to form a Device Ecology Behaviour

Model (DEB-model), deﬁned below.

Deﬁnition 3.1

A Device Ecology Behaviour

Model is a tuple DEB =

(WF

, WF

, · · · , WF

, D

, · · · , D

, T

, SC),

such that:

1. n, k ∈ N, where n is the number of device ecol-

ogy workﬂow nets and k is the number of S-systems

each representing a device;

2. for each i ∈ {1, · · · , n} : WF

is a WF-net with a

start place in

and an end place out

;

ANALYZING OBSERVABLE BEHAVIOURS OF DEVICE ECOLOGY WORKFLOWS

3. for each i ∈ {1, · · · , k} : D

is an S-system of a

device;

4. T

is the set of synchronous communication ele-

ments (fusion sets);

5. SC ⊆ T

× P(T

) × P(T

) is the syn-

chronous communication relationship, where

i∈{1,··· ,n}

, and T

i∈{1,··· ,k}

;

6. for all t ∈ T

, {(t

, x, y) ∈ SC | t

= t} is a

singleton;

7. for all (t

, x

, y

), (t

, x

, y

) ∈ SC: if t

6= t

, then

6= x

∧ y

6= y

The above deﬁnes a system which combines device

ecology workﬂows (WF-nets) with device behaviours

(ﬁnite state machines). Figure 3 depicts an example

with only one WF-net synchronising with a number

of devices. Requirement 1 states that potentially a

device user can issue more than one device ecology

workﬂows (WF-nets) to the ecology of devices for the

system to do work.

A transition t in the set T

is the result of synchro-

nising or “fusing” two transitions - one from the WF-

net and one from the device - called a synchronous

communication element. The relationship is deﬁned

by SC which is a set of triples, each consisting of

the synchronous communication element and a pair

of “fused” transitions. In Figure 3, the relationship is

denoted by the dotted line labelled SC.

Requirements 6 and 7 state that for every syn-

chronous communication element, there is only one

unique element in SC and the pair of fused transitions

are also unique. In other words, no already fused tran-

sition can be involved in other synchronous relation-

ship.

4 ANALYSIS OF DEVICE

ECOLOGY WORKFLOWS

Since we model device ecology workﬂows as WF-

nets, for a device ecology behaviour model (DEB)

with one WF-net, we can use existing WF-net anal-

ysis methods (Aalst, 1998) to verify the model. For

a DEB with multiple WF-nets (i > 1), we can use

the analysis methods for Interorganizational Work-

ﬂow (IOWF) (Aalst, 1999).

These methods are concerned with detecting the

soundness property of the workﬂow for behavioural

correctness, which is deﬁned in terms of the liveness

and boundedness properties of Petri nets, as men-

tioned in section 3. The soundness property is consis-

tent with device ecology workﬂows because we also

want the DEB to complete the workﬂow execution.

For example, it is desirable for the workﬂow in Fig-

ure 3 to be able to execute to completion such that the

off

turn

off

blinking

stop

blinking

start

off

turn

off

turn

off

turn

off

retrieve

news

bathroom

switch on

light

boil

display

news

on TV

receive

wake−up

notice

blink

bedroom light

switch on

bedroom

light

Kettle

Light

representation

ecology workflow

WF−net

of a device

Bedroom

Light

Bathroom

Figure 3: Device ecology workﬂow interacting with devices

token can move from the source place p1 to the sink

place p2.

For each device, it is crucial to determine whether

a particular device state is reachable. For example, in

Figure 3, by executing the workﬂow, will the kettle

reach the “on” state? Such questions can be answered

by performing traditional reachability analysis (Aalst,

1998; Murata, 1989) on the Petri net model. A related

question that can be answered is “Given the current

state of a device, can the workﬂow execute to com-

pletion?”. For instance, if the kettle is already in the

“on” state before execution, is the workﬂow still exe-

cutable? These questions and more can be answered

by applying Petri net analysis methods on the DEB

model.

Using reachability analysis, one can determine if

certain desirable or undesirable states will be reached

on execution of a workﬂow. Such states map to mark-

ings in a DEB. For example, at any point of the ex-

ecution of a workﬂow, one might ask “will there be

a state where all the lights in my house are off?” or

“will there be a state where my front door is left un-

locked?” (in the context of a home security workﬂow,

for example).

5 CONCLUSION AND FUTURE

WORK

We have described a Petri net model of device ecol-

ogy workﬂows and of the observable behaviour of de-

ICEIS 2004 - SOFTWARE AGENTS AND INTERNET COMPUTING

vices. A futuristic scenario of application of this work

is where before one buys a device, he or she can ver-

ify if the device will work with the other devices he or

she has, and whether existing workﬂows will be com-

patible with a new device which replaces an old one.

There is still work to be done in applying our model

to speciﬁc scenarios in order to evaluate the practi-

cality of the proposed approach. We contend that our

approach is practical given that the S-system of each

device we use will not be overly complex, being an

abstraction of only some aspect of the devices. In this

paper, we do not deal with the full complexity of a

million networked devices and things as this was not

our goal, but we consider device ecologies where de-

vices are of a granularity with some computational

functionality (offering Web services, for example at

the appliance level) and collections of devices that

are user conceivable. Another avenue of research is

to consider semantics-based matching of device ecol-

ogy workﬂow tasks with devices in a device ecology.

ACKNOWLEDGEMENTS

We would like to thank the Australian Research

Council for partial funding of this work.

REFERENCES

Aalst, W. (1999). Interorganizational workﬂows: An ap-

proach based on message sequence charts and Petri

nets. Systems Analysis - Modelling - Simulation,

34(3):335–67.

Aalst, W. v. (1998). The application of Petri nets to work-

ﬂow management. The Journal of Circuits, Systems

and Computers, 8(1):21–66.

AHAM (2002). Connected Home Appliances Object Mod-

elling, AHAM CHA-1-2002.

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

ded Systems (2nd Edition). CMP Books.

Carabelea, C. and O.Boissier (2003). Multi-agent Platforms

for Smart Devices: Dream or Reality? In Proceedings

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

Corporation, M. (2002). Understanding UPnP

: A White

Paper. Software - Practice and Experience.

Desel, J. and Esparza, J. (1995). Free Choice Petri Nets.

Cambridge University Press.

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.

Jahnke, J., DEntremont, M., and Stier, J. (2002). Facili-

tating the Programming of the Smart Home. IEEE

Wireless Communications, pages 70–76.

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

ﬂows. In Proceedings of the International Conference

on Service-Oriented Computing, pages 559–74.

Loke, S. (2004). Device ecology workﬂows with pre-

dictable observable effects. In Proceedings of

the Formal Foundations of Embedded Software and

Component-Based Software Architectures (FESCA)

Workshop (to appear).

Marples, D. and Kriens, P. (2001). The Open Services

Gateway Initiative: An Introductory Overview. IEEE

Communications, pages 2–6.

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 Ssytems (WSTFES03),

pages 71–74.

Murata, T. (1989). Petri nets: Properties, analysis and ap-

plications. Proceedings of the IEEE, 77(4):541–80.

Nakajima, T. (2003). Pervasive Servers: A Framework for

Creating a Society of Appliances. In Proceedings of

the 1AD: First International Conference on Appliance

Design, pages 57–63.

Ramparany, F., Boissier, O., and Brouchoud, H. (2003).

Cooperating Autonomous Smart Devices. In Pro-

ceedings of the Smart Objects Conference (SOC’03),

Grenoble.

Saif, U., Gordon, D., and Greaves, D. (2001). Internet Ac-

cess to a Home Area Network. IEEE Internet Com-

puting, pages 54–63.

Waldo, J. (1999). The Jini Architecture for Network-Centric

Computing. Communications of the ACM, pages 76–

82.

Workﬂow Management Coalition (1999). Workﬂow man-

agement coalition terminology and glossary (WFMC-

TC-1011). Technical report, Workﬂow Management

Coalition, Brussals.

ANALYZING OBSERVABLE BEHAVIOURS OF DEVICE ECOLOGY WORKFLOWS