Assisting Sensor-Based Application Design and ...€¦ · Assisting Sensor-Based Application Design and Instantiation Using Activity Recommendation Zahra Movahedi1,2,∗, Walid Gaaloul1,

c© The British Computer Society 2014. All rights reserved.For Permissions, please email: [email protected]

doi:10.1093/comjnl/bxu076

Assisting Sensor-Based ApplicationDesign and Instantiation Using Activity

Recommendation

Zahra Movahedi1,2,∗, Walid Gaaloul1, Sami Bhiri1 and Bruno Defude1

1Computer Science Department, TELECOM & Management SudParis, UMR 5157 CNRS Samovar, Evry,France

2Zodianet Company, Palaiseau, France∗Corresponding author: [email protected]

Recently, Sensor/Actuator Networks have become an emergent technology for various applicationareas such as security and surveillance applications, traffic control, logistics, energy control in publicand private buildings, etc. Designing and constructing new applications using these technologiesremain, however, a challenging task. Indeed, finding the relevant sensors and actuators, andcombining them in a proper way in order to achieve a specific goal is not an easy task andrequires several skills from different stakeholders. Moreover, sensor environments are inherentlyhighly dynamic. Furthermore, current applications are in general tightly coupled to the underlyinginfrastructure which hampers their reuse and flexibility to changes. In this paper, we present aprocess-oriented and service-based approach for supporting the development of adaptive sensor-based applications. Our approach decouples application logic from its implementation. A design-time model is first specified, as a flow of activities, which is then deployed in a particularenvironment. Decoupling the application logic from its implementation enables, on one hand, tofoster the reuse at the application level and, on the other hand, to adapt the same application todifferent environments and situations. We propose also an activity recommendation techniqueto provide assistance to application designers by recommending to them activities that have beenused in a similar compositional context. Our approach has been prototyped using service standardssuch as BPMN within the context of the VITRO European project and validated by several use cases.

Keywords: sensor-based applications; service composition; business process; service adaptation;activity recommendation; neighbourhood context

Received 4 October 2013; revised 1 July 2014Handling editor: Mohamed Jmaiel

1. INTRODUCTION

Sensor/Actuator Networks (S/A Networks) are becomingincreasingly emergent in a variety of applications such as homeautomation, traffic monitoring, healthcare, environment moni-toring, etc. These applications mostly require the compositionof a large number of distributed and heterogeneous sensors thatreport data continuously from physical or environmental phe-nomena (temperature, light, intensity, location, etc.) of a fea-ture (a lake, a home, etc.).

Owing to the large-scale, heterogeneous and distributednature of S/A networks, designing and constructing value-added applications is a difficult task. Numerous standards andapproaches try to address this issue. The Open Geospatial

Consortium is specifying standards for interoperability inter-faces and metadata encodings enabling the integrating of datafrom various S/A networks and the deployment of sensor webapplications over the Internet [1].

Although these standards are very important and resolvebasic problems, they operate, however, on a low technicallevel. They fall short when it comes to defining the businesslogic of sensor-based applications. Without loss of generality,sensor-based applications require the gathering, integrating andprocessing data from different sources and definition of data-based decision-taking operators that trigger certain actions asa reaction to the occurrence of certain situations. Developingsuch applications requires the combining the relevant sensors

Section C: Computational Intelligence, Machine Learning and Data AnalyticsThe Computer Journal, 2014

The Computer Journal Advance Access published August 20, 2014 by guest on July 11, 2015

http://comjnl.oxfordjournals.org/

Dow

nloaded from


2 Z. Movahedi et al.

and actuators in a proper way in order to achieve the desiredgoal. Moreover, sensor environments are inherently highlydynamic which require appropriate mechanisms enabling theapplication to adapt properly to changes.

In this paper, we are interested in supporting the develop-ment (design and implementation) of adaptive sensor-basedapplications that react properly to sensor environment changes.We present a process-oriented and service-based approach forsupporting the development of adaptive sensor-based applica-tions. Our approach decouples between the application logicand its implementation. A design-time business process (BP) isfirst specified, as a flow of activities, which is then deployed ona particular environment. An activity is a conceptual descrip-tion of a sensor, actuator, processing data or decision-makingservice. Decoupling the application logic from its implementa-tion enables, on one hand, fostering the reuse at the applicationlevel and, on the other hand, adapting the same application todifferent environments and situations.

Process design is the initial and key step that impacts on thesuccess of the desired sensor application. Designing processmodels from scratch is a labour-intensive and time-consumingactivity, especially when such models are required to bedetailed to support the development of software systems [2].It would be inefficient if every time a company engages inmodelling and re-designing its process; it does it from scratchwithout consideration of previous design experiences, bestpractices or how others perform similar tasks.

Several consortia and vendors have defined so-calledreference process models that capture proven practices andrecurrent business operations in a given domain. They aredesigned in a generic manner and are intended to beindividualized to enable systematic reuse of proven practicesacross process (re-)design projects. Other industrial andresearch efforts on facilitating BP design rely on BP discoverymechanisms.

These techniques operate on a coarse-grained level byrecommending entire BP models which may be confusingto the designers. Moreover, current techniques based onreference process models lack appropriate automation supporthampering their effective application. We present in this papera complementary technique that operate on fine-grained levelsby recommending a list of activities that are related to a specificposition in the ongoing designed process. By providing a list ofalternatives for a specific position in a process, our approachcan help to adjust it in order to improve it or adapt it to thechanging environment.

Different from current recommendation techniques, ourapproach does not require extra information about the positionto be filled in, or the activities to be recommended. Instead,our approach takes into account the similarity betweencompositional contexts of activities which can be computedfrom existing models.

To illustrate the approach features and show its feasibility,a real use-case scenario is used through this paper. The aim

of this scenario is to ensure building automation (alarm andsecurity, energy control), focusing on a fire detection scenario.

The rest of the paper is organized as follows: in Section 2we describe the main phases of a sensor-based applicationslifecycle we are considering in our approach. In Section 3,we introduce our process-oriented and service-based modelsfor specifying sensor-based applications. Section 4 elaboratesour proposed methods and algorithm for implementingand executing a sensor-based BP. Section 5 details ourrecommendation technique for the adaptation and the designof sensor-based applications [3]. In Section 6, we describethe prototype we have done in the context of the VITROproject [4]. Section 7 positions our approach within relevantrelated work. We draw in Section 8 some conclusions andpresent future directions.

2. SENSOR-BASED APPLICATION LIFECYCLE

In this section, we present a sensor-based application lifecycle(Fig. 1) which comprises four phases as follows:

1. Design phase: captures the application logic as a BP,which is defined as a flow of activities. An activity isdefined by a semantic specification that declarativelydenotes a (set of) sensor(s)/actuator(s) or an opera-tion (synchronization, manipulation or decision). Thedesigner specifies new business processes either fromscratch or using the activity recommendation technique(Section 5) which assists in facilitating the design ofnew models. This technique provides a list of alterna-tives for a specific position in the ongoing model whichcan be useful in either expanding a designed processto provide new functionalities, or creating new processvariants.

2. Deployment phase: implements a BP while taking intoaccount semantic specification of activities. During theimplementation of a BP, we maintain the mapping

Design

Deploym-ent

Execu�on

Analysis Adapta�on

FIGURE 1. Sensor-based application lifecycle.


by guest on July 11, 2015http://com

jnl.oxfordjournals.org/D

ownloaded from


Assisting Sensor-Based Application Design and Instantiation Using Activity Recommendation 3

between activities and the corresponding concreteservices that implement them. The implementationof a BP sometimes requires adding extra operationactivities. For instance, if a BP specifies the averagetemperature in Celsius, a converter activity will beneeded to convert the measured data to the specifiedunit if necessary.

