Enabling High-Level Application Development for the Internet of Things

Pankesh Patel

PhD defense   25th November, 2013

Growing number of ``things”

2

Temperature sensors Fire

alarmsSmoke detectors

Lights

Traffic signals

Water leakage detector

Smart phones

Parking space

controller

Air pollution controllers

Structuralhealth

monitors

HVAC system

Smart car

Image credit: http://www.libelium.com/

3

Internet of Things (IoT)“A global networked infrastructure, linking physical

and virtual things through the exploitation of data capture and communication capability.”

[CASAGRAS project] http://www.grifs-project.eu/data/File/CASAGRAS%20FinalReport%20(2).pdf

4

Involves a large number of heterogeneous devices, processing elements

Composes multiple activities

Interacts with users whenever necessary

IoT application

5

Illustrative example: building system

Large numbers of heterogeneous devices

Smoke detector

User interfaces(e.g., display, mobile phones)

Firealarm

Badge reader

User withbadge

Data storage

Light

Temperature

sensorHeater

For situation awareness (e.g., avg. temperature of building), devices involved in collaborative activities

An application - compose multiple activities (e.g., detect user’s entry , query, set threshold)

6

Goal

“Enable development** of IoT applications with minimal effort by various stakeholders* involved in

development process”

**Development -- “a set of related activities that leads to a production of a software product.’’ [Ian Sommerville, Software Engineering (9th edition) , 2010]

*Stakeholders in software engineering to mean – people, who are involved in the application development. Examples of stakeholders defined in [Taylor et al., Software Architecture, 2009] are software designer, developer, domain expert, technologist, etc.

7

Outline Application development challenges Existing approaches Contributions Evaluation Summary and future work

8

Application development challenges

Heterogeneity Types of devices (e.g.,

sensor, actuator, storage, processing elements, user interfaces)

Interaction modes (e.g., publish/subscribe, request/response, command)

Platforms (e.g., Android, JavaSE)

Spreads into the application code, Makes the portability of

code difficult

9

Application development challenges

Heterogeneity Large scale

Application logic in terms of a set of distributed tasks for

hundreds to thousands of devices

To reason at such levels of scale is impractical in

general

10

Application development challenges

Heterogeneity Large scale Multiple expertise

Knowledge from multiple concerns intersect

Application domain

Software design

Algorithm design,programming languages

Platform-specific knowledge

Clear conflict with skill possessed by the individual

developer

Deployment area

11

Application development challenges

Heterogeneity Large scale Multiple expertise Different life-cycle phases

Development Deployment

Evolution

Tasks has to be decomposed in a large number of devices

Application - designed/implemented into a set of distributed tasks for heterogeneous devices

Changes in application requirementsChanges in deployed devices

Software development life cycle phases -- requirement analysis, design, implementation, testing, evolution and maintenance [Ian Sommerville, Software Engineering (9th edition) , 2010]

12

Outline Application development challenges Existing approaches Contributions Evaluation Summary and future work

13

Existing approaches

Node-centric programming Think in terms of activities of

individual device & encode interactions

Olympus with Gaia middleware, Context Toolkit, nesC with TinyOS, physical-virtual mashup

Olympus with Gaia [Ranganathan et al., Percom, 2005], Context Toolkit [Dey et al., HCI, 2001], TinyOS [Levis et al., MDM, 2006], Physical virtual mashup [Guinard et al., NSS, 2010]

14

Existing approaches

Node-centric programming

Database approach Queries to SN Collects, aggregates, & sends data to base

station Not flexible to introduce a

customized application logic

TinyDB, Semantic streams, TinyREST, TinySOA

Stakeholder

Base station

queries

collects result

TinyDB [Madden et al., TODS ,2005], Semantic streams [Whitehouse et al., , EWSN, 2006], TinyREST [Luckenbach et al., REALWSN, 2005], TinySOA [Aviles-Lopez , SOCA, 2009]

15

Existing approaches

Node-centric programming Database approach WSN macroprogramming

Abstractions for high-level collaborative behaviors

Lack of software engineering methodology to support life cycle phases – results in difficult to maintain, reuse, and platform-dependent design

Regimant, MacroLab

Regiment [Newton et al., IPSN, 2007], MacroLab [Hnat et al. , SenSys, 2008]

16

Existing approaches

Node-centric programming

Database approach WSN macroprogramming Model-driven

development ATaG, RuleCaster (sensor

network) DiaSuite, PervML,

