Application development for the internet of things

Application Development for the Internet of Things

Pankesh Patel24th January, 2013

Outline• Characteristics of IoT• Application development challenges• Related work • Contribution• Conclusion• Ongoing and future work

Characteristics of ``things’’ • May have sensors attached• May have actuators attached• Can communicate with other

things • Can be involved in the information

exchange between ``physical’’ and ``virtual’’ worlds

3

Marriage of sensor network and pervasive computing

Sensor network Pervasive computing

Internet of things

Large Scale Heterogeneity

Multiple levels[IoTSurvey]

Internet of Things

Smart Environment Transportation

Domain

[IoTSurvey] L. Atzori, A. Iera, and G. Morabito. The Internet of Things: A Survey. Computer Networks, 54:2787–2805, 2010.

HVAC Detecting FireApplication

INRIA office Google Office

Deployment

…Health-care

Outline

• Characteristics of IoT• Application development challenges• Related work • Contribution• Conclusion• Ongoing and future work

Heterogeneity of the devices

• Different types of sensors and actuators (e.g., temp. sensor, badge reader)

• Different implementations (e.g., Android, iOS).

• Different interaction modes (pub/sub, req./resp., command)

• Different data unit (e.g., ‘C, ‘F)

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

Large scale• Hundreds to thousands of devices

equipped with sensors and actuators• Reasoning such a scale is not

feasible/practical.

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

No separation of concerns

Internet of Things Application

Domain-specific featuresMiddleware specific

features

Wide range of hardware and software entities,

running on specific platforms

All concerns are largely coupled into the application logic.

Need of separating all these concerns to enable reusability.

Lots of glue code• The stakeholders have to write lots of glue code

apart from an application logic:– Interface hardware and software components– Interface software components and middleware.– mapping code for device and software component

Ideally, the glue code should be generated, allowing the stakeholders to focus only on the application logic.

Life-cycle and future changes

– Development: The application logic has to be analysed and separated into a set of distributed tasks for the underlying network.

– Deployment : The tasks have to be implemented for the specific hardware.

– Evolution: future changes in the infrastructure and application requirements.

Covering application development life-cycle

Summary

• An approach1. Covers all application development stages 2. Links IoT development concerns3. Supports modeling language (abstracts

heterogeneity and scale)4. Provides automations at all stages

Outline

• Characteristics of IoT• Application development challenges • Related work• Contribution• Conclusion• Ongoing and future work

Related workApproaches Motivation Examples Disadvantages

Database •Provide SQL-like interface,•Address scale for data-collecting application

TinyDB, Cougar, SINA • Only 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,•No separation of concerns •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

Outline

• Characteristics of IoT• Application development challenges• Related work • Contribution• Conclusion• Ongoing and future work

Contributions…

Conceptual model 1Captures concepts and associations to represent the IoT applications

Development concerns2• separation of concerns,•Promotes re-usability

Classification of concepts

A set of modeling languages

are specified in

•Abstracts heterogeneity,•Abstracts large scale,•Parameterized with domain

3

4 A multi-stage model-driven approach for IoT

• Supports application development stages• Links IoT development concerns•Supports automations at all stages

are combined in

17

Software Component

It encapsulates system’s functionalities, provides interface.

End-user Application

Storage Service

Computational service

Driver

ExtendsExtends Extends Extends

Sensor Driver

ActuatorDriverUser Store

Provides access to

Interacts with

1

1..*1

1

Communicates-with

11..*

Informationconsumes

generates

1 1..*

11

ExtendsExtends

Traditional Internet concepts

``Things’’- orientedconcepts

Our IoT Conceptual Model (1/2)

Our IoT Conceptual Model (2/2)

18

Entity of Interest Phenomenon

affects

Actuator

Actuator Driver

actuates

Command

consumes

Sensor

Observes

Sensor Driver

accesses

Sensor Measurement

generates

Consists of

Resource

DeviceHosts

User

Software Component

Runs-on

End-user Application

Storage Service

Store

Computational Service

Driver

Information

IoT applications and its development concerns

IoT Applications

Domain Application

Deployment* Infrastructure

• Sensor,• Actuator,• Storage

• Computational Service,• End-user application

• Sensor Driver,• Actuator Driver,• Storage Service

• Device

* I am in process of identifying a suitable name. The name could be “physical”.

This concern describes the concepts that are specific to the application domain (e.g., building automation, transport)

This concerns describes how the software components are connected for specifying the application logic.

This concerns supply information about how the devices are grouped and physically distributed.It refers to underlying platform specific-components.

20

Storage

Actuator

Sensor

ComputationalService

Observes Phenomenon

(e.g., TemperatureSensor )

Stores info.about

Phenomenon(e.g., User’s Preferences)

AffectsPhenomenon(e.g., Heater)

ComputesInformation and

take decision(e.g., Calculate Avg) Sensor

Measurement

Information/ command

action



Device

Device

DeviceVocabulary Lang.(Domain)

Vocabulary Lang.(Domain)

Deployment Lang.

(Deployment)Architecture Lang.(Application)

Vocabulary Language (1/2)

21

structs: TempStruct

tempValue : double; unitOfMeasurement : String;resources: sensors: TemperatureSensor generate tempMeasurement : TempStruct; actuators: Heater action Off(); action SetTemp(setTemp: TempStruct); storages: ProfileDB

generate profile : TempStruct accessed-by badgeID : String;

One resource description for many instances.

One resource description for many implementations.

As a first step of abstracting heterogeneity, sensing and actuating entities are specified in high-level manner.