3. Execution phase: in addition to running an activity,we also ensure its proper execution and the respect ofthe semantic specifications. In case of a dysfunctionalservice has been detected, an adaptation mechanismis launched. We go back to the design phase, we usethe same recommendation technique to specify a newmodel by replacing the activity that the dysfunctionalservice implements. Then we deploy the new modeland execute it.

4. Analysis phase: this phase analyses the applicationexecution logs in order to analyse and improve them.In this paper, we do not deal with this phase.

3. COMPOSITION MODEL

In this section, we introduce a process-oriented and service-based composition model. This model explains the differentlevels for specifying sensor-based applications. In the follow-ing, we present firstly an overview on this model (Section 3.1)and then we detail the notations of activity (Section 3.2) and BP(Section 3.3) in the context of S/A networks. At the end of thissection, following our model, we present a use-case scenariothat will be developed through the paper to present differentphases of a sensor-based application lifecycle (Section 3.4).

3.1. Overview on composition model

The proposed composition model is structured on three levels:concrete service level, activity level and BP level (Fig. 2).

1. Concrete (low-level) service level: is the lowest levelof the composition model, which relies on the differentcomponents of an S/A network. In general, an S/Anetwork is composed of heterogeneous (different typesof sensors and actuators such as temperature, light,alarm, etc.) and dynamic (sensors may appear anddisappear at any time) nodes (sensors or actuators) aswell as a gateway (GW). The role of the GW is tooffer interconnection between an S/A network and theupper layers. In this sense, each GW contains a uniformAPI allowing the upper layers to retrieve and invokesensors/actuators in the same way as web service.It contains also a registry describing capabilities ofsensors and actuators. We have chosen SensorML [5]to define these capabilities.

2. Activity level: aims to abstract the specificities of theconcrete service level vis-à-vis the requester. Appli-cations are defined as business processes referencing

Opera�on ac�vity Repository

Opera�on ac�vity

S/A ac�vityRepository

S/A ac�vity

Business processRepository

GWGW Concrete service

levelAc�vity level

Business process

level

FIGURE 2. Composition model.

activities and not directly as concrete services. Thisallows the decoupling of the application logic from itsimplementation. Decoupling the application logic fromits actual implementation has many benefits. First, itenables reuse when developing new applications. Sec-ondly, it enables implementing the same application ondifferent environments and according to different userrequirements. Activities are defined by semantic spec-ification denoting declaratively a set of concrete ser-vices. The created activities are stored in a repositoryin this level and the BP provider uses them to createbusiness processes.

3. BP level: an application is modelled as a BP (a flow ofactivities) which is then implemented and executed ona particular environment binding to the actual concreteservices in level 1. This allows creating an arbitrarycomplex process and reusing existing activities. Theseorchestrations are defined as business processes that arestored in a repository. The next section explains in moredetail the notion of activities and BP.

3.2. Activity

Formally, an activity is defined as a black box with threeattributes (Fig. 3): Activity =<IdA, typed input/output,semantic specification>.




ownloaded from



FIGURE 3. Activity model.

(i) IdA is a unique identifier for an activity.(ii) Input specifies the input values which have to be sent to

an activity to perform its tasks and Output specifies theresults produced by an activity. The inputs and outputsare typed, allowing checking of the correctness of anorchestration.

(iii) Semantic specification which describes the activitysemantically as a set of conditions {(property, opera-tor, value)}. Property references a concept in a domainontology which has to be defined for each class ofapplications, operator references a classical compari-son operator (equality, inequality, . . .) and value rep-resents either a constant or a concept in a domainontology.

The domain ontology is used to describe semantic attributesand is a top-level ontology structured in six main concepthierarchies: device (sensors and actuators), measure (containsall the concepts related to measures coming from sensors, i.e.type of measure, unit of measure, it should be compatible withthe description language of sensors in our case SensorML [5]),action (contains all concepts related to actions that can bedone by actuators, i.e. switch on/off), operation (contains allconcepts related to operations for end-users, i.e. monitoring,controlling), time (contains concepts related to time) andlocation (contains concepts related to location, i.e. building,room). Of course, there are semantic relationships betweenthese hierarchies (i.e., an action can contribute to an operation,a sensor produces values in a given unit of measure). The inputand output are in a stream data nature. We define a stream dataas following.

Definition 3.1 (Stream element). An element s contains onetyped measurement attribute m, and one timestamp attributetmstmp, s =< m, tmstmp >.

Each attribute m belongs to the measurement concept Mand tmstmp to the time concept T . By T we denote a totallyordered set containing discrete points which represent differentmoments in time, tmstmp ∈ T = {t0, t1, t3, . . .}, T ⊂ N0.

Definition 3.2 (Stream data). A stream S = {s0, s1, . . . ,

sn, . . .} is a sequence of elements si ordered by timestampvalue. In addition, elements s also have linear positionalordering, i.e. the element sn is the nth element of the stream S.

Based on the activity definition, we categorize three kindsof activity as follows (sensor activity, actuator activity andoperation activity):

1. Sensor activity: each sensor activity denotes a setof sensor services. The schema of a sensor activ-ity is as follows: <IdSA, typed output, semanticspecification>.

(a) IdSA attribute specifies a unique identifier for asensor activity.

(b) Output attribute which specifies the measurementsproduced by the sensor activity. The outputs are atyped data stream. A data stream is defined as a(infinite) set of tuples ordered by timestamp value.Each tuple contains a measurement value and atimestamp attribute.

(c) Semantic specification attribute which uses conceptsfrom device, measure, location and time parts ofthe domain ontology. For example, one can definethe type and unit of measurements of the sensor(concepts from measure) and the frequency (conceptof time).

2. Actuator activity: each actuator activity denotes a setof actuator services. The general schema of an actuatoractivity is as follows: <IdAA, typed input, semanticspecification>.

(a) IdAA attribute specifies a unique identifier for anactuator activity.

(b) Input attribute which specifies the input values ofan actuator activity to perform a task. They areconsidered to have a type which is described by anaction concept. For instance, for a siren actuator, theaction may be switch on/off.

(c) Semantic specification attribute which uses conceptsfrom device and action parts of the domainontology. It should be noted that some devices aresensor and actuator at the same time. In our model,we described them as two devices: a sensor and anactuator.

3. Operation activity: operations are needed to orchestratesensor and actuator activities. An operation activitydescribes an operation service and specifies the way theinput of an operation is transformed into the output.

In the following, we define several kinds of operationactivities that are synchronization, manipulation anddecision. New operations can be added by anadministrator if needed. More complex operations canalso be defined by composing several operators.

(a) Synchronization: In this category, we have operatorsoperating on a single stream (Synfreq and Syntemporal)and operators operating on multiple streams (unionand join). The Syn operators operate on an inputstream and produce an output stream with a different




ownloaded from



frequency or a different time interval. For synchro-nization on frequency, the operator Synfreq(S, F, t f )

operates on a stream S and is parametrized by afunction F specifying how to delete values in theinput stream if the target frequency t f is lowerthan the source one or to add values in the othercase. For temporal synchronization, the operatorSyntemporal(S, start, end) operates on a stream S andproduces as output all the values of S with a times-tamp belonging to the interval [start, end].

Join and union operate on multiple streamsas input and produce a single stream as output.Union(S1, S2) returns a stream composed by all thetuples of stream S1 and all the tuples of stream S2,ordered by their timestamp. JoinJC (S1, S2) returnsa stream composed by a set of tuples t, where t is theconcatenation of a tuple from S1 and a tuple fromS2 satisfying the join condition JC .

