Application development for the internet of things

Application Development for the
Internet of Things
Pankesh Patel
24th 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

Large
Scale Heterogeneity

Internet of things

Multiple levels[IoTSurvey]
Internet of
Things

Domain
…
Smart Health-care Transportation
Environment

Detecting
Application HVAC
Fire

Deployment

INRIA office Google Office

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

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
Wide range of hardware Domain-specific
and software entities, Middleware specific features
running on specific features
platforms

All concerns are largely coupled
Internet of Things
Application 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 approach
1. Covers all application development stages
2. Links IoT development concerns
3. Supports modeling language (abstracts
heterogeneity and scale)
4. Provides automations at all stages

Related work
Approaches Motivation Examples Disadvantages

Database •Provide SQL-like interface, TinyDB, Cougar, SINA • Only for homogeneous
•Address scale for data- devices
collecting application • Missing development life-cycle

Library- or •Offer abstractions to Gaia with Olympus, •Lots of glue code,
toolkit based implement applications Context toolkit •No separation of concerns
• Address heterogeneity •Missing development life-cycle
partially
Model-driven •Raise the level of abstractions ATaG, Only cover a limited subset of
in program specifications (in DiaSuite, requirements
UML/textual language) and PervML
transforms into working
implementations

Contributions…

Classification
of concepts

1 Conceptual model
Captures concepts and associations 2 Development concerns
to represent the IoT applications
• separation of concerns,
•Promotes re-usability
are specified
in

are combined
in
3 A set of modeling
languages
•Abstracts heterogeneity, A multi-stage model-driven
•Abstracts large scale, 4
•Parameterized with domain
approach for IoT
• Supports application development stages
• Links IoT development concerns
•Supports automations at all stages

Our IoT Conceptual Model (1/2)
It encapsulates system’s
functionalities, provides
interface. Communicates-with

Traditional 1..* 1 consumes 1..*
1 Software
Internet concepts Information
Component 1 generates 1

Extends
Extends Extends Extends
End-user Storage Computational
Driver
Application Service service

Interacts 1 1
Provides
Extends Extends
with access to
1 1..*
Sensor Actuator
User Store Driver Driver

``Things’’- oriented
concepts
17

Our IoT Conceptual Model (2/2)
Entity of Consists of Observes
Phenomenon
Interest

affects
Actuator Sensor

accesses
actuates
Resource Actuator Sensor
Hosts Driver Driver
Device
generates
consumes
Runs-on
Software
Component Command Sensor
Measurement

End-user Storage
Computational Driver
Application Service
Service

Information
User Store

18

IoT applications and its development
concerns
Domain Application
• Sensor, • Computational
• Actuator, Service,
• Storage IoT
• End-user application
Applications

Deployment* Infrastructure

• Device • Sensor Driver,
• Actuator Driver,
• Storage Service

This concerns describesinformation about howspecific to the application
This concern supply howconcepts that components are are grouped
This concerns the the software are the devices connected for
It refers to underlying platform specific-components.
domain (e.g., buildingapplication logic.
specifying the automation, transport)
and physically distributed.

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

Actuator
Vocabulary Lang. Device
action
Affects
Phenomenon
(Domain)
(e.g., Heater)
Information/
Deployment
command Lang.
Architecture Lang.
Computational
Service
(Deployment)
Computational
Device
(Application)
Service
Computes
Information and
take decision Computational
(e.g., Calculate Avg) Sensor Service
Measurement

Observes
Phenomenon
Vocabulary Lang. Device
Sensor Storage Stores info.
(e.g., Temperature
Sensor )
(Domain) about
Phenomenon
(e.g., User’s Preferences) 20

Vocabulary Language (1/2)
As a first step of abstracting heterogeneity, sensing and actuating entities are
specified in high-level manner.

One resource description for
many implementations.

One resource description for many
structs:
instances.
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; 21

