enabling high level application development for internet of things

Enabling High-Level Application Development for Internet of Things

Pankesh Patel, Animesh Pathak, Damien Cassou, and Valerie Issarny

Inria Paris Rocquencourt, France

S-CUBE, 12th June, 2013

Pankesh Patel et. al.2

Outline Characteristics of Internet of Things Application development challenges Related work Our approach

Overview A simple example Evaluation

Conclusions Ongoing and future work


Characteristics of ``things’’ May have sensors

attached May have actuators

attached Can communicate

with other things Can be involved in

information exchange between physical and virtual world


Internet of Things A networked infrastructure that connects

physical and virtual things.

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

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

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


Marriage of sensor network and pervasive computing

Internet of things

Sensor network Pervasive computing

Large Scale Heterogenei

ty

[IoTRoadMap] Antoine de Saint-Exupery, Internet of Things Strategic Research Roadmap, 2009


Multiple application domains

Building Automation

Traffic Control and Management Health-care

Internet of things[IoTSurvey] Luigi Atzori, Antonio lera, Giacomo Morabito, The internet of Things Survey, 2010


Outline Characteristics of Internet of Things Application development challenges Related work Our approach


Conclusion Ongoing and future work


Application Development Challenges

Heterogeneity Types (e.g., sensor, actuator,

storage). Implementations (e.g., android,

iOS). Unit of measurement (e.g., C,

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

Ideally, it should not be the developer's responsibility to handle this heterogeneity.



Heterogeneity Large Scale

Hundreds to thousands of devices equipped with sensors, actuators, storages.

Need of adequate abstractions to present the large scale in suitable manner .



Heterogeneity Large Scale Multiple expertise

Application domain

Software design

Programming Language

Distributed system

Device-specific knowledge

Need of separating all development concerns according to the stakeholders expertise and

skills



Heterogeneity Large Scale Multiple Expertise Poor Automation

Interface hardware and software components

Interface software and middleware components

Deployment Ideally, the glue code should be generated, allowing the stakeholders to focus only on the

application logic.

Distributed Systems(i.e., middleware)

Application logic(e.g., calculating avg.

temperature)

Device drivers(e.g. code for accessing sensor

data from android device)

Application logic(e.g., calculating avg.

temperature)


Outline Characteristics of IoT Application development challenges Related work Our approach




Related work

Approaches Motivation Examples Disadvantages

Database • Provide SQL-like interface

• Address scale for data-collecting application

• TinyDB• Cougar• SINA

• Largely for homogeneous devices

• Missing development life-cycle

Library- or toolkit based

• Offer abstractions to implement applications

• Address heterogeneity partially

• Gaia with Olympus

• Context toolkit

• Lots of glue code• Poor automation at

deployment• No separation of

concerns for stakeholders

• Missing development life-cycle

Model-driven • Raise the level of abstractions in program specifications (in UML/textual language) and transforms into working implementations

• ATaG• DiaSuite• PervML

• Only cover a limited subset of requirements


Application development methodology

Research Challenges

Solution

Multiple expertise Clear division of roles of stakeholders.

Poor Automation Code generators and deployment modules (mapper and linker).

Heterogeneity Abstractions in modeling languages.

Scale Abstractions in modeling language.


Domain Expert

DomainSpecification

Specify

Input

Refer

Output

1 Application domain specification using vocabulary language

• Regions (e.g., room, floor, building)• Sensors (e.g. temp. sensor, smoke

detector)• Actuators (e.g., heater, alarm)• Storages

Domain Specification


Architecture Specification

Application Designer

ArchitectureSpecification

2

Domain Expert

VocabularySpecification

1

Architecture specification using architecture language.• Computational components (e.g.,

calculating avg. temp, detecting fire)• Interactions among computational

components

Specify

Input

Refer

Output


Implementing Software Component

System Designer


2

ApplicationLogic

ApplicationDeveloper

FrameworkGenerator

ApplicationFramework

34

Domain Expert


1

Generated application framework in general purpose language.

Application developers writes application logic (e.g. Java code for calculating avg. temp. ) on top of programming framework.

Specify

Input

Refer

Output


Target Deployment Specification

System Designer


2

ApplicationLogic


FrameworkGenerator


4

NetworkManager

Deploymentdescription

Domain Expert


1

3

5

Target deployment using deployment language.• Device region • Device properties

• Type ( android, Sunspot)• Name • Mobile ( true or false) • Identification

Specify

Input

Refer

Output


Mapping

ApplicationDesigner


2

ApplicationLogic


FrameworkGenerator


34

NetworkManager

5

Networkdescription

Mapper

Mapping files

6

Decides the specific device where each software component will be running.

Domain Expert


1

Specify

Input

Refer

Output


Writing Device-Drivers

ApplicationDesigner


2

ApplicationLogic


FrameworkGenerator


34

NetworkManager

5


Mapper

Mapping files

6

Domain Expert


1

DeviceDeveloperDevice

Drivers

7

Writes device drivers • sensor driver• actuator driver• storage driver

Specify

Input

Refer

Output


Linking

ApplicationDesigner


2

ApplicationLogic


FrameworkGenerator


34

7


Drivers

NetworkManager

5


Mapper

Mapping files

6

System Linker

8Combines the generated code into the actual code to be deployed on the real devices.

Domain Expert


1

Specify

Input

Refer

Output


Application development methodology

ApplicationDesigner


2

ApplicationLogic


FrameworkGenerator


34

7


Drivers

NetworkManager

5


Mapper

Mapping files

6

System Linker

8

Domain Expert


1

Specify

Input

Refer

Output

Example: Smart Buildings


Smart Buildings

Building 1

Alarm

Building 2

Building 3


Smart Buildings

Building 1

Smoke detector Temperature sensor

Fire Computation

Fire Computation

Fire Computation

Alarm

TemperatureSensor

Smoke Detector

FireState

FireState

FireState

Fire Computation

Fire State

Fire Detect

FireDetect

Alarm

Room

Floor

InformationSources

(E.g., Sensor, Storage)

Computationalcomponents

On( )

tempMeasurement

SmokePresence

Actuators(e.g., alarm, twitter )

Building


Domain Specification: Information sources

TemperatureSensor

Smoke Detector

Fire Computation

Fire State

FireDetect

Alarm

Room

Building

Floor

InformationSources



On( )

tempMeasurement

SmokePresence

TempStruct tempValue : double ; unitOfMeasurement : String ;

TemperatureSensor generate tempMeasurement: TempStruct;

• One entity description for many implementations (e.g., Android, SunSpot).

• One entity description for many instances.



Domain Specification: Actuators

TemperatureSensor

Smoke Detector

Fire Computation

Fire State

FireDetect

Alarm

Room

Building

Floor

InformationSources



On( )

tempMeasurement

SmokePresence

Alarm action On();



Architecture Specification: computational components

TemperatureSensor

Smoke Detector

Fire Computation

Fire State

FireDetect

Alarm

Room

Building

Floor

InformationSources



On( )

tempMeasurement

SmokePresence

FireComputation consume tempMeasurement from hops : 0 : Room; consume smokePresence from hops : 0 : Room; generate FireComputation : FireStruct ; in-region : Room

Scope of consuming data.

Scope of Deployment

Scope of consuming and scope of deployment enables hierarchical clustering.



Generating framework and implementing application logic

FireComputation consume tempMeasurement from hops : 0 : Room; consume smokePresence from hops : 0 : Room; generate FireComputation : FireStruct ; in-region : Room

public void notifiedReceived (String event Name, Object arg, Device deviceInfo) { if (eventName.equals(“tempMeasurement”) { onNewSmokePresence ((TempStruct) arg) ; }}

public abstract void onNewSmokePresence(TempStruct arg);

Compiler

generates

Programmer

implements

application logic

Pankesh Patel et. al.

Evaluation of our approach (1/2)

31

Goal of our evaluation:• To demonstrate the advantage of our approach over manual

application development approach.

Component Type

Office environment application

Fire Detect

Sensing Temperature Sensor,BadgeReader

Temperature SensorSmoke Detector

Actuating HeaterMonitor

Door, Alarm, SprinklerSystem, Light

Storage ProfileDB -

Computational RoomAvgTemp,FloorAvgTemp,BuildingAvgTemp,Proximity,RegulateTemp,DisplayTemp

HouseFireComputation,HouseFireComputation,HcFireComputation,HouseFireControllerHcFireController

Pankesh Patel et. al.

Evaluation of our approach (2/2)

32

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

Development efforts:• It is directly proportional to the lines of code. • The more hand-written lines of code there is, the efforts

required to develop application is longer.

Specification7% Application

logic10%

Device Drivers

9%

Generated code*74%

Lines of Code

Office environment management

Executed code**90.7 %

Fire Detect

Specification7% Application

logic9%

Device drivers12%

Generated code72%

Lines of code

Executed code**93.7 %


ConclusionChallenges Solved in our approach

Abstracting Heterogeneity

• Vocabulary language (Different types of resources , Different types of implementations)

• Architecture language (different types of interactions)

Abstracting Scale • Architecture and vocabulary language ( Scope constructs)

Multiple Expertise • Separation of concern

Poor Automation • Compiler generates Programming framework, mapper and linker module


Ongoing and future work Evaluation

Current evaluation is preliminary.

Need to look at Reusability Expressiveness of our

modeling languages. Development efforts on

real devices and real middleware


Ongoing and future work Evaluation Development life-

cycle and future changes Change in application

requirements Change in

deployment infrastructure

Evolution in device drivers

Design

Implementation

Deployment

Future changes

Pankesh Patel38


cycle and future changes

End-user applications Originator: an user

triggers an event or query to the application.

Recipient: an user is notified a final results by the application.

Abstractions for specifying end-user interfaces.

Possible User interface description languages (UIDLs) to look UIML UsiXML XUL Others



cycle and future changes

End-user applications Integrated Toolkit

Eclipse plugin for the stakeholders involved in application development process


Thanks for listening to me [email protected]

enabling high level application development for internet of things

Education