(b) Manipulation: in this category, we have operatorsdoing arithmetic operations on streams. We presentthree of particular interest, which are conversion,filtering and aggregation. The Conversion operatoroperates on a single stream and produces as outputa new stream where values of the source streamare transformed by applying a function. A simpleexample of conversion is the transformation of avalue from a unit of measure to another (changeFahrenheit to Celsius). The Filtering operatoroperates on a single stream and produces as output astream composed by all values of the source streamsatisfying a particular condition. The aggregationoperator operates on a single stream or on multiplestreams. It applies an aggregate (average, min,max, . . .) on a window of the input stream(s). Thewindowing can be defined either by a time intervalor a number of values.

(c) Decision operators: they are typical domain opera-tors and providers have generally to add new onesto fulfil their needs. A decision operator operateson an input stream (or on another decision operator)makes a decision and produces as output an actionfor an actuator activity. A simple example of such anoperator is the triggering of an actuator if one valuefrom the input stream exceeds a given threshold.

3.3. Business process

Sensor-based applications share many similarities with busi-ness processes. Both of them can be modelled as directedgraphs where nodes correspond to the processing tasks andedges express sequencing order between these tasks. However,stream-data processing applications and business processeshave also fundamental differences regarding the paradigm of

their execution. A BP model is used as a blueprint that is instan-tiated every time a new request is issued, generating differentthreads running in parallel, each one serving a specific request.However, the concept of instance is not quite clear and explicitin data-stream processing application as it is in BP.

Given the purpose of our work, we can model sensor-basedapplications as BP. First, data-stream applications operate ondata belonging to a time-window. In this way, an instance ofthe same BP model can be created for every occurring time-window. Secondly, the focus of our work is more on (design)models rather than on details of implementing sensor-basedapplications on a specific stream processing engine. Modellingsensor-based applications as BP would enable reusing andadapting a rich set of techniques developed in the context ofBPM.

A BP can be seen from two complementary views. Seen as ablack box, a BP can be considered as one (composite) activityand thereafter it can be described as any other activity by its Id,input/output and semantic specification. Seen as a white box, aBP can be considered as a flow of activities. Given the focus ofour paper, we limit our definition of a sensor-based BP to thewhite box view.

There are a number of process modelling languages, e.g.BPMN, WS-BPEL, EPC, YAWL and UML activity diagram.Despite their variances in expressiveness and modellingnotation, all these languages are graph-based and sharecommon concepts of tasks, events, gateways, artefacts andresources, as well as relations between them, such as transitionflows [6].

In our work, we define a sensor-based BP as a directedlabelled graph. Our model is generic enough so that it cancapture a BP modelled in different notations and languages.Without loss of generality, we use in this paper BPMNto represent a BP. However, BPs are modelled and storedaccording to our model given in Definition 3.3.

Definition 3.3 (Business process). A sensor-based BP is adirected labelled graph G P = (AP , EP , L P ) in which AP isthe set of activities, EP is the set of edges between activitiesand L P is the set of edge labels:

(i) EP ⊆ AP × AP ,

(ii) L P = l(EP ),

where : l : EP −→ L P ,

An edge between two activities captures control flowelements between them. How the function l is defined isdetailed in Section 5.2. Figure 4 depicts how the BusinessProcess BP1 given in Fig. 5 is specified according to our model.

3.4. Use-case scenario: design phase

In this section, we describe the ‘fire detection’ scenario thatis used through this article and detail its design phase. In this




ownloaded from



a 1 : SA1a 2 SA2a 3 SA3a 4 : AvG Temperaturea 5 : AvG CO2

a 7 : Decisiona 8 : AA1

a 6 : User Action

Nodes:

: Starts 1 ,s 2

: Ende 1

Edge labels:Mappings:

S: 'sequence'

Y: 'synchronisation'P: 'parallel-split'M: 'message-catching'

E: 'Data-based-exclusive(XOR)-gateway'

l 2

l 1

l 3

l 4

l 5

l10

l11

Y.Ya 4:a1

P.P a 1:s 1P.P a 2:s 1

P.P a 3:s 1

M.M a6:s 2

S.S a 5:a3

Y.YE.E a 7:a4

l12 Y.YE.a 6:a4

Y.Ya 5:a4l13

a 1

a 2

a 3

a 4

a 5

a 7 a 8

a 6l1

l2

l3

l4

l5

l8

l10

l11 l16

l14

l l 18

ll7

l9l13

e 1

s 1

s 2

l 6:P a 1 .P a 2

l 7:P a 1 .P a 3

l 9:P a 2=.P a 3

l 8 Y.Ya 4:a2

l12

E

l15

l14 Y.YE.E a 7:a5

l15 Y.YE.a 6:a5 EE.Ea 7:a6l16

17

S.S a 8:a7l17

e 1S.S:a8l18

6

FIGURE 4. Graph ‘BP1’.

BP1

AvGTemperature

SA3

AvGCO2

Decision AA1

SA1

SA2

UserAction

FIGURE 5. Business process ‘BP1’.

scenario, we consider different kinds of sensors and actuators(CO2, monoxide, light, temperature, fire siren, etc.) acrossfour distinct geographical trial sites (Tanagra, Paris, Patras,Rome), connected via the VITRO middleware platform [4]located in Madrid. The overall objective of VITRO is therealization of a scalable, flexible, adaptive, energy-efficientand trust-aware Virtual Sensor Networking platform, focusingon the reduction of deployment complexity and on advancedinteroperability. The end-user can access information from S/Anetworks, through gateways. As a BP provider, we design aset of business processes. These processes are defined usingactivities described in Table 1. We use the BP1 (Fig. 5)as a reference scenario in order to describe our approach.

BP1 monitors the temperature and CO2 level. A fire siren isactivated either directly by a user or when temperature and/orthe CO2 level go beyond a certain threshold. This processuses three sensor activities (two temperature sensor activities:S A1 and S A2 and one CO2 sensor activity: S A3), fouroperation activities (AvG temperature, AvG CO2, Useraction and Decision) and one actuator activity (sirenactivation: AA1).

As shown in Fig. 6, we present four other business processes.BP2 regulates a heater depending on the temperature, BP3activates a fire siren due to a high temperature and monoxidedensity, BP4 starts a video due to a high monoxide densityand motion detection and BP5 activates a fire siren due to a




ownloaded from



TABLE 1. Activities presentation.

Activity ID Activity description Semantic specification

S A1 temperature in Celsius (type,=, temperature), (units of measure,=, Celsius)S A2 temperature in Fahrenheit (type,=, temperature), (units of measure,=, Fahrenheit)S A3 CO2 (type,=, CO2)S A4 light (type,=, light)S A5 monoxide (type,=, monoxide)S A6 detection motion (type,=, detection motion)

AA1 fire siren (action,=, on/off)AA2 heater regulator (action,=, regulation)AA3 camera video (action,=, taking video)

AvG temperature calculate the average (type,=, temperature), (units of measure,=, Celsius),(frequency, >=, 5), (nb of inputs, >=, 3)

AvG CO2 calculate the average (type,=, CO2), (nb of inputs,>=, 2)AvG light calculate the average (type,=, light), (nb of inputs, >=, 2)AvG monoxide calculate the average (type,=, monoxide)Decision decide an action in terms of inputs ∅

BP5

AvGTemperature

BP4

Decision

AvGTemperature

AvGLight

Decision 1

1

AvGTemperature

AvGMonoxide

BP3

BP2

SA

1SA

1SA 2

AA

3AA

1AA

4SA

5SA

AA

Decision

Decision

5

AvGMonoxideSA

6SA

FIGURE 6. Examples of business processes.




ownloaded from



high light and temperature density. These BPs will be used toillustrate the recommendation scenario in Section 5.

4. IMPLEMENTATION OF SENSOR-BASED BP

Once a sensor-based process is designed, it is deployed on anexecution engine that takes care of creating an instance foreach client request and ensuring the execution of the processinstances. In this section, we discuss how a sensor-basedprocess is implemented.

4.1. Implementation of S/A and operation activities