To address scalable operations within IoT system, hierarchical clustering should be specified [SINA].

22

regions: Building : Integer; Floor : Integer; Room : Integer;

[SINA] Srisathapornphat, C. and Jaikaeo, C. and Shen, C. , Sensor information networking architecture and applications, 2001

Building:03

Floor: 10 Floor: 15...

Room: 5 Room: 6

Vocabulary Language (2/2)

Use of region construct:• Enables system partition at logical level • Defines scope from which software components will

produce/consume data

Architecture Language

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

23

TemperatureSensor

RoomAvgTemp

Scope of consuming data.

Scope of deployment

EnablesHierarchicalClustering

tempMeasurement

avgTemp

hops:0:Room

In-region : room

Deployment Language

24

Temperature-Sensing-Device : region : Building : 15 ; Floor : 11; Room : 0; abilities : TemperatureSensor; type : sunspot;

Badge-Scanner : region : Building : 15 ; Floor : 11; Room : 0; abilities : BadgeReader ; type : android;

Device Name

Attached sensor/ actuator/storage

with device

Vocabulary Specification

Domain Expert

VocabularySpecification

25

Specify

InputRefer

Output

1Vocabulary Specification using Vocabulary Language

• Sensor• Actuator• Storage

Architecture Specification

Application Designer

ArchitectureSpecification

He defines architecture of an application using Architecture Language.

• Computational service• End-user application

2

26

Specify

InputRefer

Output

Domain Expert


1

Implementing Software Component

System Designer


2

27

Specify

InputRefer

Output

ApplicationLogic

ApplicationDeveloper

FrameworkGenerator

ApplicationFramework

34

It allows application developers to focus on software component logic.

Domain Expert


1

Target Deployment Specification

System Designer


2

28

Specify

InputRefer

Output

ApplicationLogic


FrameworkGenerator


4

NetworkManager

Networkdescription

He specifies target deployment scenario using Deployment Language.

•Device

Domain Expert


1

3

5

Mapping

ApplicationDesigner


2

29

Specify

InputRefer

Output

ApplicationLogic


FrameworkGenerator


34

NetworkManager

5

Networkdescription

Mapper

Mapping files

6

It decides the specific device where each software component will be running.

Domain Expert


1

Writing Device-Drivers

ApplicationDesigner


2

30

Specify

InputRefer

Output

ApplicationLogic


FrameworkGenerator


34

NetworkManager

5

Networkdescription

Mapper

Mapping files

6

Domain Expert


1

DeviceDeveloperDevice

Drivers

7

He writes device drivers • sensor driver• actuator driver• storage service

Linking

ApplicationDesigner


2

31

Specify

InputRefer

Output

ApplicationLogic


FrameworkGenerator


34

7

DeviceDeveloperDevice

Drivers

NetworkManager

5

Networkdescription

Mapper

Mapping files

6

System Linker

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

Domain Expert


1

DefiningApplication

concern

32

DefiningDomain Concern

Defining deployment

concern

Defining infrastructure

concern

Compiler

Change in Any requirements?

E.g., Adding a new applications in the existing infrastructure.E.g., Moving an application from one deployment to other.E.g., Implementing and plugging new device drivers.

Maintenance and evolution(1/2)

Maintenance and evolution(2/2)1. Change in vocabulary specification2. Change in architecture specification3. Change in network specification

Spec. Initially generated framework

Implementation(Application logic)

Initially generated framework

Change inSpec.

Compile timeerrors

Modified Impl.

Preserves previous application logic and replaces the generated

framework

ConclusionRequirements Solved in our approach

Abstracting Heterogeneity

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

• Architecture language ( different types of interactions)AbstractingScale

• Architecture and vocabulary lang. (system-level) • Scope constructs

Separation of concern • Conceptual model , capturing concepts and association • Classification of development concerns (enabling reusability)

Automation in development

Code generation and task mapping techniques

Covering application development stages

• Links development concerns• Supports automation in software development• Combines modeling languages• Supports for each stage of application development

End-user interactions with devices

• The end-user is going to play a major role in the IoT applications.– Originator: an user triggers an event or query to

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

application.– Intermediary: an user is prompted as required.

We will provide abstractions to specify these users’ interactions with applications.

Mobility of devices**

• The current version of our modeling language considers only static topology where the devices do not move once they are deployed.

We will support mobile devices in our future version of modeling languages.

** I am investigating this future challenge.

Evaluating expressiveness of modeling languages

• It explores the subset of IoT applications characteristics that may be suitably developed in the framework.

What are the characteristics of IoT applications that can modeled by our approach ?

Evaluating development effort in the real-world

• It evaluates the time required to develop an application.

• To measure the development effort, we plan to give our framework to our lab members with a suitable application.

• From this experiment, we will measure the total time to develop an application.

Tentative time-lineMonth

FebruaryMarch

AprilMayJuneJulyAugustSeptemberOctober

Presentation preparationThesis defense

TODO list

(1) Journal paper submission (2) Finish future work

Thesis Writing and Thesis submission

What will an Intern do with the help of me ? (next slide)

What will an Intern do ?

1. The intern will implements different applications using our framework.

– Outcomes:• Expressiveness of our approach• Bugs identification and fix

2. The intern will implement a wrapper between our framework and a middleware.

– Outcomes:• Prototype implementations in real-world.

3. The intern will write a documentation of our approach on web-pages.

– Outcomes:• It will guide the developers to develop IoT applications.• It will help our future PhD students to further extend this work.

Application development for the internet of things

Documents

Transcript of Application development for the internet of things