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
alarmsSmoke
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 andVisualization
(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
image credit to organizations, who own copyrights of used images
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
image credit to organizations, who own copyrights of used images
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
image credit to organizations, who own copyrights of used images
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], ContextToolkit [Dey
et al., HCI, 2001], TinyOS [Levis et al., MDM, 2006], Physical virtual mashup
[Guinard et al., NSS, 2010]
image credit to organizations, who own copyrights of used images
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]
image credit to organizations, who own copyrights of used images
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]
image credit to organizations, who own copyrights of used images
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*
Entity	of	
Interest	
Storage	 Sensor	
Observes	
Resource	
Extends	
Device	
Actuator	
Stores	Affects	
Extends	 Extends	
Hosts	
Software	
Component	
Runs‐On	
Actuator	
Driver	
Storage	
Driver	
Sensor	
Driver	
Accesses	Accesses	Actuates	
Extends	 Extends	 Extends	
Computational	
Component	
Extends	
Communicates‐With	
End‐user	
Application	
Interacts‐with	
Extends	
Cloud		
Service	
Extends	
In‐Built	 Custom	
Extends	 Extends	
Periodic	
Sensor	
Event‐Driven	
Sensor	
Conceptual model for IoT applications
Request	
Sensor	
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
image credit to organizations, who own copyrights of used images
Domain
17
Domain
Room
temperature
(e.g. building
automation)
Actuator
Sensor Storage
Concepts that are responsible
for interacting with EoI of a
domain
- Sensor, actuator, storage
Building fire
state
image credit to organizations, who own copyrights of used images
Functionality
18
Domain
Room
temperature
(e.g. building
automation)
Functionality
Home fire
detection
Building
HVAC
Computational
service
Actuator
StorageSensor
Computational
service
responserequest
publish/
subscribe
Concepts that are responsible for
- processing data and taking decisions
Building fire
state
command
image credit to organizations, who own copyrights of used images
Deployment
19
Domain
Room
temperature
(e.g. building
automation)
Functionality
Deployment
Device
Device
Device
Device Device
Building fire
state
Concepts to describe various
properties of devices
Actuator
Sensor Storage
Computational
service
Computational
service
responserequest
publish/
subscribe
Home fire
detection
Building
HVAC
command
ABB- BTP
office
ABB-Peenya
office
image credit to organizations, who own copyrights of used images
Modeling
languages
20
Domain
(e.g. building
automation)
Functionality
ABB- BTP
office
ABB-Peenya
office
Deployment
Device
Device
Device
Device
Actuator
Sensor Storage
Computational
service
Computational
service
Home fire
detection
Building
HVAC
Vocabulary
Language (VL)
Architecture
Language
(AL)
Deployment
Language
(DL)
image credit to organizations, who own copyrights of used images
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
image credit to organizations, who own copyrights of used images
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
badgeDetected
badgeDisappeared
ProfileDB
profile
Proximity
Heater
off()
setTemp()
Temperature
Controller
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
Temperature
Controller
badgeDetected
badgeDisappeared
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
Temperature
Controller
badgeDetected
badgeDisappeared
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
badgeDetected
badgeDisappeared
ProfileDB
profile
Proximity
Heater
off()
setTemp()
Temperature
Controller
image credit to organizations, who own copyrights of used images
Functional
concern
26
Domain
expert
Vocabulary
spec.
Compilation
of vocabulary
Architecture
spec.
Software designer
Software designer – understands
software architecture concepts,
Specifies computational components
using Architecture language
Badge
Reader
ProfileDB
profile
Heater
off()
setTemp()
Proximity
Temperature
Controller
badgeDetected
badgeDisappeared
image credit to organizations, who own copyrights of used images
Functional
concern
27
Domain
expert
Vocabulary
spec.
Compilation
of vocabulary
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
image credit to organizations, who own copyrights of used images
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.
image credit to organizations, who own copyrights of used images
Deployment
concern
29
Vocabulary
spec.
Compilation
of vocabulary
Deployment
spec.
Mapper
Network
manager
Mapper – decides device where each computational
service will be executing
Mapping
files
Compilation
of architecture
Application
developer
Application
logic
Architecture
framework
Software designer
Domain
expert
Architecture
spec.
Parser
Mapping
Algorithm
Code
Generator
Deployment
Spec.
Architecture
Spec.
Mapping
files
Mapper
Data
structures
Mapping
decisions
image credit to organizations, who
own copyrights of used images
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.
Compilation
of vocabulary
Device
developer
Device driver
Deployment
spec.
Mapper
Network
manager
Mapping
files
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
Device Driver
Sensing/actuating
framework
Vocabulary
frameworkDomain
expert
Architecture
spec.
image credit to organizations, who
own copyrights of used images
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
image credit to organizations, who
own copyrights of used images
Linking
33
Domain
expert
Vocabulary
spec.
Compilation
of vocabulary
Architecture
spec. Compilation
of architecture
Deployment
spec.
Mapper
Application
developer
Application
logic
Architecture
framework
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
image credit to organizations, who
own copyrights of used images
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
(Meeting
Room)
Application1: Personalized HVAC in Bedroom
36
Badge
Reader
badgeDetected
badgeDisappeared
ProfileDB
profile
Proximity
Heater
off()
setTemp()
Temperature
Controller
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 -
Temperature
Controller
-
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%
Generat
ed LoC
63%
Provided
Wrapper
with
Runtime
System
LoC
21%
Code Coverage: 84%
38
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
(Meeting
Room)
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()
Device2Device1
Device3
Device4
Device5
Device6
6 entities communicating
over MQTT protocol.
6 devices simulated on a
single PC.
Entities Name Platform
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
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
(Meeting
Room)
Implement “Fire Mgmt.”
application in Room (1-3)
0
20
40
60
80
100
120
Fire detection (in
bedroom)
Fire detection (in
kitchen)
Fire detection (in
meeting room)
LinesofCode
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
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
(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
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()
Entities Name Platform
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
LinesofCode
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
Sensor,
Computational,
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
Sensor,
Computational,
Actuator
JavaSE, MQTT Event-driven,
Periodic,
Command
Static 24
Technological change support (1/2)
1/22/201650
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/201651
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:
dr.pankesh.patel@gmail.com
sanjay.chaudhary@ahduni.edu.in
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.
55

SRCenabling application development for the internet of things

  • 1.
    Enabling Application Development forthe 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
  • 2.
    Growing number of‘things’ 2 Temperature sensors Fire alarmsSmoke 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/
  • 3.
    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
  • 4.
    Internet of Thingsbrings 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 andVisualization (e.g., collecting user’s activity through phone and health recommendation )
  • 5.
    Goal 5 “Enable development** ofIoT 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.
  • 6.
    Challenges 6  Heterogeneity  Typesof 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 image credit to organizations, who own copyrights of used images
  • 7.
    7  Heterogeneity  Largenumber  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 image credit to organizations, who own copyrights of used images Challenges
  • 8.
    8  Heterogeneity  Largenumber  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 image credit to organizations, who own copyrights of used images Challenges
  • 9.
    9  Heterogeneity  Largenumber  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
  • 10.
    Existing approaches 10  Node-centricprogramming  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], ContextToolkit [Dey et al., HCI, 2001], TinyOS [Levis et al., MDM, 2006], Physical virtual mashup [Guinard et al., NSS, 2010] image credit to organizations, who own copyrights of used images
  • 11.
    Existing approaches 11  Node-centricprogramming  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]
  • 12.
    Existing approaches 12  Node-centricprogramming  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] image credit to organizations, who own copyrights of used images
  • 13.
    Existing approaches 13  Node-centricprogramming  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] image credit to organizations, who own copyrights of used images
  • 14.
    Contributions… 14  A comprehensiveapproach 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*
  • 15.
    Entity of Interest Storage Sensor Observes Resource Extends Device Actuator Stores Affects Extends Extends Hosts Software Component Runs‐On Actuator Driver Storage Driver Sensor Driver Accesses Accesses Actuates Extends Extends Extends Computational Component Extends Communicates‐With End‐user Application Interacts‐with Extends Cloud Service Extends In‐Built Custom Extends Extends Periodic Sensor Event‐Driven Sensor Conceptual model for IoT applications Request Sensor Extends Extends
  • 16.
    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 image credit to organizations, who own copyrights of used images
  • 17.
    Domain 17 Domain Room temperature (e.g. building automation) Actuator Sensor Storage Conceptsthat are responsible for interacting with EoI of a domain - Sensor, actuator, storage Building fire state image credit to organizations, who own copyrights of used images
  • 18.
    Functionality 18 Domain Room temperature (e.g. building automation) Functionality Home fire detection Building HVAC Computational service Actuator StorageSensor Computational service responserequest publish/ subscribe Conceptsthat are responsible for - processing data and taking decisions Building fire state command image credit to organizations, who own copyrights of used images
  • 19.
    Deployment 19 Domain Room temperature (e.g. building automation) Functionality Deployment Device Device Device Device Device Buildingfire state Concepts to describe various properties of devices Actuator Sensor Storage Computational service Computational service responserequest publish/ subscribe Home fire detection Building HVAC command ABB- BTP office ABB-Peenya office image credit to organizations, who own copyrights of used images
  • 20.
    Modeling languages 20 Domain (e.g. building automation) Functionality ABB- BTP office ABB-Peenya office Deployment Device Device Device Device Actuator SensorStorage Computational service Computational service Home fire detection Building HVAC Vocabulary Language (VL) Architecture Language (AL) Deployment Language (DL) image credit to organizations, who own copyrights of used images
  • 21.
    21 Hello world appin building automation: Personalized HVAC system Badge Reader badgeDetected badgeDisappeared ProfileDB profile Proximity Heater off() setTemp() Temperature Controller Device Device Device Device Device image credit to organizations, who own copyrights of used images
  • 22.
    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 badgeDetected badgeDisappeared ProfileDB profile Proximity Heater off() setTemp() Temperature Controller Device Device Device Device Device • Abstractions to specify heterogeneous entities • One entity description for many instances
  • 23.
    computationalService: Proximity generate tempPref:TempStruct; consume badgeDetectedfrom 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 Temperature Controller badgeDetected badgeDisappeared
  • 24.
    24 Hello world appin building automation: Personalized HVAC system – deployment language Badge Reader ProfileDB profile Heater off() setTemp() Device Device Device Device Device Proximity Temperature Controller badgeDetected badgeDisappeared 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.
  • 25.
    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 badgeDetected badgeDisappeared ProfileDB profile Proximity Heater off() setTemp() Temperature Controller image credit to organizations, who own copyrights of used images
  • 26.
    Functional concern 26 Domain expert Vocabulary spec. Compilation of vocabulary Architecture spec. Software designer Softwaredesigner – understands software architecture concepts, Specifies computational components using Architecture language Badge Reader ProfileDB profile Heater off() setTemp() Proximity Temperature Controller badgeDetected badgeDisappeared image credit to organizations, who own copyrights of used images
  • 27.
    Functional concern 27 Domain expert Vocabulary spec. Compilation of vocabulary Architecture spec. Compilation ofarchitecture Application developer Architecture framework Software designer Application logic Architecture framework (in object-oriented GPL) - Contains abstract classes - Concrete methods - Abstract methods image credit to organizations, who own copyrights of used images
  • 28.
    Implementing application logic 28 Proximity consume badgeDetectedfrom 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. image credit to organizations, who own copyrights of used images
  • 29.
    Deployment concern 29 Vocabulary spec. Compilation of vocabulary Deployment spec. Mapper Network manager Mapper –decides device where each computational service will be executing Mapping files Compilation of architecture Application developer Application logic Architecture framework Software designer Domain expert Architecture spec. Parser Mapping Algorithm Code Generator Deployment Spec. Architecture Spec. Mapping files Mapper Data structures Mapping decisions image credit to organizations, who own copyrights of used images
  • 30.
  • 31.
    Platform concern 31 Vocabulary spec. Compilation of vocabulary Device developer Device driver Deployment spec. Mapper Network manager Mapping files Compilation ofarchitecture 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 Device Driver Sensing/actuating framework Vocabulary frameworkDomain expert Architecture spec. image credit to organizations, who own copyrights of used images
  • 32.
    Implementing device driver 32 public interfaceIBadgeReader { 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 image credit to organizations, who own copyrights of used images
  • 33.
    Linking 33 Domain expert Vocabulary spec. Compilation of vocabulary Architecture spec. Compilation ofarchitecture Deployment spec. Mapper Application developer Application logic Architecture framework 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 image credit to organizations, who own copyrights of used images
  • 34.
    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.
  • 35.
    Example: Home automation 35 Motionsensor 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 (Meeting Room)
  • 36.
    Application1: Personalized HVACin Bedroom 36 Badge Reader badgeDetected badgeDisappeared ProfileDB profile Proximity Heater off() setTemp() Temperature Controller 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 - Temperature Controller - Actuator Heater JavaSE (Simulated)
  • 37.
    Results… Lines of codeusing 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% Generat ed LoC 63% Provided Wrapper with Runtime System LoC 21% Code Coverage: 84%
  • 38.
    38 Motion sensor todetect 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 (Meeting Room) Implement “Fire Mgmt.” application Application2: Fire Mgmt.
  • 39.
    Application2: Fire Mgmt. 39 Smoke Detector smoke Presence Temperature Sensor temperature Measurement Calculate AvgTemp FireState Measurement Fire Controller Alarm activate() deactivate() Device2Device1 Device3 Device4 Device5 Device6 6 entitiescommunicating over MQTT protocol. 6 devices simulated on a single PC. Entities Name Platform Sensor Smoke Detector JavaSE (Simulated) Temperature Sensor JavaSE (Simulated) Computation CalculateAvgTemp - FireState Measurement - FireController Actuator Alarm JavaSE (Simulated)
  • 40.
    Results… 40 • Device drivercode 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%
  • 41.
    Implementing Fire Mgmt.Application 41 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 (Meeting Room) Implement “Fire Mgmt.” application in Room (1-3)
  • 42.
    0 20 40 60 80 100 120 Fire detection (in bedroom) Firedetection (in kitchen) Fire detection (in meeting room) LinesofCode Applications Vocab. Spec. Arch. Spec. Deploy. Spec. Device Driver Application logic Reusability 42 We are assuming that device platforms remain same across deployment.
  • 43.
    Evaluating Reusability… 43 Motion sensorto 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 (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
  • 44.
    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 Heatingcontrol 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
  • 45.
    Reusability 45 We areassuming that device platforms remain same across deployment. For simplicity, we are assuming that one device hosts only one entity.
  • 46.
    Application: Road trafficmonitoring & 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.
  • 47.
    Experiment setup 47 Speed sensor Speed Measurement Presence sensor Presence Measurement Calculate AvgSpeed Calculate AvgQueueLength RampSignal Controller Ramp Signal signal() Entities Name Platform SensorSpeed 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.
  • 48.
    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 LinesofCode Number of Devices Vocab. Spec. Arch. Spec. Deploy. Spec. Device Driver Application logic
  • 49.
    Expressiveness… 49 All application codeis 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 Sensor, Computational, 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 Sensor, Computational, Actuator JavaSE, MQTT Event-driven, Periodic, Command Static 24
  • 50.
    Technological change support(1/2) 1/22/201650 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
  • 51.
    Technological change support(2/2) 1/22/201651 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
  • 52.
    Summary & futurework 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.
    53 Thanks! Email: dr.pankesh.patel@gmail.com sanjay.chaudhary@ahduni.edu.in Implementation of thiswork with documentations, running on both Android and JavaSE device and MQTT runtime system https://github.com/pankeshlinux/IoTSuite/wiki
  • 54.
    State of theart 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.
  • 55.