Implementing a sensor-based BP boils down to implementingits sensor, actuator and operation activities (or activityinstances depending on the binding mode as explained below).Control and data flows are interpreted by the execution engine.In the context of service-based BP, activities (more preciselyactivity instances) are carried out by invoking appropriateservices. The operation of discovering and invoking theappropriate service that provides the required functionality iscalled service binding.

A sensor activity (instance) retrieves measures aboutsome features and feeds them (as a data stream) to anoperation activity which processes them accordingly. Anoperation activity may impose constraints on the number ofmeasurement inputs, their reading frequency and measurementunit. Therefore, a sensor activity is implemented by a set of(rather than one) sensor services sensing the same featureand returning potentially different measures in different unitsand with different reading frequencies. Moreover, additionalservices may be required to synchronize sensor readingfrequencies and convert measurement units. An actuatoractivity may also be carried out by a set of actuator servicesperforming the same action in different locations. For instancethe activity AA1 in our example activates a siren alarm. Theimplementation of such activity is achieved by firing severalsirens, i.e. invoking different actuator services, at differentlocations. Operation activities are implemented by JAVAservices providing the required functionalities. These JAVAservices are specified, as annotations to the correspondingactivities, before the BP is deployed.

4.2. S/A service binding

We distinguish between two modes for binding services:deployment-time and instantiation-time binding. S/A servicebinding may occur at deployment time, when the BP isdeployed on the execution engine, or at instantiation time,when a process instance is created to answer a given request.Operation services are bound to their activities at deploymenttime at the latest. However, the validation of their inputconstraints (See below Algorithm 2 lines 16 and 17) is done

at deployment or instantiation time depending on the bindingmode.

Algorithm 1 shows how a list of services are bound to agiven S/A activity independently of the binding time. Each S/Aservice description is matched to the S/A activity specification.Services that satisfy the activity requirements are selectedand added to the list of bound services (lines 6 and 7). Thefunction sd() returns the semantic description of the givenservice/activity.

Algorithm 1 S/A service binding algorithm.

1: Function binding(n) : l2: input n: S/A activity3: output l: list of S/A services implementing n4: l← ∅5: for all S/A service s ∈ S/A repository do6: if satisfy(sd(s), sd(n)) then7: Add(l, s)8: end if9: end for

10: return l

Depending on the binding mode, the result of the implemen-tation of a service-based BP at deployment time differs. Bind-ing at deployment time requires binding appropriate servicesto each process activity. This means that the same set of ser-vices will be invoked for all instances of the same activity. Sec-ondly, all activities of the BP are bound to services at deploy-ment time. At instantiation time, the engine has just to invokethe already bound services. The result of a BP implementationwhen services are bound at deployment time is a composite ser-vice (directly executable). The implementation of an activity isthe invocation of the bound services.

Binding at instantiation time requires binding a service toeach activity instance. This means that instances of the sameactivity may be carried out by different sets of services. Atdeployment time the activities are not bound to any services.The implementation result is therefore an abstract compositeservice in which an activity implementations are performedper instance. At instantiation time, the execution engine hasto discover and invoke appropriate services.

Deployment-time binding is more suitable in a ratherstatic environment. Indeed, in a dynamic environment whereservices may appear and go off, service binding andtherefore BP implementation may become invalid. In astatic environment where the service landscape changes lessfrequently, deployment-time binding enables ensuring theimplementation of the BP before BP instantiation.

Binding at instantiation time is more suitable for a dynamicenvironment where the service landscape changes frequently.




ownloaded from



Service binding at instantiation time enables to having the mostsuitable implementation for that particular instance.

4.3. Implementation algorithm

The implementation phase consists in binding actual concreteservices to activities of the BP. This binding has to satisfy allthe semantic specifications of the BP activities and potentiallyadditional conditions defined by the BP requester.1 Forexample, the BP requester can add conditions on the locationof the sensors and actuators. These additional conditions aredefined on activities. In some cases, it can be impossible toimplement a BP because some semantic specifications are notsatisfied. In this case, the recommendation phase is launched inorder to modify the initial BP.

Algorithm 2 The implementation algorithm.

1: Procedure implementation(G, IG)2: input Business process G(A, E, L)

3: output Implemented Business process I G4: not Bound← ∅5: I G← implementation of the activity flow of G6: for all n ∈ A do7: list O f Services← ∅8: if (type(n) = "Sensor activity" or "Actuator activity")

then9: list O f Services← binding(n)

10: if (list O f Services = ∅) then11: Add_implem(I G, n, list O f Services)12: else13: not Bound← not Bound

⋃n

14: end if15: else if (type(n) ="Operation activity") then16: if (satisfy_SD_Operation(sd(n),

sd(predecessors(n)))) then17: Add_Implem(I G, n, serviceOf(n))18: add appropriate synchronisation and

conversion services19: else20: not Bound← not Bound

⋃n

21: end if22: end if23: end for24: if (not Bound = ∅) then25: launch the recommendation procedure26: end if

Algorithm 2 describes the main steps for implementing a BPwhere services are bound at deployment time. The algorithmimplements first a skeleton of the process based on the flow

1Supporting additional conditions requires that binding occurs atinstantiation time.

of activities (line 5). Then it moves to bind services to processactivities (lines 6–23).

For each S/A activity, the algorithm calls the bindingfunction (explained above in Algorithm 1) in order to retrievea list of services that implement the given activity (line 9). Ifthe returned set is not empty, it is added as an implementationof the given activity (lines 10–12).

An operation activity is bound to its corresponding service(specified as annotation to the activity before the BPdeployment) only when its constraint in terms of numberof input streams is satisfied (lines 16 and 17). Services thatsynchronize reading frequencies and convert measurementunits as requested by the operation activity are added ifnecessary (line 18).

The variable notBound detains the list of activities thatcannot be implemented (lines 4, 13, 20). If there is at least oneactivity that cannot be implemented, then the recommendationprocedure is invoked to redesign the BP (lines 24–26).

4.4. Use-case scenario: deployment phase

Figure 7 shows one implementation of our application exampleillustrated in Fig. 5. The sensor activities S A1 and S A2which denote temperature sensors are implemented by threeconcrete services (S1, S2 and S3). These services satisfythe semantic specifications of S A1 and S A2. They returntemperature streams and feed them to the operation activityAvG Temperature. AvG Temperature requires havingat least two temperature values to compute their average. In thisexample, S1, S2 and S3 do not have all the required frequency(≥ 5) and the units of measurement (Celsius), as specifiedin AvG Temperature semantic specification (see Table 1).Therefore, to solve this inconsistency, new services have beenadded to synchronize the temperature stream frequency andconvert S3’s measures. One can note that, even if only twosensor services are required by the Avg Temperature, allthe possible bindings are constructed in order to offer morepossibilities for further operations of the BP or at executiontime. The sensor activity S A3, which denotes CO2 sensors, isimplemented by two concrete services S4 and S5, as depictedin Fig. 7. The measures returned by these services are thenprocessed by the operation activity AvG CO2.

5. ACTIVITY RECOMMENDATION

5.1. Motivations

Designing sensor-based applications is a challenging task.Indeed, finding the relevant sensor and actuator services, andcombining them in a proper way in order to achieve a specificgoal is not an easy task and requires several, skills detainedby different stakeholders. Moreover, sensor environments areinherently highly dynamic. Sensor-based applications needto adapt to changes that may impact its proper function.




ownloaded from



1 Syn

ServiceConverter

ServiceAvGCO2

ServiceDecision 1

ServiceAvG

Temperature

Service

n__-ySService

SynService

Service

2

Service

3

Service

4

Service

5

Service

UserAction

S

S

S

S

S ServiceA

FIGURE 7. BP1 implementation.

