srcenabling application development for the internet of things

Enabling Application Development for the Internet of Things

Pankesh Patel*, Saurabh Chauhan+, and Sanjay Chaudhary**

* Research Scientist, ABB Corporate Research, Bangalore

+ MTech (CSE) student, Institute of Engineering and Technology

** Professor and Head (Research), Institute of Engineering and Technology, Ahmedabad University

Growing number of ‘things’

2

Temperature sensors Fire

alarms Smoke detectors

Lights

Traffic signals

Water leakage

detector

Smart phones

Parking space controller

Air pollution controllers

Structural health

monitors

HVAC system

Smart car

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

Internet of Things (IoT)

3

“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

Internet of Things brings following behaviors to the mix…

(e.g., personalized HVAC system - user interactions)

image credit to organizations, who own copyrights of used images

Sense-Compute-Control Regular Data Collection (e.g., environment monitoring- cloud

computing)

Data Analytics and Visualization (e.g., collecting user’s activity through phone and health

recommendation )

Goal

5

“Enable development** of IoT applications with minimal efforts 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.

Challenges

6

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

storage, processing elements, user interfaces)

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

Data types (e.g., date, number, time, string, Boolean)

Device properties (e.g., memory, processing constraint, mobile)

Protocols (e.g., MQTT, CoAP) Platforms (e.g., Android, JavaSE) Spreads into the application code, Makes

the portability of code difficult


7

Heterogeneity Large number Application logic in terms of a set of distributed tasks for

hundreds to thousands of devices

To reason at such levels of number is impractical in general


Challenges

8

Heterogeneity Large number 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


Challenges

9

Heterogeneity Large number Multiple expertise Different life-

cycle phases

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

Design: Application logic has to be analyzed and then separated into a set of distributed tasks. Implementations: Application has to be implemented for heterogeneous platforms

Deployment: Tasks of an application have to be decomposed in a (large) number of heterogeneous devices.

Challenges

Existing approaches

10

Node-centric programming Think in terms of activities of individual

devices & explicitly encode their interactions with other devices.

Write a program that reads sensing data from sensing devices, aggregates data pertaining to the some external events, decides where to send it addressed by ID & communicates with actuators if needed

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]


Existing approaches

11

Node-centric programming Database approach Queries to SN Collects, aggregates, & sends data to base station Not flexible to introduce a

customized application logic.

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]

Existing approaches

12

Node-centric programming Database approach Macro-programming 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

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


Existing approaches

13

Node-centric programming Database approach Macro-programming Model-driven development Vertical SoC – reduce app.

development complexity separating PIM and PSM

Horizontal SoC – separate different aspects of a system

Transformation and code generators

PIM

PSM

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

PSM …

C1 C2 Cn …

Horizontal Separation of

Concerns (SoC)

Vertical separation of

concerns

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]


Contributions…

14

A comprehensive approach that utilizes advantages of existing MDD and WSN macro-programming approaches, while focusing on ease of IoT application development.

*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].

Objectives: Separate development into different concerns (reusability) Integrate high-level modelling languages (reduce complexity & effort) Automate development wherever possible (reduce effort)

Development framework*

EntityofInterest

Storage Sensor

Observes

Resource

Extends

Device

Actuator

StoresAffects

Extends ExtendsHosts

SoftwareComponent

Runs‐On

ActuatorDriver

StorageDriver

SensorDriver

AccessesAccessesActuates

Extends Extends Extends

ComputationalComponent

Extends

Communicates‐With

End‐userApplication

Interacts‐with

Extends

CloudService

Extends

In‐Built Custom

Extends Extends

PeriodicSensor

Event‐DrivenSensor

Conceptual model for IoT applications

RequestSensor

Extends

Extends

Commonality at various levels

16