Pantagruel (pervasive and ubiquitous computing)

Transformation and code generators

PIM

PSM

E.g., J2SE E.g., .Net

PSM…

C1 C2 Cn…

HorizontalSeparation of

Concerns (SoC)

Verticalseparation of

concerns

our work takes inspiration from ATaG, which is a WSN framework to develop SCC applications

ATaG [Pathak et al., DCSN, 2011], RuleCaster [Bischoff et al., EuroSSC, 2006], DiaSuite [Cassou et al., TSE, 2012], PervML [Serral et al., Journal of Pervasive and Mobile computing, 2010], Pantagruel [Drey et al., Percom, 2010]

17

Outline Application development challenges Existing approaches Contributions Evaluation Summary and future work

18

Contributions A comprehensive approach that utilizes

advantages of existing MDD and WSN macroprogramming approaches, while focusing on ease of IoT application development

Set of modeling languages to specify different concerns of IoT applications

Development framework* to integrates modeling languages

and automation techniques*It includes support programs, code libraries, high-level languages or other software that help stakeholders to develop and glue together different components of a software product [Ian Sommerville, Software Engineering (9th edition) , 2010].

19

Commonality at various levels

Functionality (e.g., home

fire detection

Domain

(e.g., building HVAC)

(e.g., Inria Office)

(e.g., GoogleOffice)

Deployment

Room temperatur

e

(e.g. building automation)

“Entities of Interest (EoI) is an object, including the attributes that describes

it, and its state that is relevant from a user or an application perspective.” [Stephan Haller, Internet of Things,

2010]

Building fire state

“Reusabilityacross concerns”

20

Domain

Room temperatur

e

(e.g. building automation)

Actuator

Sensor

User interface

Domain

Storage

Concepts that are responsible for interacting with EoI of a domain- Sensor, actuator,

storage, user interface

Building fire state

21

Domain

Room temperatur

e

(e.g. building automation)

Functionality

FunctionalityHome fire detection

Building HVAC

Computationalservice

Actuator

StorageSensor

Computationalservice

response

requestpublish/

subscribeConcepts that are responsible for - processing data and taking decisions

Building fire state

command

User interface

22

Domain

Room temperatur

e

(e.g. building automation)

Deployment

Functionality

Inria office

Googleoffice

Deployment

Device

Device

Device

Device

Device Device

Building fire state

Concepts to describe various

properties of devicesActuato

r

Sensor

User interface

Storage

Computationalservice

Computationalservice

response

requestpublish/

subscribe

Home fire detection

Building HVAC

command

23

Domain

(e.g. building automation)

Modeling languages

Functionality

Inria office

Googleoffice

Deployment

Device

Device

Device

Device

Actuator

Sensor

User interface

Storage

Computationalservice

Computationalservice

Home fire detection

Building HVAC

Srijan* Vocabulary

Language (SVL)

Srijan* Architecture

Language(SAL)

Srijan* Deployment

Language(SDL)

*Srijan is the sanskrit word for “creation”, and this word is derived form Srijan toolkit for sensor network macroprogramming in our group.

24

Smart building application

Building 1

RoomAvgTemp

RoomAvgTemp

RoomAvgTemp

FloorAvgTemp

FloorAvgTemp

FloorAvgTemp

BuildingAvgTemp

BuildingAvgTemp

RoomAvgTemp

FloorAvgTemp

Temperaturesensor Monitor

TemperatureSensor

tempMeasurement

Monitor

Display()

25

RegulateTempManager

Heater

Off()SetTemp()

Smart building application

BuildingAvgTemp

RoomAvgTemp

FloorAvgTemp

TemperatureSensor

tempMeasurement

Monitor

Display()

BadgeReader ProfileDB

Proximity

badgeDetectedbadgeDisappeared

profile

User interface

request, command

26

Heater

Off()SetTemp()

ProfileDB

profile

User interface

request, command

Srijan vocabulary language

BadgeReader generate badgeDetected:BadgeDetectedStruct;

TempStruct tempValue: double; unitofMeasurement : String;

ProfileDB generate profile:TempStruct accessed-by badgeID:String;

Heater action Off(); action SetTemp(temp:TempStruct);

User interface request profile(badgeID); command setTemp(temp);

BadgeReader

BadgeDetected

• SVL provides abstractions to specify heterogeneous entities• 1 entity description for many instances and implementations

27

Srijan architecture language

BuildingAvgTemp

RoomAvgTemp

FloorAvgTemp

TemperatureSensor

tempMeasurement

Monitor

Display()

hops:0:Room

hops:0:Floor

hops:0:Building

hops:0:Building

Room

Floor

Building

RoomAvgTemp consume tempMeasurement from hops:0:Room; generate roomAvgTemp:TempStruct; in-region:Room;

Scope of consuming data.Scope of

Deployment

To reduce scale, devices can be grouped based on their spatial relationship

• Cluster head is elected, responsible for processing data of that cluster.

28

BadgeReader ProfileDB

Proximity

badgeDetectedbadgeDisappeared

profile

hops:0:Room

Room

Srijan architecture language

Proximity generate tempPref:TempStruct; consume badgeDetected from hops:0:Room; consume badgeDisappeared from hops:0:Room; request profile(badgeID); in-region:Room;

pub./sub. reques

tresponse

To facilitate, SAL provides abstractions to manage heterogeneous interactions

Computational service may compose multiple activities.

29

Domain

Room temperatur

e

(e.g. building automation)

Srijan deployment language

Functionality

Inria office

Googleoffice

Deployment

Device

Device

Device

Device

Device Device

Building fire state

SDL provides abstractions to describes various properties of devices

Actuator

Sensor

User interface

Storage

Computationalservice

Computationalservice

response

requestpublish/

subscribe

Home fire detection

Building HVAC

30

Deployment specification

Device1: region: Building:15 ; Floor:11; Room:1; resources:TemperatureSensor, Heater; type:JavaSE;

Device2: …

Device3:…

Location of device

Type platform a device runs on

31

Summary of modeling languages Srijan vocabulary language

Abstractions for heterogeneous entities of domain 1 entity description for potentially many

implementations and instances Srijan architecture language

Use domain to specify functionality in global manner Abstractions for processing elements &

heterogeneous interactions, scope constructs to enable scalable operations

Srijan deployment language Use domain concepts to specify device details

(individually)

32

Contributions

Set of modeling languages to specify different concerns of IoT applications

Development framework* to integrates modeling languages and automation techniques

*It includes support programs, code libraries, high-level languages or other software that help stakeholders to develop and glue together different components of a software product [Ian Sommerville, 9th edition, 2010].

33

Domain & Functional concern

Domain expert

Vocabulary

spec.

Compilationof

vocabulary

Architecture

spec.

Software designer

Computationalservice

Computationalservice

Software designer – understands software architecture concepts

StorageSensor

retrievalsensor measurement

Actuator

action

User interfacerequest/command/

action

SAL

Domain expert (e.g. biologist, medical system designer) understands domain concepts.SVL

34

Domain expert

Vocabulary

spec.

Compilationof

vocabulary

Architecture

spec.Compilation

of architecture

Application developer

Architecture

framework

Software designer

Functional concern

Application logic

Application developer – skilled in algorithm design & use of programming lang.

Architecture framework (in object-oriented GPL)- Contains abstract classes

- Concrete methods- Abstract methods

35

Proximity generate tempPref:TempStruct; consume badgeDetected from hops:0:Room; consume badgeDisappeared from hops:0:Room; request profile(badgeID); in-region : Room;

Compiler

generates

private String partitionAttribute = "Room"; public void subscribebadgeDetected() {

PubSubMiddleware.subscribe(this, "badgeDetected", subscriptionCondition);} public void notifiedReceived (String event Name, Object arg, Device deviceInfo) { if (eventName.equals(“badgeDetected”) { onNewBadgeDetected((BadgeDetectedStruct) arg) ; }}

public abstract void onNewBadgeDetected (BadgeDetectedStruct arg);

Implementing application logic

Concrete method

forSubscripti

onrequest Concrete method

forReceivingnotificatio

ns

separation application logic & interaction code, known location for application logic

36

Domain expert

Vocabulary

spec.

Compilationof

vocabulary

Deployment spec.

MapperNetworkmanager

Mapper – decides device where each computational service will be executing

Deployment concern

Mapping

files

Architecture

spec.Compilation

of architecture

Application developer

Application logic

Architecture

framework

Software designer

Understands the specific target areaSDL

37

Domain expert

Vocabulary

spec.

Compilationof

vocabulary

Device develop

er

Device driver

Vocabulary

framework

Deployment spec.

MapperNetworkmanager

Mapping

files

Platformconcern

Architecture

spec.Compilation

of architecture

Application developer

Application logic

Architecture

framework

Software designer

• Device developer – understands inputs/outputs, protocols of device platform

Vocabulary Framework• Abstract classes with

concrete methods, interfaces

38

Domain expert

Vocabulary

spec.

Compilationof

vocabulary

Device develop

er

Device driver

Vocabulary

framework

Architecture

spec.Compilation

of architecture

Deployment spec.

Mapper

Application developer

Application logic

Architecture

framework

Software designer

Networkmanager

Linker

Android devices

PC

PC

Mapping

files

Linking

Combines and packs the code generated by various stages into packages that can be deployed on devices.

39

Summary of development framework Promotes suitable division of work among

stakeholders

Separates development in different concerns (deal with each individually at evolution, enables reusability across IoT applications)

Integrates a set of modeling languages & supports automation techniques to reduce development effort

Defines a sequence of steps to follow to develop IoT applications

40

Outline Application development challenges Existing approaches Contributions Evaluation Summary and future work

41

Evaluation Goal : To describe how well approach

addresses our aim in a quantitative manner.

Development effort : indicates effort required to create an application

Reusability : indicates reuse of specifications and implementations across applications

42

Development effortVocabulary spec.

2%

Architecture spec.1% Deployment

spec. 4%

Device driver5%

Application logic6%

Generated code*82%

Code coverage** : 92.22%

*Lines of code using Metrics 1.3.6 Eclipse plugin, **Code coverage using EclEmma Eclipse plug-in.

43

Fire detection application

RoomFireState

Activate( )

Alarm User interface

GetNotification( )

TemperatureSensor

tempMeasurement

Smoke Detector

Smokepresence

RoomAvgTemp

Smoke detector

Temperature sensor Alarm User

interface

FloorFireState

BuildingFireControll

er

Building

RoomFireState

RoomFireState

RoomFireState

FloorFireState

Building FireControlle

r

FloorFireState

FloorFireState

hops:0:Room

hops:0:Room

hops:0:Room

hops:0:Floor

hops:0:Building

hops:0:Building

hops:0:Building

Room

Floor

Building

Room

44

Reusability

Handwritten Lines of code

Domain Applications

Vocab.

spec.

Arch.spec.

Deploy. spec.

Application

logic

Device driver

Development effort

BuildingAutomatio

n

Smart building 55 28 81 131 151 446

Fire detection 21 72 93

45

Outline Application development challenges Existing approaches Contributions Evaluation Summary and future work

46

Summary Application development challenges:

Heterogeneity, large scale, multiple expertise, different life cycle phases

Existing approaches Node-centric programming, database, WSN

macroprogramming, model-driven development Our approach

Separation of concerns, modeling languages, automation, development framework

Evaluation Reduce development effort

47

Future work Supporting testing phase of application

development Emulates execution before deployment, Identifies conflicts, reducing application debugging

effort. Integration of open source simulator (Siafu?)

Run-time adaptation in IoT applications How changes can be injected into the running

application that would adapt itself accordingly? e.g., when a new device is added, an application

include device and assign a new task to contribute

Backup slides

49

Development effort

Number of

devices

Vocab Spec.

Arch Spec.

DeploySpec.

Device Driver

Application Logic

10 41 28 81 98 131

34 41 28 273 98 131

50 41 28 401 98 131

62 41 28 497 98 131

86 41 28 689 98 131

110 41 28 881 98 131

200 41 28 1601 98 131

300 41 28 2401 98 131

350 41 28 2801 98 131

500 41 28 4001 98 131

Development effort remains constant independent of a number of devices

50

Generated code snippet from high-level specifications Generate (or publish) interaction mode Command interaction mode Request interaction mode

Vocabulary framework Class diagram of vocabulary framework Factory class

51

Proximity generate tempPref : UserTempPrefStrut; consume badgeDetected from hops:0:Room; consume badgeDisappeared from hops:0: Room; request profile(badgeID); in-region : Room; Compiler

generates

protected void setTempPref(UserTempPrefStruct newValue) { PubSubMiddleware.publish("tempPref", newValue, myDeviceInfo);}

Generated code for “generate”

52

RegulateTemp command SetTemp(setTemp) to hops:0: Room; command OffLight() to hops:0: Room; in-region : Room;

Compiler

generates

protected void SetTemp(TempStruct arg) { PubSubMiddleware.sendCommand(“SetTemp", arg, myDeviceInfo);}protected void OffLight() { PubSubMiddleware.sendCommand(“OffLight", arg, myDeviceInfo);}

Generated code for “command’’

53

Proximity generate tempPref : UserTempPrefStrut; consume badgeDetected from hops:0:Room; consume badgeDisappeared from hops:0: Room; request profile(badgeID); in-region : Room; Compiler

generates

protected TempStruct getprofile(String arg) { return (TempStruct) PubSubMiddleware.sendRequest("getprofile", arg, myDeviceInfo);}

Generated code for “request”

54

Class diagram

IBadgeReader

AndroidBadgeReader

BadgeReaderFactory BadgeReader

Implements

Device-specific implementation by device developers

Contains concrete methods

for interacting with other entities

Contains interfaces to implement for device

developer

Provide interface to obtain an instance of different platform-specific device driver implementations without having to know what implementation the concrete class obtains.

55

Implementing device driver

public interface IBadgeReader { public BadgeDetectedStruct getbadgeDetected(); public void getbadgeDetected(ListenerbadgeDetected handler);}

Compiler

generatesDevice

developer implemen

ts interfaces

BadgeReader generate badgeDetected:badgeDetectedStruct;

56

Compiler

generates

public class BadgeReaderFactory { public static IBadgeReader getBadgeReader(String nameBadgeReader) {

if(nameBadgeReader.equals("Android")) return new AndroidBadgeReader(); if (nameBadgeReader.equals(“J2SE"))

return new J2SEBadgeReader(); }}

Generated factory class

BadgeReader generate badgeDetected: badgeDetectedStruct;

57

Iterative development for handing evolution Evolution in functionality Evolution in deployment

Evolution in platform Evolution in domain

Iterative development for change in functionality

1. Adding a computational service2. Removing a computational service3. Extending a functionality of a computational service4. Changing a functionality of an application.

59

Iterative development for change in deployment

Change in Deployment Specification• Adding, removing, or shifting a

device • Change in a target deployment

60

Iterative development for change in platform

Adding new software features

61

Iterative development for change in domain

1. Adding new resources (i.e., sensor, actuator, storage, user interface)

2. Removing resources 3. Extending resources

62

Existing model-driven approaches for IoT

Heterogeneity

Scale Multiple expertise

Life cycle

ATaG [2011]

Partially Yes No Yes

RuleCaster

[2007]

Partially Yes No Yes

PervML[2010]

Yes No Partially Partially(Manual

deployment)

DiaSuite [2011]

Yes No Partially Partially(Manual

deployment)

Pantagruel

[2009]

Partially No Partially Partially(Manual

deployment)

63

RegulateTempManager

Heater

Off()SetTemp()

hops:0:Room

hops:0:Room

Proximity

Room

hops:0:Room

Srijan architecture language

RoomAvgTemp

RoomTempManagerconsume roomAvgTempMeasurement from hops:0:Room;consume tempPref from hops:0:Room;command SetTemp(setTemp) to hops:0:Room;command Off() to hops:0:Room;in-region:Room;

64

Class diagram of domain-specific concepts

Vocabulary

Region Structure

1..* 1..*Resource1..*

1..*

Sensor Actuator Storage User interface

Request

Command

Action

*

*

*Sensor

Measurement Action Retrieval

1..* 1..* 1..*

65

Architecture

Structure* Computational

Service

1..*1..*

Input Output

Consume Generate Request Command

Region1..*

1..* 1..*

Class diagram of functionality-specific concepts

66

Deployment

Device1..*

Resource*

Region

1..*

Class diagram of deployment-specific concepts

67

Smart building application

Building 1

RoomAvgTemp

RoomAvgTemp

RoomAvgTemp

FloorAvgTemp

FloorAvgTemp

FloorAvgTemp

BuildingAvgTemp

BuildingAvgTemp

RoomAvgTemp

FloorAvgTemp

Temperaturesensor Monitor

TemperatureSensor

tempMeasurement

Monitor

Display()

Room

hops:0:Room

hops:0:Floor

hops:0:Building

hops:0:Building

Floor

Building

68

RegulateTempManager

Heater

Off()SetTemp()

Smart building application

BuildingAvgTemp

RoomAvgTemp

FloorAvgTemp

TemperatureSensor

tempMeasurement

Monitor

Display()

hops:0:Room

hops:0:Floor

hops:0:Building

hops:0:Building

hops:0:Room

hops:0:Room

BadgeReader ProfileDB

Proximity

badgeDetectedbadgeDisappeared

profile

hops:0:Room

User interface

Room

Floor

Building

Room

Room

request, command

hops:0:Room