Inspired from previous work proposed in [3], we propose acomplementary technique that operates on fine-grained levelsby recommending activities for given positions in the ongoingmodelled process. Concretely, our approach can recommendactivities, which have similar neighbourhood context with afailed activity, in order to react to a dysfunctional sensor oractuator. Our recommendation approach can also be used atdesign time in order to help the designer to find activities thatshare similar neighbourhood contexts for given positions in theongoing modelled process. This neighbourhood context, whichrepresents the activity’s compositional context, is defined asa BP fragment around the activity. For a selected activity,we match its neighbourhood context with the neighbourhoodcontexts of other activities. The matching between twoneighbourhood contexts is scored by a similarity value. Then,based on the similarity values, we recommend to the processanalyst activities that have the highest similarity values.

There are rationale and benefits behind using the neighbour-hood context as it informs us about the activity’s behaviourand thereafter can unveil its business context. By using it, ourobjective is two-fold: (i) taking into account the BP fragmentsurrounding an activity as an input which would help to focuson specific parts of the BP and can avoid the computation com-plexity problem of BP structure matching and (ii) benefitingfrom the existing business processes by extracting the implicitknowledge contained in their fragments.

In the following, we detail our approach to generatingrecommendations for a particular activity/position in a BP.First, we present the concept of activity neighbourhood context(Section 5.2). Then, we detail how we compute the similaritiesbetween activities based on the matching of neighbourhoodcontexts (Section 5.3). In Section 5.4, following our scenario,we show how, for a given activity, we recommend a list ofactivities based on the computed similarity values. Finally,we discuss the complexity of the activity matching algorithm(Section 5.5).

5.2. Activity neighbourhood context

An activity in a process is a node and the connection betweentwo activities in that process is an edge in the correspondingprocess graph. On one hand, a connection between twoactivities is a sequence of connection elements connectingthem. On the other hand, activities can be connected in eitherseries (e.g. connected by sequence connection element) orparallel (e.g. split by a parallel connection element) fashion.So, to capture the connections between any two activities in aprocess and present them in the corresponding process graph,we present those connections in strings of characters and labelthe corresponding edges in the process graph with these strings.The following presents our solution to label the connectionbetween two activities.

Definition 5.1 (Connection flow). Let AP is a set ofactivities and CP is a set of connection elements in a businessprocess P; ei is connected to e j in P, denoted by ei ↔P e j , iffe j is performed right after or right before ei in P. The label ofthis relation denoted by l(ei ↔P e j ) = ei e j (if e j is performedright after ei ), or e j ei , (if e j is performed right before ei ).

A connection flow from ai to a j , ai , a j ∈ AP , denoted bya jai fP , is a sequence of connection elements c1, c2, . . . , cn ∈CP that satisfies: ai ↔P c1, c1 ↔P c2, . . . , cn−1 ↔P

cn, cn ↔P a j .2 a j

ai fP ∈ C∗P , C∗P is the set of sequencesof connection elements in P. The label of a connectionflow is the concatenation of labels of connected relations ina jai fP : l(

a jai fP )=l(ai ↔P c1).l(c1 ↔P c2) · · · l(cn−1 ↔P

cn).l(cn ↔P a j ).

For example, the label of the connection flow fromS A3 to AvG CO2 (as shown in Figs 4 and 5) is: S A3‘sequence’.‘sequence’AvG CO2; from AvG temperature

2The connection flow from a j to ai is the inverse of the connection flowfrom ai to a j .




ownloaded from



to User action is: AvG temperature‘synchronisa-tion’.‘synchronisation’‘Data-based-exclusive(XOR)-gateway’.User action‘Data-based-exclusive(XOR)-gateway’, andso on.

Intuitively, the closeness between activities is specifiedby the connection paths connecting them. The shortest pathbetween activities presents their closest relation. To specifythe best relations of an activity to others, we define theneighbourhood context graph (see Definition 5.2) whichpresents all shortest paths from an activity to others. Eachvertex in the neighbourhood context graph has a number whichindicates the shortest path length from it to the associatedactivity. Vertexes that have the same shortest path lengthare considered to be located on the same layer around theassociated activity. Thus, we name the number associated toeach activity (vertex) in a neighbourhood context graph layernumber. The area limited between two adjacent layers is calledzone. The edge connecting two vertexes in a neighbourhoodcontext graph belongs to a zone. We assign to each edge inthe neighbourhood context graph a number, so-called zonenumber, which determines the zone that the edge belongs to.

Definition 5.2 (Activity neighbourhood context graph). Aneighbourhood context graph of an activity ai in a businessprocess P, defined by Gai

P = (V aiP , Eai

P , LaiP ), is a labelled

directed graph built from the BP graph G P ; V aiP is the set

of nodes, EaiP is the set of edges, Lai

P is set of edge labels,where:

(i) V aiP = VP × N ,

V aiP = {(a j ,a j v

aiP ) : a j ∈ VP , a j v

aiP = S P LG P (ai ,

a j )},3 S P LG P (ai , a j ) is the shortest path length ofa jai fP ,

(ii) EaiP = EP × N ,

EaiP = {((a j , ak),

aka j zai

P ) : (a j , ak) ∈ EP ,aka j z

aiP =

min(a j vaiP ,ak v

aiP )+ 1},4

(iii) LaiP = L P .

For example, the neighbourhood context graphs of the ‘BP1’process (Fig. 5) and the ‘BP5’ process (BP5, Fig. 6) arepresented in Fig. 8.

5.3. Neighbourhood context matching

The similarity between two neighbourhood context graphs iscomputed based on the matching of their connection flows.In this section, we present step by step our computation,including the connection flow matching (Section 5.3.1), theneighbourhood context graph matching (Section 5.3.2), thematching with zone weight consideration (Section 5.3.3).

3a j v

aiP is the layer number of the node a j in G

aiP .

4aka j z

aiP is the zone number of the edge (a j ,ak ) in G

aiP .

5.3.1. Connection flow matchingThe label of each connection flow between two activitiescontains the relation information, i.e. connection elements anddirections, between them. Each label is presented in pairs ofpredefined strings, i.e. activity names and connection elements.It can be encoded as a string of characters in which eachcharacter represents a pair of predefined strings. We proposeto apply the Levenshtein distance (LD) [7] to compute thematching between two edge labels. Concretely, given twoconnection flows that have respectively labels l(y

x fP1) andl(vu fP2). By Encode(l(y

x fP1)) we denote the function thatencodes each pair of strings in the label l(y

x fP1) by a character.Let sP1 = Encode(l(y

x fP1)); sP2 = Encode(l(vu fP2)) andlength(sP1), length(sP2) be the lengths of the strings sP1 andsP2, respectively. The pattern matching between them, denotedby M(

yx fP1 ,

vu fP2), is computed by the following equation:

M(yx fP1 ,

vu fP2) = 1− L D(sP1, sP2)

Max(length(sP1), length(sP2))(1)

5.3.2. Neighbourhood context graph matchingTo compute the matching between two activity neighbourhoodcontext graphs, we propose to match all connection flows thatconnect the same activities and have the same zone number.Particularly, in the first zone, we match connection flows thatconnect the two associated activities to the same activitiesin the first layer. For example, in Fig. 8, we match a4

a5 fB P1

and a4a10 fB P5 , a7

a5 fB P1 and a7a10 fB P5 (the first zone), a1

a4 fB P1 anda1a4 fB P5 , a7

a4 fB P1 and a7a4 fB P5 , a8

a7 fB P1 and a8a7 fB P5 (the second

zone), and so on.Assume that ai is the selected activity in the ongoing design

process P1. Let ZtP1

(ai ) be the set of connection flows and|Zt

P1(ai )| be the number of connection flows in zone t of the

context neighbourhood graph GaiP1

. The similarity between ai