Functionality (e.g., home fire detection

Domain

(e.g., building HVAC)

Deployment

Room temperature

(e.g. building automation)

Building fire state

“Reusability across concerns”

ABB- BTP office

ABB-Peenya office


Domain

17

Domain

Room temperature


Actuator

Sensor Storage

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

Building fire state


Functionality

18

Domain

Room temperature


Functionality Home fire detection

Building HVAC

Computational service

Actuator

Storage Sensor


response request publish/

subscribe Concepts that are responsible for - processing data and taking decisions

Building fire state

command


Deployment

19

Domain

Room temperature


Functionality

Deployment

Device

Device

Device

Device Device

Building fire state

Concepts to describe various properties of devices

Actuator

Sensor Storage



response request publish/

subscribe

Home fire detection

Building HVAC

command

ABB- BTP office

ABB-Peenya office


Modeling languages

20

Domain


Functionality

ABB- BTP office

ABB-Peenya office

Deployment

Device

Device

Device

Device

Actuator

Sensor Storage



Home fire detection

Building HVAC

Vocabulary Language (VL)

Architecture

Language (AL)

Deployment

Language (DL)


21

Hello world app in building automation: Personalized HVAC system

Badge Reader

badgeDetected badgeDisappeared

ProfileDB

profile

Proximity

Heater

off() setTemp()

Temperature Controller

Device

Device

Device

Device

Device


structs: BadgeStruct badgeID: String; badgeEvent:String; TempStruct tempValue: double; unitOfMeasurement: String; resources: sensors: BadgeReader generate badgeDetected: BadgeStruct; generate badgeDisappeared: BadgeStruct; actuators: Heater action Off(); action SetTemp(setTemp: TempStruct); storages: ProfileDB generate profile: tempStruct accessed-by badgeID: String;

22

Hello world app in building automation: Personalized HVAC system – vocabulary language

Badge Reader


ProfileDB

profile

Proximity

Heater

off() setTemp()


Device

Device

Device

Device

Device

• Abstractions to specify heterogeneous entities

• One entity description for many instances

computationalService: Proximity generate tempPref:TempStruct; consume badgeDetected from BadgeReader; consume badgeDisappeared from BadgeReader; request profile; TemperatureController consume tempPref from Proximity; command Off() to Heater; command SetTemp(setTemp) to Heater;

23

Hello world app in building automation: Personalized HVAC system – architecture language

Badge Reader

ProfileDB

profile

Heater

off() setTemp()

Device

Device

Device

Device

Device

Proximity



24

Hello world app in building automation: Personalized HVAC system – deployment language

Badge Reader

ProfileDB

profile

Heater

off() setTemp()

Device

Device

Device

Device

Device

Proximity



Device1: location: Building:15 ; Floor:11; Room:1; type:JavaSE; resources: BadgeReader; Device2: location: Building:15 ; Floor:11; Room:1; type: Android; resources: Heater;

Device3: ...

Type platform a device runs on

Location of device

Property of a device is specified individually – Not scalable.

Domain concern

25

Domain expert

Vocabulary spec.

Compilation of vocabulary

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

Domain concepts using vocabulary language

Badge Reader


ProfileDB

profile

Proximity

Heater

off() setTemp()



Functional concern

26

Domain expert

Vocabulary spec.


Architecture spec.

Software designer

Software designer – understands software architecture concepts,

Specifies computational components using Architecture language

Badge Reader

ProfileDB

profile

Heater

off() setTemp()

Proximity




Functional concern

27

Domain expert

Vocabulary spec.


Architecture spec. Compilation

of architecture Application developer

Architecture framework

Software designer

Application logic

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

- Concrete methods - Abstract methods


Implementing application logic

28

Proximity consume badgeDetected from region-hops:0:Room; partition-per:Room; Compiler

generates

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

public abstract void onBadgeDetectedEvent(BadgeStruct arg);

Concrete method for Subscription

request

Concrete method for Receiving

notifications

Application developer

Structured code: Application Developer has to locate methods to write application logic.


Deployment concern

29

Vocabulary spec.


Deployment spec.

Mapper Network manager

Mapper – decides device where each computational service will be executing

Mapping files

Compilation of architecture


Application logic


Software designer

Domain expert

Architecture spec.

Parser Mapping Algorithm

Code Generator

Deployment Spec.

Architecture Spec.

Mapping files

Mapper

Data structures

Mappingdecisions


Deployment concern

30

computationalService: Proximity … TemperatureController …

Architecture specification

devices: Device1: … Device2: … DeviceN: …

Deployment Specification

Mapper

Device1: Proximity

Device2: TemperatureController

Mapping decision (output in GPL)

Mapping decision (output in GPL)

Platform concern

31

Vocabulary spec.


Device developer

Device driver

Deployment spec.

Mapper Network manager

Mapping files

Compilation of architecture


Application logic


Software designer

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

Vocabulary Framework • Abstract classes with concrete

methods, interfaces

Device Driver

Sensing/actuating framework

Vocabulary framework Domain

expert

Architecture spec.


Implementing device driver

32

public interface IBadgeReader { public BadgeStruct getBadgeDetectedEvent(); public void getBadgeDetectedEvent(ListenerBadgeDetected handler); }

Compiler

generates

BadgeReader generate badgeDetected: BadgeStruct;

public class JavaSEBadgeReader implements IBadgeReader { @Override public BadgeStruct getBadgeDetectedEvent() { // TODO: Write Device Driver } @Override public void getBadgeDetectedEvent(ListenerBadgeDetected handler) { // TODO: Write Device Driver } }

Device developer

implements interfaces


Linking

33

Domain expert

Vocabulary spec.


Architecture spec. Compilation

of architecture

Deployment spec.

Mapper


Application logic


Software designer

Network manager

Linker

Android devices

PC

PC

Mapping files

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

Generated code For Device X

Middleware

Device developer

Device driver

Vocabulary framework

Device Driver

Sensing/actuating framework

Middleware Wrapper


Evaluation

34

Development effort: the effort required to create a new application.

Reusability: the extend to which software artifacts can be

reused during application development. Expressiveness: the characteristics of IoT applications that can

be modeled using our approach.

Technological change support: it indicates the support provided by the approach to change the implementation platform or programming language. While the lines of code metric is useful, a number of limitations have been noted. It depends heavily on programming

languages, styles, and stakeholder’s skills. In view of this, we have combined one of well-known metrics – Code coverage (it defines code which is actually executed, thus it show usefulness of the generated code), with LoC.

Example: Home automation

35

Motion sensor to detect the presence of a moving object

Stove to sense if it is turned on/off

Badge reader

Smoke Detector

Fire alarm

Heater

Data storage

Temperature sensor

Room 2(bedroom)

Room 1 (Kitchen) Room 3

(MeetingRoom)

Application1: Personalized HVAC in Bedroom

36

Badge Reader


ProfileDB

profile

Proximity

Heater

off() setTemp()


Device1 Device2

Device3

Device4

Device5

• 5 entities communicating over MQTT* protocol

*MQTT (Message Queue Telemetry Transport) is a machine-to-machine (M2M)/"Internet of Things" connectivity protocol. It was designed as an extremely lightweight publish/subscribe messaging transport.

• 5 devices simulated on a single PC.

Aim: To demonstrate automation provided by our approach.

Entities Name Platform

Sensor Badge Reader

Android (Simulated)

Storage ProfileDB MySQL Server

Computation Proximity -


-

Actuator Heater JavaSE (Simulated)

Results…

Lines of code using Metrics 1.3.6 Eclipse plug-in. Code Coverage using EclEmma Eclipse plug-in

• While considering code coverage, we wanted to measure code coverage of the generated code , not application logic, written by Application developer, and device driver, written by Device developer.

• Lines of Device driver code vary from one platform to other platform.

• Lines of application logic code

depend on functionalities.

• The other portion of code is unused features (e.g., getters, setters, exception handling, etc.), which was not executed during experiments.

LoC Wriiten

by Stakehold

er 16%

Generated LoC

63%

Provided Wrapper

with Runtime System

LoC 21%

Code Coverage: 84%

38



Badge reader

Smoke Detector

Fire alarm

Heater

Data storage

Temperature sensor

Room 2(bedroom)


(MeetingRoom)

Implement “Fire Mgmt.” application

Application2: Fire Mgmt.

Application2: Fire Mgmt.

39

Smoke Detector

smoke Presence

Temperature Sensor

temperature Measurement

Calculate AvgTemp

FireState Measurement

Fire Controller

Alarm

activate() deactivate()

Device2 Device1

Device3

Device4

Device5

Device6

6 entities communicating over MQTT protocol.

6 devices simulated on a single PC.


Sensor Smoke Detector

JavaSE (Simulated)

Temperature Sensor

JavaSE (Simulated)

Computation CalculateAvgTemp -

FireState Measurement

-

FireController

Actuator Alarm JavaSE (Simulated)

Results…

40

• Device driver code varies from one platform to other platform. • Lines of application logic code depend on functionalities.

LoC Wriiten by

Stakeholder 17%

Application specific

generated LoC 64%

Provided Wrapper

with Runtime

System LoC 19%

Code Coverage: 82%

Implementing Fire Mgmt. Application

41



Badge reader

Smoke Detector

Fire alarm

Heater

Data storage

Temperature sensor

Room 2(bedroom)


(MeetingRoom)

Implement “Fire Mgmt.” application in Room (1-3)

0

20

40

60

80

100

120

Fire detection (inbedroom)

Fire detection (inkitchen)

Fire detection (inmeeting room)

Line

s of

Cod

e

Applications

Vocab. Spec. Arch. Spec. Deploy. Spec. Device Driver Application logic

Reusability

42 We are assuming that device platforms remain same across deployment.

Evaluating Reusability…

43



Badge reader

Smoke Detector

Fire alarm

Heater

Data storage

Temperature sensor

Room 2(bedroom)


(MeetingRoom)

Turned on the alarm if the stove is switched on and when no body in the kitchen – Safety in Kitchen

Manage the heating of the meeting room, depending on the room’s temperature, when room is occupied unexpectedly.

1

2

Applications

44

Stove

Temp Measurement

Motion Sensor

motion Presence

Kitchen State

Alarm

Activate()

Kitchen Controller

Temperature Sensor

Temp Measurement

Motion Sensor

motion Presence

Avg Temperature

Room Occupancy

Heat Regulation

Heater

SetTemp()

Heat Controller

Safety in Kitchen

Heating control system in Meeting room

Turned on the alarm if the stove is switched on and when no body in the kitchen – Safety in Kitchen

Manage the heating of the meeting room, depending on the room’s temperature, when room is occupied unexpectedly.

1 2

Reusability

45 We are assuming that device platforms remain same across deployment. For simplicity, we are assuming that one device hosts only one entity.

Application: Road traffic monitoring & control

46

• Ramp metering: It influences traffic by controlling access to the highway.

One of the techniques to control traffic:

Image credit: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.147.3471&rep=rep1&type=pdf

Usually, this kind of system is divided into disjoint sectors, with each sector usually being controlled depending on the current status of the sector.

• Speed sensors to measure and report the speeds of vehicles.

• Presence sensors to measure and report the presence of vehicles.

• Ramp signals designed to allow or disallow cars onto the highways.

Experiment setup

47

Speed sensor

Speed Measurement

Presence sensor

Presence Measurement

Calculate AvgSpeed

Calculate AvgQueueLength

RampSignal Controller

Ramp Signal

signal()


Sensor Speed Sensor

JavaSE (Simulated)

Presence Sensor

JavaSE (Simulated)

Computation Calculate AvgSpeed

-

Calculate AvgLength

-

RampSignal Controller

-

Actuator Ramp Signal

JavaSE (Simulated) hops:0:Sector

Sector Sector

Sector

hops:0:Sector

hops:0:Sector hops:0:Sector

hops:0:Sector

Entities communicating over MQTT protocol

Devices simulated on a single PC.

Results: large number

48 • Lines of Device driver code vary from one platform to other platform. • Lines of application logic code depend on functionalities.

0

20

40

60

80

100

120

140

160

6 8 10 12 14 18 24

Line

s of

C

ode

Number of Devices

Vocab. Spec. Arch. Spec. Deploy. Spec. Device Driver Application logic

Expressiveness…

49 All application code is available on URL: https://github.com/pankeshlinux

Many solutions exist for developing software in specific application domains (for example HomeOS). Our approach’s applicability is extended to beyond this particular context. Our approach is not limited to one particular domain. It can be applied to various other domain as well.

App. Name

Behaviors Components Platforms Runtime System

Interaction Modes

Topology Network Size

Personalized HVAC

SCC loop

Sensor, Storage, Computational,

Actuator

JavaSE, Android

MQTT Event-driven, Req.-Resp., Command

Static 5

Fire Detection

SCC loop

Sensor, Computational,

Actuator

JavaSE,

MQTT Event-driven, Periodic,

Command

Static 8

Safety In Kitchen

SCC loop


Actuator

JavaSE, Android

iBICOOP Event-driven, Periodic,

Command

Static 5

Collecting Avg. Temp. of Building

Regular data

collection

Sensor, Computational, User Interface

JavaSE,

MQTT Periodic, Command

Static 16

Road Traffic Monitoring & Control

SCC loop


Actuator

JavaSE,

MQTT Event-driven, Periodic,

Command

Static 24

Technological change support (1/2)

1/22/2016 50

Vocabulary Spec.

Architecture spec.

Deployment spec.

Code generator

…

Android Plug-in

JavaSE Plug-in

Data Structures

Parser

JavaSE files

Android files

Others

Others

Implemented in ANTLR, a parser generator from grammar description

StringTemplateEngine, a template engine for generating source code

the system to be specified independently of the platform

Technological change support (2/2)

1/22/2016 51

Generated code For Device X

Runtime System

Middleware Wrapper

Middleware runs on each individual device and provides a support for executing distributed tasks.

Wrapper plugs “generated code for a device” and middleware. It implements interfaces, specified in a support library, specific to a middleware.

The linker produces generated code for a device.

Device Wrapper for MQTT middleware is available at URL: https://github.com/pankeshlinux/IoTSuite-TemplateV2 • Wrapper for iBICOOP middleware is available at URL: https://github.com/pankeshlinux/ToolSuite

Summary & future work

52

Application development challenges Heterogeneity, large number, multiple expertise, different life-cycle

phases Existing approaches

Node-centric programming, database, macro programming, MDD Our approach

Separation of concerns, modeling languages, automation, development framework

Early results: reduce development effort Future work

Short term goals: Integration of cloud-based deployment, integration of CoAP

runtime system (targeted for small low power sensors, switches, valves, etc.)

Long term-goals: Supporting testing phase, mapping algorithm, runtime adoption

53

Thanks! Email:

[email protected] [email protected]

Implementation of this work with documentations, running on both Android and JavaSE device and MQTT

runtime system https://github.com/pankeshlinux/IoTSuite/wiki

State of the art in IoT Application Development

54

Comparison* of our approach with state of the art in IoT application development on various dimensions.

*This work is submitted to GPCE 2015.

srcenabling application development for the internet of things

Education