Vocabulary Language (2/2)
To address scalable operations within IoT system, hierarchical clustering should
be specified [SINA].
Building:03
regions:
Building : Integer;
Floor : Integer; Floor: 10 ... Floor: 15
Room : Integer;

Room: 5 Room: 6
Use of region construct:
• Enables system partition at logical level
• Defines scope from which software components will
produce/consume data

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

Architecture Language avgTemp In-region
: room

Room
AvgTemp

tempMeasurement
hops:0:Room

Scope of consuming Temperature
data. Sensor

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

Scope of
deployment

23

Deployment Language
Temperature-Sensing-Device : Device Name
region :
Building : 15 ;
Floor : 11;
Room : 0;
Attached sensor/
abilities : TemperatureSensor;
actuator/storage
type : sunspot;
with device
Badge-Scanner :
region :
Building : 15 ;
Floor : 11;
Room : 0;
abilities : BadgeReader ;
type : android;

24

Vocabulary Specification
1
Vocabulary Specification using Vocabulary
Language
Domain Vocabulary • Sensor
Expert Specification • Actuator
• Storage

Specify
Input
Refer
Output

25

Architecture Specification
1
2

Domain Vocabulary
Expert Specification Architecture Application
Specification Designer

He defines architecture of an application
using Architecture Language.

• Computational service
• End-user application

Specify
Input
Refer
Output

26

Implementing Software Component
1
2

Domain Vocabulary
Expert Specification Architecture System

Framework
Generator
3
4

Application Application Application
Developer Logic Framework

Specify
Input
Refer It allows application developers to focus on
Output software component logic.

27

Target Deployment Specification
1
2

Domain Vocabulary
Expert Specification Architecture System

5
Framework
Generator
Network Network
3 description Manager
4

Developer Logic Framework

Specify He specifies target deployment scenario
Input using Deployment Language.
Refer
Output •Device

28

Mapping
1
2

Domain Vocabulary

5
Framework
Generator
Network Network
4 Mapper

6

Developer Logic Framework Mapping
files

Specify
Input
It decides the specific device where
Refer
each software component will be
Output
running.

29

Writing Device-Drivers
1
2

Domain Vocabulary

5
He writes device drivers
Framework • sensor driver
Generator • actuator driver
Network Network
3 • storage service
description Manager
4 Mapper

6

Application Application 7
Application
files
Device
Device Developer
Specify Drivers
Input
Refer
Output

30

Linking
1
2

Domain Vocabulary

5
Framework
Generator
Network Network
4 Mapper

6

Application Application 7
Application
files
Device
Device Developer
Specify Drivers
8 Combines the generated code into
Input
System Linker the actual code to be deployed on
Refer
the real devices.
Output

31

Maintenance and evolution(1/2)
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.

Change in
Any requirements?

Defining Defining Defining Defining
Compiler
Domain Application deployment infrastructure
Concern concern concern concern

32

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

Preserves previous application
logic and replaces the generated
Implementation framework
(Application logic)

Spec. Initially generated Initially generated Change in Compile time Modified
framework framework Spec. errors Impl.

Conclusion
Requirements Solved in our approach
Abstracting • Vocabulary language (Different types of resources , Different
Heterogeneity types of implementations)
• Architecture language ( different types of interactions)
Abstracting • Architecture and vocabulary lang. (system-level)
Scale • Scope constructs
Separation of concern • Conceptual model , capturing concepts and association
• Classification of development concerns (enabling reusability)
Automation in Code generation and task mapping techniques
development
Covering application • Links development concerns
development stages • 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-line
Month TODO list
February (1) Journal paper submission
(2) Finish future work
March

April
May
June
Thesis Writing and Thesis submission
July
August
September Presentation preparation
October Thesis defense

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

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (6)

Semelhante a Application development for the internet of things

Semelhante a Application development for the internet of things (20)

Mais de Pankesh Patel

Mais de Pankesh Patel (17)

Application development for the internet of things