and another service a j in a process P2 based on neighbourhoodcontext graph matching within k zones is equal to the sum ofthe matchings of all connection flows within kth zones dividedby the number of connection flows within kth zones of theneighbourhood context graph of ai (Equation (2)).

Mk(GaiP1

, Ga jP2

) =

∑kt=1

∑ayax fP1∈Zt

P1(ai )

avau fP2∈Zt

P2(a j )

Mt (

ayax fP1 ,

avau fP2)

∑kt=1 |Zt

P1(ai )|

(2)where

Mt (

ayax fP1 ,

avau

fP2) ={

M(ayai fP1 ,

aya j fP2), t = 1

M(ayax fP1 ,

ayax fP2), 2 ≤ t ≤ k

As the LD of two inverse strings is equal to the LD of theoriginal strings5 and the connection flow from a j to ai is the

5See our proof at http://www-inf.it-sudparis.eu/SIMBAD/tools/BPAR/ld-inverse-strings.pdf.




ownloaded from

http://www-inf.it-sudparis.eu/SIMBAD/tools/BPAR/ld-inverse-strings.pdf

http://www-inf.it-sudparis.eu/SIMBAD/tools/BPAR/ld-inverse-strings.pdf



GBP1 (a 5)

a 1 : SA1a 2 : SA2a 3 : SA3a 4 : AvG temperaturea 5 : AvG CO2

a 7 : Decisiona 8 : AA1a 9 : SA4a 10: AvG Light

a 6 : User Action

Nodes:

: Starts 1 ,s 2

:Ende 1 ,e 2

Edge labels:Mappings:

S: 'sequence'

Y: 'synchronisation'P: 'parallel-split'M: 'message-catching'

E: 'Data-based-exclusive(XOR)-gateway'

a 2

nd -zone2

l1

a 5

a 3

a 4

a 6

a 7

l2

l3

l4

s 1

a 1

a 8

l5

l6

l7

l8

l9l10

l11

l12

l14

l15

l16

l17

l18

1st -zone

rd -zone3

st -layer1nd -layer2

rd -layer3

a 8

nd -zone2

a 10

a 9

a 4

a 7

l20

l21

s 3

a 1

l22

l23

l24

l25

l14

1st -zone

rd -zone3

st -layer1 nd -layer2rd -layer3

l19

a 10Y.Ya 7l21:

a 10Yl20:

a 4 Y.Ya 7l25:

l26

a 7 S.S a 8l26:

e 2

l27

e 1

Y.Ya 1l15:Y.Ya 2l16:

s 1s 1a 1 P.P a 2l17:

a 8 S.S e 1l18:

S a 5 .a 3 Sl1:

l2 Y. a 4:a5 Yl3 Y.YE.a 6:a5 El4 Y.YE.E a 7:a5

Y a 3 .s 1Yl5:

P a 3 .a 1Pl6:

P a 3 .a 2Pl7:

Y a 4 .a 1Pl8:

Y a 4 .a 2Pl9:

l10 Y.YE.a 6:a4 El11 Y.YE.E a 7:a4

a 6 E.E a 7l12:

Sa 10.a 9Sl19:

.a 2Y

Y a 9 .s 3Yl22:

P a 4 .a 1Pl23:

S a 4 .a 1Sl24:

,s 3

s 2

l13

GBP5 (a 10)

a 7 S.S a 8l14:

Ma 6 .s 2Ml13: a 8 S.S e 2l27:

FIGURE 8. Neighbourhood context graphs of the selected activities.

inverse of the connection flow from ai to a j , the matchingbetween two connection flows

ayax fP1 and av

au fP2 is computedby either M(

ayax fP1 ,

avau fP2)) or M(

axay fP1 ,

auav

fP2). For example,the neighbourhood context graph matching between a3 and a9given in Fig. 8 with k = 2 is as follows:

Mk(Ga3B P1

, Ga9B P2

)

= M(a4a5 fB P1,

a4a10 fB P5)+ M(

a7a5 fB P1 ,

a7a10 fB P5)

4+ M(

a1a4 fB P1 ,

a1a4 fB P5)+ M(

a7a4 fB P1 ,

a7a4 fB P5)+ M(

a8a7 fB P1 ,

a8a7 fB P5)

10

5.3.3. Zone weight considerationIntuitively, the behaviour of an activity is strongly reflectedby the connection flows to its closest neighbours, while theinteractions among other neighbours in the further layers donot heavily expose its behaviour. Therefore, we propose to




ownloaded from



assign a weight (wk) for each kth zone, so-called zone-weight,and inject this weight to the similarity computation. Sincethe zone-weight has to have greater values in a smaller kthzone, we propose to assign the zone-weight a value computedby a polynomial function, which is wz = (k + 1 − z)/k,where z is the zone number (1 ≤ z ≤ k), and k is thenumber of considered zones around the activity. A connectionflow belonging to the kth zone has a weight (wk = 1/k).The final matching formula improved with the zone weightconsideration is given below.

Mk(GaiP1

, Ga jP2

) = 2

k + 1×

k∑t=1

k + 1− t

k

×

∑ayax fP1∈Zt

P1(ai )

avau fP2∈Zt

P2(a j )

Mt (

ayax fP1 ,

avau fP2)

|ZtP1

(ai )| (3)

5.4. Use-case scenario: recommendation purpose

The neighbourhood context graph presents the interactionsbetween the associated activity and its neighbours in layers.It induces the behaviour of the associated activity in theprocess through neighbours. Therefore, the matching betweenneighbourhood context graphs exposes the similarity inbehaviours of the associated activities. In our approach, thehigher the matching value, the more similar in behaviour isthe activity. To generate recommendations, for each activityin a process, we compute the neighbourhood context graphmatching between it and others. Then, we sort the computedmatching values in descending order and pick up top-N6

activities that have the highest matching values for therecommendation.

Back to our use case, we present two scenarios to illustrateour activity recommendation technique. The first one concernsthe design phase in order to assisting the design of newbusiness processes and the second one concerns the executionphase in order to adapt the executed business processes tochanges.

Design phase: Assuming that the designer wants to modela variant of the business process BP1 where we do notrely on CO2 measurement to detect fire. So he selects theactivity AvG CO2 and launches our activity recommendationtechnique. Based on currently defined models, our techniquecan recommend to him the two activities AvG monoxide andAvG light. Indeed, given the business processes BP3 andBP5, we can see that AvG monoxide and AvG light havebeen used in compositional contexts similar to the one of AvGCO2.

It is worthy to note that our approach does not only aim atfinding activities that have similar functions with a selectedone. Instead, we also aim at retrieving activities that have

6N can be tuned by the process designer.

similar neighbourhood contexts. By recommending activities,our approach not only helps to find suitable activities for amissing position but also helps to find other alternatives fora selected activity. These alternatives can be useful in eitherexpanding a designed process to provide new functionality,replacing existing activities or creating BP variants. In thefollowing, we leverage our recommendation technique toimplement fault-tolerant techniques enabling sensor-basedapplications to adapt to component service failures.

Execution phase: Assuming that during the execution ofBP1 (in fact, the deployed model depicted in Fig. 7), theservice A1 has some execution problems and needs to bereplaced. Based on the correspondence table (which maintainthe matching between the activities and their implementationservice), we trace back the failure to the activity AA1 at the BPlevel. Using the same recommendation technique, the systemwill recommend AA2 and AA3 as potential replacements toAA1 (for the same reason explained above). The new definedprocess will then be deployed and executed.

5.5. Activity matching algorithm complexity

The process fragment surrounding an activity is presented by asub-BP graph. Therefore, the matching problem would becomea graph matching problem which was proved to be an NP-complexity problem [8]. However, in our case, we know theroot points of the graph comparison, which are ai and a j , andwe match only the same pairs of activities in both BP graphs;thus we avoid the NP-complexity problem of the original graphmatching.

