Application development in the Internet of Things (IoT) is challenging because it involves dealing with a wide range of related issues such as lack of separation of concerns, and lack of high-level of abstractions to address both the large scale and heterogeneity. Moreover, stakeholders involved in the application development have to address issues that can be attributed to different life-cycles phases. when developing applications. First, the application logic has to be analyzed and then separated into a set of distributed tasks for an underlying network. Then, the tasks have to be implemented for the specific hardware. Apart from handling these issues, they have
to deal with other aspects of life-cycle such as changes in application requirements and deployed devices.
Several approaches have been proposed in the closely related fields of wireless sensor network, ubiquitous and pervasive
computing, and software engineering in general to address the above challenges. However, existing approaches only cover limited subsets of the above mentioned challenges when applied to the IoT. This work proposes an integrated approach for addressing the above mentioned challenges. The main contributions of this work are: (1) a development methodology that separates IoT application development into different concerns and provides a conceptual framework to develop an application, (2) a development framework that implements the development methodology to support actions of stakeholders. The development framework provides a set of modeling languages to specify each development concern and abstracts
the scale and heterogeneity related complexity. It integrates code generation, task-mapping, and linking techniques
to provide automation. Code generation supports the application development phase by producing a programming
framework that allows stakeholders to focus on the application logic, while our mapping and linking techniques together support the deployment phase by producing device-specific code to result in a distributed system collaboratively hosted by individual devices. Our evaluation based on two realistic scenarios shows that the use of our approach improves the productivity of stakeholders involved in the application development.
Towards application development for the internet of things updated
Towards application development for the internet of things
1. Towards Application Development for
the Internet of Things*
Pankesh Patel
ABB Corporate Research, India
* This research work is partially done at University of Paris VI and French National Institute
for Research in Computer Science & Automation (INRIA), Paris, France
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. Examples
Road traffic monitoring & control
aims to maximize the flow of vehicle on the road
Personalized HVAC system
image credit to organizations, who own copyrights of used images
5. Goal
5
“Enable development** of IoT applications with
minimal effort 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
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. 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. 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. 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
10. 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
11. 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]
12. 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
13. 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
14. Early 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*
15. Commonality
at various levels
15
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
20. 20
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
21. 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;
21
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
22. computationalService:
Proximity
generate tempPref:TempStruct;
consume badgeDetected from region-hops:0:Room;
consume badgeDisappeared from region-hops:0:Room;
request profile;
partition-per:Room;
TemperatureController
consume tempPref from region-hops:0:Room;
command Off() to region-hops:0:Room;
command SetTemp(setTemp) to region-hops:0:Room;
partition-per:Room;
22
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
Scope of
consuming dataScope of
Deployment
To reduce scale, devices can be grouped based on their
spatial relationship
- Cluster head is elected, responsible for processing
data of that cluster.
hops:0:Room
hops:0:Room
Room
Room
badgeDetected
badgeDisappeared
23. 23
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:
region:
Building:15 ;
Floor:11;
Room:1;
type:JavaSE;
resources: BadgeReader;
mobile: false;
Device2:
region:
Building:15 ;
Floor:11;
Room:1;
type: Android;
resources: Heater;
mobile: false;
Device3:
...
Type platform a
device runs on
Location of device
Property of a device
is specified individually – Not scalable.
24. Domain
concern
24
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
31. Implementing
device driver
31
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
32. Linking
32
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
33. Evaluation
33
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.
34. Example: Home automation
34
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)
35. Application1: Personalized HVAC in Bedroom
35
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)
36. 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.
LoCWriiten
by
Stakeholder
16%
Application
specific
generated LoC
63%
Provided
Wrapper with
Runtime
System LoC
21%
Code Coverage: 84%
37. 37
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.
39. Results…
39
• Device driver code varies from one platform to other platform.
• Lines of application logic code depend on functionalities.
LoCWriiten
by
Stakeholder
17%
Application specific
generated LoC
64%
Provided
Wrapper
with
Runtime
System LoC
19%
Code Coverage: 82%
40. Implementing Fire Mgmt. Application
40
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)
41. 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
41
We are assuming that device platforms remain same across deployment.
42. Evaluating Reusability…
42
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
44. Reusability
44 We are assuming that device platforms remain same across deployment.For simplicity, we are assuming that
one device hosts only one entity.
45. Application: Road traffic monitoring & control
45
• 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. Results: large number
47 • 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
48. Expressiveness…
48
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
RoadTraffic
Monitoring &
Control
SCC
loop
Sensor,
Computational,
Actuator
JavaSE, MQTT Event-driven,
Periodic,
Command
Static 24
49. Technological change support (1/2)
6/26/201549
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
50. Technological change support (2/2)
6/26/201550
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
51. Summary & future work
51
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. State of the art in IoT Application
Development
53
Comparison* of our approach with state of the art in IoT
application development on various dimensions.
*This work is submitted to GPCE 2015.