On the other hand, only the flows connecting commonactivities in two adjacent layers are taken into account for thematching computation. So, by using queues (data structure) tostore the common neighbours and track them from the nearestzones to the furthest zones, we avoid the redundant checkingof unrelated neighbours. On the other hand, since the numberof common neighbours of two arbitrary activities is not great,our algorithm can run fast in computing the complete matchingof two activities. Without optimization, the worst case of thisalgorithm’s computation time is O(nS × nC × n × k), wherenS is the number of activities, nC is the number of businessprocesses, n is the maximum number of common activitiesof two arbitrary activities and k is the number of consideredzones. The worst case only happens when all the businessprocesses in the database are exactly the same.

Also noteworthy the number of connection flows connectingtwo activities. This number can be >1, which means thatthere can be more than 1 connection flows connecting twoactivities. So, we have to take into account all matching casesof those connection flows (bipartite graph matching problem).However, this rarely occurs in a BP and this number is notso great (in our dataset, the maximum value is 7). Therefore,this problem is negligible as it does not impact much on thecomputation time.




ownloaded from



Update the DB

10.Get data

10.Get data

USERSBUSINESS PROCESSMIDDLEWARESENSOR/ACTUATOR NETWORKS

Business process repository

BP deployment

browse r

1. Design a BP

BP p

rovi

der

2.Register in BP repository

3. Upload the BP list

VITRO service discovery component

VITRO service execution component

Web service

Recommendation

BP engine

BP design en v iro nem

ent

(12).Recommendation

(execution)

(1).

Reco

mm

enda

tion

4. Select and deploy a BP

End-

user

I nst a nciat ion-tim

e metho d

Deplo yment -

time m

eth od

5.a..Start 5.b..Star

t

13.End

6.Service discovery

7.Discovered services

Send the BP list

S/A desc DB

9.Servi

ce in

voca

tion

11.Servi

ce in

voca

tion re

sult

(8).Recommendation

(implementation)

FIGURE 9. Prototype overview.

6. IMPLEMENTATION

In this section, we describe the prototype we have developedin the context of the VITRO project. This implementationis based on Bonita,7 which is a BP software environment,including a BP designer, BP repository, BP browser andBP engine. The global environment is structured in threetiers (Fig. 9). The first one is the S/A Network, whichprovides the S/A data and supports interactions with the secondtier using gateways. The second tier is the middleware tierresponsible for describing and invoking actual S/A servicesimplementing BP activities. This tier is implemented by theVITRO middleware. The third tier corresponds to our software.It implements the sensor BP approach described in the previoussections. It is based on the Bonita environment. Moreover, aset of operation activities has been implemented using Javalanguage. Connections to the middleware layer are ensuredby connectors. The Database connector interacts with theS/A description database to select and bind an activity toappropriate S/A services considering semantic specifications.

7http://www.bonitasoft.com/.

The Web service connector is in charge of invoking S/Aservices to get data from sensors or activate an actuator.

This environment can be used by two kinds of users. Thefirst one is the Business Process Provider (BP provider) whois the actor responsible for designing Business processes foruse by end-users. In our implementation, the BP provider usesBPMN 2.0 standard in the BP design environment of Bonita.The second type of user is the End-user who selects andinvokes the business processes provided by BP providers.

As described in the design phase of the sensor-basedapplication lifecycle (Section 2), the BP provider can design aBP either from scratch or along with recommendation assisting(step 1, 1.a, 1.b). For each S/A activity, the BP providerdefines semantic specifications. The BP repository will be thenupdated, registering the new designed BPs (step 2).

An end-user selects and deploys a BP using the browser(step 4). Then the system has to interact with the middlewarelayer to associate an implementation for all activities. This taskis done either by a deployment-time method (step 5a) or by ainstantiation-time one (step 5b). The deployment-time methodanalyses the whole BP and transforms it into an implemented




ownloaded from

http://www.bonitasoft.com/



BP using the S/A description database (step 6, 7). Then thisimplemented BP is executed by the BP engine, invoking webservices from the middleware layer (step 8). The instantiation-time method uses the same principle but processing the BPactivity per activity. In both methods, if an activity becomesdysfunctional, the recommendation component is invoked(step 6, 10) to replace the dysfunctional activity (more detailsin Section 4).

7. RELATED WORK

Compton et al. [9] provide a detailed survey on the differentproposed semantic specifications of sensors. Many of theseapproaches focused on sensor meta-information. Recently,the W3C SSN-XG group has made an effort to providea domain-independent ontology compatible with existingsensor standards such as SensorML. This contribution will beconsidered in the evolution of our work.

Service composition has been the subject of many researchworks in the web services domain (see [10, 11] asgood surveys). However, due to the different characteristicsof S/A network compared with traditional web service(high dynamicity, resource constraints, heterogeneity), newapproaches for service composition in the S/A network are thenrequired.

A dynamic composition of sensor services is proposedin [12]. This approach proposes to model the compositionas a data flow graph enhanced with metadata information.They propose then two heuristic algorithms (bottom-up andtop-down) to map the composition graph to the appropriatesensor services. Their aim is to optimize the cost ofservice composition (communication cost, processing cost)considering both user preferences and service metadatainformation. However, this paper does not provide a clearpresentation on the service composition development process.

In [13], the authors present OASiS, a service-orientedmiddleware for wireless sensor networks. Its main goal isto facilitate the design, development and implementationof applications. Like our proposal, OASiS uses a multi-layer development process. Applications are defined asdataflows (modelled as a graph of services). Services arethen dynamically discovered and have to verify constraints.Compared with our work, OASiS does not use semanticdescription to describe and select services. It does not alsoexplicitly support operations in the graph definition.

Reuse in BP modelling is a hot topic. Several consortiaand vendors have defined so-called reference process models,for example SCOR [14] or SAP [15] models, that captureproven practices and recurrent business operations in a givendomain. They are designed in a generic manner and areintended to be individualized to fit the requirements ofspecific organizations. Other industrial and research effortson facilitating BP design rely on BP discovery mechanisms.

They recommend to the designer a list of BPs similar to theongoing designed one. These techniques operate on a coarse-grained level by recommending entire BP models which maybe confusing to the designers, especially when the processmodels are relatively large. Moreover, it is quite often thatprocess designers have a partial idea of the process model andrequire assistance to complete missing parts.

Some existing approaches [16–18] target hastening thedesign phase by retrieving a process to the current designedprocess from repositories. They proposed either rankingexisting BP models for similarity search [16, 19], or measuringthe similarity between them [17, 18, 20] for creating newprocess models. Several consortia and vendors have defined so-called reference process models that capture proven practicesand recurrent business operations in a given domain. Theyare designed in a generic manner and are intended to beindividualized to enable systematic reuse of proven practicesacross process (re-)design projects. Other industrial andresearch efforts on facilitating BP design rely on BP discoverymechanisms. These techniques operate on a coarse-grainedlevel by recommending entire BP models which may beconfusing to the designers. Moreover, current techniques basedon reference process models lack appropriate automationsupport, hampering their effective application.

Business processes in reality consist of a large numberof activities and flow connections; therefore, recommendingto the designer a list of business processes can make himconfused and make it hard for him to detect how thebusiness processes are similar and which parts should beinherited from the recommended processes to use for hiscurrent design. In addition, computation on the whole processleads the existing approaches to the graph matching problemwhich is NP-complexity [8] and they have to deal with thetrade-off among the complexity, accuracy (efficiency) andsystem performance [16, 19]. In our approach, we focuspartially on the BP and take into account only the activityneighbourhood context for recommendations. Consequently,we retrieve related activities without facing the NP-complexityproblem (Section 5.3).

Thomas Gschwind et al. [21] applied workflow patterns forBP design. They aimed at helping business users to understandthe context and apply patterns during the editing process. In ourwork, we help designers better design a BP by automaticallyrecommending activities that have similar contexts instead ofpatterns (Section 5.4).

8. CONCLUSIONS AND PERSPECTIVES

In this paper, we presented a process-oriented and service-based approach for developing sensor-based applications.Our approach decouples the application logic from itsimplementation. An application is first modelled as a BP, whichis then deployed on a particular environment. Decoupling




ownloaded from



the application logic from its actual implementation hasmany benefits. First, it enables reuse when developingnew applications. Secondly, it enables implementing thesame application on different environments and according todifferent user requirements.

To assist designers in specifying new sensor-based appli-cations, we proposed an approach based on recommendingactivity to given selected positions in the ongoing modelledprocess. This recommendation technique is based on similar-ity between compositional contexts the different activities havebeen used in.

Moreover, the same recommendation technique enablesproviding a fault-tolerant mechanism enabling a sensor-based application to adapt to changes due to sensor failuresor constraint violation. In current approaches, adaptationis ensured by replacing dysfunctional sensor services. Thelimitation of these techniques is that in case no sensorservice is available, the adaptation fails. Our approach enablesovercoming this problem by operating on the BP level, ratherthan on the deployed model. Ensuring the adaptation at theabstract model enables considering other activities or replacingthe implementation of a whole fragment and not just oneservice as current approaches do.

Our approach has been validated by use cases that havebeen defined in the context of the European project VITRO.We have implemented a prototype for modelling sensor-basedapplications using our recommendation technique. Businessprocesses are defined using BPMN. We use a Bonita engineto execute them.

As future work, we intend to investigate a service-oriented approach to integrate data-stream and complex-eventprocessing into process-oriented applications. We intend alsoto investigate the co-existence of connection flows in businessprocesses, as well as the number of times that an S/A serviceis used in order to refine our matching algorithm. we also aimat extending our recommendation approach to mine the processmodels from event logs. The mined process models can be thenused as inputs for building the configurable process fragmentsto assist the BP designers.

FUNDING

This work has been partly performed under Project FP7 ICT-257245 VITRO, funded by the European Commission.

REFERENCES

[1] Botts, M., Percivall, G., Reed, C. and Davidson, J. (2008)OGC Sensor Web Enablement: Overview and High LevelArchitecture. In Nittel, S., Labrinidis, A. and Stefanidis, A. (eds),GeoSensor Networks. Springer, Berlin.

[2] Aalst, W., Dumas, M., Gottschalk, F., Hofstede, A., Rosa, M.and Mendling, J. (2010) Preserving correctness during business

process model configuration. Formal Aspects Comput. J., 22,459–482.

[3] Chan, N.N., Gaaloul, W. and Tata, S. (2012) AssistingBusiness Process Design by Activity Neighborhood ContextMatching. Proc. 10th Int. Conf. on Service-Oriented Computing,Shanghai, China, January 12–15, pp. 541–549. Springer,Berlin.

[4] VITRO: Virtualized dIstributed plaTfoRms of smart Objects,FP7-257245 Information & Communication Technologies (ICT)research project. www.vitro-fp7.eu.

[5] OGC 04-019r2 (2007) Sensor Model Language (SensorML):Implementation Specification. Technical Report. Open Geospa-tial Consortium.

[6] Pascalau, E., Awad, A., Sakr, S. and Weske, M. (2011) Partialprocess models to manage business process variants. Int. J. Bus.Process Integr. Manage., 5, 240–256.

[7] Levenshtein, V. (1966) Binary codes capable of correctingdeletions, insertions and reversals. Sov. Phys. Doklady, 10,707–710.

[8] Abdulrahim, M.A. (1998) Parallel algorithms for labeled graphmatching. PhD Thesis, Colorado School of Mines, Golden, CO,USA.

[9] Compton, M., Henson, C., Lefort, L., Neuhaus, H. and Sheth, A.(2009) A Survey of the Semantic Specification of Sensors. Proc.2nd Int. Workshop on Semantic Sensor Networks, Collocatedwith the 8th Int. Conf. on Semantic Web, Chantilly, USA,October 25–29, pp. 17–32. Springer, Berlin.

[10] Papazoglou, M. and van den Heuvel, W.-J. (2007) Serviceoriented architectures: approaches, technologies and researchissues. VLDB J., 16, 389–415.

[11] Dustdar, S. and Schreiner, W. (2005) A survey on web servicescomposition. Int. J. Web Grid Serv., 1, 1–30.

[12] Geyik, S.C., Szymanski, B.K., Zerfos, P. and Verma, D.C. (2010)Dynamic Composition of Services in Sensor Networks. IEEEInt. Conf. on Services Computing, Miami, FL, USA, July 5–10,pp. 242–249. IEEE Computer Society, Los Alamitos, CA.

[13] Koutsoukos, X., Kushwaha, M., Amundson, I., Neema,S. and Sztipanovits, J. (2007) OASiS: A Service-OrientedArchitecture for Ambient-Aware Sensor Networks. In Kordon,F. and Sokolsky, O. (eds), Composition of Embedded Systems.Scientific and Industrial Issues, Lecture Notes in ComputerScience 4888, pp. 125–149. Springer, Berlin.

[14] Stephens, S. (2001) Supply chain operations reference modelversion 5.0: A new tool to improve supply chain efficiency andachieve best practice. Inf. Syst. Front. J., 3, 471–476.

[15] Akkiraju, R. and Ivan, A. (2010) Discovering Business ProcessSimilarities: An Empirical Study with SAP Best PracticeBusiness Processes. Proc. 8th Int. Conf. on Service-OrientedComputing, San Francisco, CA, USA, December 29–10,pp. 515–526. Springer, Berlin.

[16] Yan, Z., Dijkman, R. and Grefen, P. (2010) Fast Business ProcessSimilarity Search with Feature-Based Similarity Estimation.Proc. Int. Conf. On the Move to Meaningful Internet Systems(OTM)—Volume Part I, Hersonissos, Crete, Greece, October25–29, pp. 60–77. Springer, Berlin.

[17] Aalst, W., Medeiros, A. and Weijters, A. (2006) ProcessEquivalence: Comparing Two Process Models based on




ownloaded from



Observed Behavior. Proc. 4th Int. Conf. on Business ProcessManagement, Vienna, Austria, September 5–7, pp. 129–144.Springer, Berlin.

[18] Li, C., Reichert, M. and Wombacher, A. (2008) On MeasuringProcess Model Similarity Based on High-Level ChangeOperations. Proc. 27th Int. Conf. on Conceptual Modeling,Barcelona, Spain, October 20–24, pp. 248–264. Springer,Berlin.

[19] Dijkman, R., Dumas, M. and Garcia-Banuelos, L. (2009) GraphMatching Algorithms for Business Process Model SimilaritySearch. Proc. 7th Int. Conf. on Business Process Management,

Ulm, Germany, September 8–10, pp. 48–63. Springer,Berlin.

[20] Ehrig, M., Koschmider, A. and Oberweis, A. (2007) MeasuringSimilarity Between Semantic Business Process Models. Proc.4th Asia-Pacific Conf. on Conceptual modelling, Ballarat, Vic-toria, Australia, January 30–February 2, pp. 71–80. AustralianComputer Society, Inc. Darlinghurst, Australia.

[21] Gschwind, T., Koehler, J. and Wong, J. (2008) Applying PatternsDuring Business Process Modeling. Proc. 6th Int. Conf. onBusiness Process Management, Milan, Italy, September 3–4,pp. 4–19. Springer, Berlin.




ownloaded from


Documents

Assisting Sensor-Based Application Design and ...€¦ · Assisting Sensor-Based Application Design and Instantiation Using Activity Recommendation Zahra Movahedi1,2,∗, Walid Gaaloul1,