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 paper proposes an integrated approach for addressing the above mentioned challenges. The main contributions of this paper are$\colon$ (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.

1. Enabling High-Level Application
Development for the Internet of Things
Pankesh Patel
PhD defense
25th November, 2013

2. Growing number of ``things”
Smoke
detectors
Air pollution
controllers
Temperature
sensors
Lights
HVAC
system
Fire
alarms
Smart
phones
Structural
health
monitors
2
Image credit: http://www.libelium.com/
Parking
space
controller
Smart Water
car leakage
detector
Traffic
signals

3. Internet of Things (IoT)
“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
3

4. IoT application

Involves a large number of heterogeneous devices,
processing elements

Composes multiple activities

Interacts with users whenever necessary
4

5. Illustrative example: building system
Large numbers of heterogeneous devices
An application - compose multiple
activities (e.g., detect user’s entry ,
query, set threshold)
For situation awareness (e.g.,
avg. temperature of building),
devices involved in collaborative
activities
Temperature
sensor
5
Heater
Smoke
detector
Fire
alarm
Badge
reader
User with
badge
Data
storage
Light
User interfaces
(e.g., display,
mobile phones)

6. Goal
“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

7. Outline
Application development challenges
Existing approaches
Contributions
Evaluation
Summary and future work





7

8. Application development challenges
Heterogeneity




Types of devices (e.g., sensor,
actuator, storage, processing
elements, user interfaces)
Interaction modes (e.g.,
publish/subscribe,
request/response, command)
Platforms (e.g., Android,
JavaSE)
Spreads into the application code,
Makes the portability of code
difficult
8

9. Application development challenges
Heterogeneity
Large scale



Application logic in terms of
a set of distributed tasks for
hundreds to thousands of
devices
To reason at such levels of
scale is impractical in general
9

10. Application development challenges



Heterogeneity
Large scale
Multiple expertise

Application domain
Platform-specific
knowledge
Knowledge from multiple
concerns intersect
Algorithm design,
programming languages
Software design
Clear conflict with skill possessed
by the individual developer
10
Deployment
area

11. Application development challenges




Application Heterogeneity
designed/implemented
into a set of distributed tasks for
Large scale
heterogeneous devices
Development
Multiple expertise
Different life-cycle
phases
Tasks has to be
decomposed
in a large number of
devices
Deployment
Evolution
Changes in application
requirements
Changes in deployed devices
Software development life cycle phases -- requirement analysis, design, implementation, testing,
evolution and maintenance [Ian Sommerville, Software Engineering (9th edition) , 2010]
11

12. Outline





Application development challenges
Existing approaches
Contributions
Evaluation
Summary and future work
12

13. Existing approaches

Node-centric programming


Think in terms of activities of
individual device & encode
interactions
Olympus with Gaia middleware,
Context Toolkit, nesC with TinyOS,
physical-virtual mashup
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]
13

14. Existing approaches


Node-centric programming
Database approach




Queries to SN
Collects, aggregates, &
sends data to base station
Not flexible to introduce a
customized application logic
TinyDB, Semantic streams,
TinyREST, TinySOA
queries
Stakeholder
collects
result
Base station
TinyDB [Madden et al., TODS ,2005], Semantic streams [Whitehouse et
al., , EWSN, 2006], TinyREST [Luckenbach et al., REALWSN, 2005],
TinySOA [Aviles-Lopez , SOCA, 2009]
14

15. Existing approaches



Node-centric programming
Database approach
WSN macroprogramming
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
 Regimant, MacroLab
Regiment [Newton et al., IPSN, 2007], MacroLab [Hnat et

al. , SenSys, 2008]
15

16. Existing approaches




Node-centric programming
Database approach
WSN macroprogramming
Model-driven development


ATaG, RuleCaster (sensor
network)
DiaSuite, PervML, Pantagruel
(pervasive and ubiquitous
computing)
Horizontal
Separation of
Concerns (SoC)
PIM
C1
Vertical
separation of
concerns
C2
…
Cn
Transformation and
code generators
…
ATaG [Pathak et al., DCSN, 2011], RuleCaster [Bischoff
PSM
et al., EuroSSC, 2006], DiaSuite [Cassou et al., TSE,
2012], PervML [Serral et al., Journal of Pervasive and
E.g., J2SE
Mobile computing, 2010], Pantagruel [Drey et al., Percom,
2010]
16 our work takes inspiration from ATaG, which is a WSN framework to develop SCC
applications
PSM
E.g., .Net

17. Outline





Application development challenges
Existing approaches
Contributions
Evaluation
Summary and future work
17

18. Contributions

A comprehensive approach that utilizes advantages
of existing MDD and WSN macroprogramming
approaches, while focusing on ease of IoT
application development

Set of modeling languages to specify different concerns of
IoT applications

Development framework* to integrates modeling
languages
and automation techniques
*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].
18

19. Commonality
at various levels
Building fire
state
Room
temperature
Domain
(e.g. building
automation)
“Entities of Interest (EoI) is an object,
including the attributes that describes it, and
its state that is relevant from a user or an
application perspective.”
[Stephan Haller, Internet of Things, 2010]
Functionality
(e.g., building (e.g., home
HVAC) fire detection
Deployment
(e.g., Inria
Office)
19
(e.g., Google
Office)
“Reusability
across concerns”

20. Domain
Room
temperature
Building fire
state
Actuator
User interface
Domain
(e.g. building
automation)
Concepts that are responsible
for interacting with EoI of a
domain
- Sensor, actuator, storage,
user interface
Sensor
20
Storage

21. Functionality
Building fire
state
Room
temperature
Actuator
User interface
Domain
(e.g. building
automation)
command
Computational
service
Functionality
Building
HVAC
Home fire
detection
Computational
service
Concepts that are responsible for
- processing data and taking
decisions
21
publish/
subscribe
request
Sensor
response
Storage

22. Concepts to describe various
properties of devices
Deployment
Building fire
state
Room
temperature
Actuator
User interface
Device
Domain
Device
(e.g. building
automation)
command
Device
Device
Functionality
Building
HVAC
Computational
service
Computational
service
Home fire
detection
Deployment
publish/
subscribe
Inria
office
22
Google
office
request
Device
Sensor
response
Storage
Device

23. Modeling
languages
Srijan* interface
User
Vocabulary
Language (SVL)
Actuator
Device
Domain
(e.g. building
automation)
Functionality
Building
HVAC
Deployment
Inria
office
23
Device
Computational
Srijan*
service
Deployment
Srijan*
Home fire
Language Architecture
detection
(SDL)
Language
Computational
Device
service
(SAL)
Google
office
Device
Sensor
Storage
*Srijan is the sanskrit word for “creation”, and this word is derived form Srijan toolkit for
sensor network macroprogramming in our group.

24. Smart
building application
Monitor
Display()
RoomAvgTemp
Building
AvgTemp
FloorAvgTem
p
RoomAvgTemp
RoomAvgTemp
Floor
AvgTemp
FloorAvgTem
p
FloorAvgTem
p
Building
AvgTemp
Room
AvgTemp
Building 1
temp
Measurement
24
Temperature
sensor
Monitor
Temperature
Sensor

25. Smart
building application
Heater
Monitor
Display()
User interface
Off()
SetTemp()
request,
command
Building
AvgTemp
RegulateTemp
Manager
Floor
AvgTemp
Room
AvgTemp
Proximity
badgeDetected
badgeDisappeared
25
Badge
Reader
profile
temp
Measurement
ProfileDB
Temperature
Sensor

26. Srijan
vocabulary language
BadgeDetected
BadgeReader
profile
• SVL provides abstractions to specify
heterogeneous entities
• 1 entity description for many instances
and implementations
TempStruct
tempValue: double;
unitofMeasurement : String;
BadgeReader
generate badgeDetected:BadgeDetectedStruct;
ProfileDB
generate profile:TempStruct
accessed-by badgeID:String;
ProfileDB
Heater
Off()
SetTemp()
User interface
26
request,
command
Heater
action Off();
action SetTemp(temp:TempStruct);
User interface
request profile(badgeID);
command setTemp(temp);

27. Srijan
architecture language
To reduce scale, devices can be grouped
based on their spatial relationship
• Cluster head is elected, responsible for
processing data of that cluster.
Monitor
Display()
hops:0:Building
Building
AvgTemp
Building
hops:0:Building
Floor
AvgTemp
Floor
hops:0:Floor
RoomAvgTemp
consume tempMeasurement from hops:0:Room;
generate roomAvgTemp:TempStruct;
in-region:Room;
Room
AvgTemp
hops:0:Room
Scope of
Deployment
27
Scope of
consuming data.
temp
Measurement
Temperature
Sensor
Room

28. Srijan
architecture language
Proximity
generate tempPref:TempStruct;
consume badgeDetected from hops:0:Room;
consume badgeDisappeared from hops:0:Room;
request profile(badgeID);
in-region:Room;
Computational service may
compose multiple activities.
Room
Proximity
pub./sub.
hops:0:Room
badgeDetectedresponse
badgeDisappeared
28
Badge
Reader
request
profile
ProfileDB
To facilitate, SAL provides
abstractions to manage
heterogeneous interactions

29. Srijan
deployment language
Building fire
state
Room
temperature
SDL provides abstractions to
describes
various properties of devices
Actuator
User interface
Device
Domain
(e.g. building
automation)
Device
Device
Device
Functionality
Building
HVAC
Computational
service
Computational
service
Home fire
detection
Deployment
publish/
subscribe
Inria
office
29
Google
office
request
Device
Sensor
response
Storage
Device

30. Deployment specification
Device1:
region:
Building:15 ;
Location of device
Floor:11;
Room:1;
resources:TemperatureSensor, Heater;
type:JavaSE;
Type platform a device runs on
Device2:
…
Device3:
…
30

31. Summary of modeling languages

Srijan vocabulary language



Srijan architecture language



Abstractions for heterogeneous entities of domain
1 entity description for potentially many implementations
and instances
Use domain to specify functionality in global manner
Abstractions for processing elements & heterogeneous
interactions, scope constructs to enable scalable
operations
Srijan deployment language

31
Use domain concepts to specify device details
(individually)

32. Contributions

Set of modeling languages to specify different concerns of
IoT applications

Development framework* to integrates modeling
languages and automation techniques
*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, 9th edition, 2010].
32

33. Domain &
Functional concern
Domai
n
expert
User
interface
request/command/
action
Domain expert (e.g. biologist,
medical system designer)
understands domain
concepts.
SVL
Actuator
action
Computational
service
Software designer –
understands software
architecture concepts
SAL
Computational
service
Vocabulary Compilation
spec. of vocabulary
33
Software designer
sensor
measurement
retrieval
Sensor
Architectur
e
spec.
Storage

34. Functional
concern
Domai
n
expert
Architecture framework (in object-oriented
GPL)
- Contains abstract classes
- Concrete methods
- Abstract methods
Application developer – skilled in algorithm
design & use of programming lang.
Vocabulary Compilation
spec. of vocabulary
Architectur
e
spec.
34
Application
logic
Compilation
of architecture
Software designer
Application
developer
Architectur
e
framework

35. Implementing
application logic
separation application logic &
interaction code, known location for
application logic
Proximity
generate tempPref:TempStruct;
consume badgeDetected from hops:0:Room;
consume badgeDisappeared from hops:0:Room;
request profile(badgeID);
in-region : Room;
Concrete
method for
Subscriptio
n
request
Concrete
method for
Receiving
notification
s
35
Compiler
generat
es
private String partitionAttribute = "Room";
public void subscribebadgeDetected() {
PubSubMiddleware.subscribe(this, "badgeDetected",
subscriptionCondition);
}
public void notifiedReceived (String event Name, Object arg,
Device deviceInfo) {
if (eventName.equals(“badgeDetected”) {
onNewBadgeDetected((BadgeDetectedStruct) arg) ;
}
}
public abstract void onNewBadgeDetected (BadgeDetectedStruct arg);

36. Deployment
concern
Understands the specific target area
SDL
Mapper – decides device where each
computational service will be executing
Domai
n
expert
Mapping
files
Deployment
spec.
Mapper
Vocabulary Compilation
spec. of vocabulary
Network
manager
Architectur
e
spec.
36
Application
logic
Compilation
of architecture
Software designer
Application
developer
Architectur
e
framework

37. Platform
concern
Domai
n
expert
Device
develope
r
Device
driver
• Device developer – understands
inputs/outputs, protocols of
device platform
Vocabulary Framework
• Abstract classes with
concrete methods,
interfaces
Vocabulary
framework
Mapping
files
Deployment
spec.
Mapper
Vocabulary Compilation
spec. of vocabulary
Network
manager
Architectur
e
spec.
37
Application
logic
Compilation
of architecture
Software designer
Application
developer
Architectur
e
framework

38. Linking
Domai
n
expert
Device
develope
r
Device
driver
Combines and packs the code
generated by various stages
into packages that can be
deployed on devices.
Vocabulary
framework
Android
devices
Mapping
files
Deployment
spec.
Mapper
Vocabulary Compilation
spec. of vocabulary
Linker
PC
Network
manager
PC
Architectur
e
spec.
38
Application
logic
Compilation
of architecture
Software designer
Application
developer
Architectur
e
framework

39. Summary of development framework

Promotes suitable division of work among
stakeholders

Separates development in different concerns (deal
with each individually at evolution, enables
reusability across IoT applications)

Integrates a set of modeling languages & supports
automation techniques to reduce development effort

Defines a sequence of steps to follow to develop IoT
applications
39

40. Outline





Application development challenges
Existing approaches
Contributions
Evaluation
Summary and future work
40

41. Evaluation

Goal : To describe how well approach addresses our
aim in a quantitative manner.

Development effort : indicates effort required to create an
application

Reusability : indicates reuse of specifications and
implementations across applications
41

42. Development effort
Vocabulary
spec.
2%
Code
coverage** : 92.22%
Architecture
spec.
1%
Deployment
spec.
4%
Device driver
5%
Application
logic
6%
Generated
code*
82%
*Lines of code using Metrics 1.3.6 Eclipse plugin, **Code coverage using EclEmma Eclipse plug-in.
42

43. Fire
detection application
Alarm
User interface
Activate( )
GetNotification( )
hops:0:Building
hops:0:Building
Building
Building
FireController
RoomFireState
hops:0:Building
FloorFireState
RoomFireState
Floor
Floor
FireState
RoomFireState
hops:0:Floor
FloorFireState
Room
Room
FireState
FloorFireState
hops:0:Room
Building
FireController
hops:0:Room
Smoke
presence
Smoke
Detector
Smoke
detector
Room
AvgTemp
hops:0:Room
Building
43
Room
Temperature
sensor
Alarm
User
interface
temp
Measurement
Temperature
Sensor

44. Reusability
Handwritten Lines of code
Domain
Building
Automation
Applications
Smart
building
Fire
detection
44
Voca
b.
spec.
Arch.
spec.
Deploy.
spec.
Applicatio
n
logic
Device
driver
Developme
nt effort
55
28
81
131
151
446
21
72
93

45. Outline





Application development challenges
Existing approaches
Contributions
Evaluation
Summary and future work
45

46. Summary

Application development challenges:


Existing approaches


Separation of concerns, modeling
languages, automation, development framework
Evaluation

46
Node-centric programming, database, WSN
macroprogramming, model-driven development
Our approach


Heterogeneity, large scale, multiple expertise, different life cycle
phases
Reduce development effort

47. Future work

Supporting testing phase of application development




Emulates execution before deployment,
Identifies conflicts, reducing application debugging effort.
Integration of open source simulator (Siafu?)
Run-time adaptation in IoT applications


47
How changes can be injected into the running application
that would adapt itself accordingly?
e.g., when a new device is added, an application include
device and assign a new task to contribute

48. Backup slides

49. Development effort remains
constant
independent of a number of
devices
Development
effort
Number of
devices
Vocab
Spec.
Arch
Spec.
Deploy
Spec.
Device
Driver
Application
Logic
10
41
28
81
98
131
34
41
28
273
98
131
50
41
28
401
98
131
62
41
28
497
98
131
86
41
28
689
98
131
110
41
28
881
98
131
200
41
28
1601
98
131
300
41
28
2401
98
131
350
41
28
2801
98
131
500
41
28
4001
98
131
49

50. Generated code snippet from high-level
specifications



Generate (or publish) interaction mode
Command interaction mode
Request interaction mode
Vocabulary framework


50
Class diagram of vocabulary framework
Factory class

51. Generated code for “generate”
Proximity
generate tempPref : UserTempPrefStrut;
consume badgeDetected from hops:0:Room;
consume badgeDisappeared from hops:0: Room;
request profile(badgeID);
in-region : Room;
Compiler
generat
es
protected void setTempPref(UserTempPrefStruct newValue) {
PubSubMiddleware.publish("tempPref", newValue, myDeviceInfo);
}
51

52. Generated code for “command’’
RegulateTemp
command SetTemp(setTemp) to hops:0: Room;
command OffLight() to hops:0: Room;
in-region : Room;
Compiler
generat
es
protected void SetTemp(TempStruct arg) {
PubSubMiddleware.sendCommand(“SetTemp", arg, myDeviceInfo);
}
protected void OffLight() {
PubSubMiddleware.sendCommand(“OffLight", arg, myDeviceInfo);
}
52

53. Generated code for “request”
Proximity
generate tempPref : UserTempPrefStrut;
consume badgeDetected from hops:0:Room;
consume badgeDisappeared from hops:0: Room;
request profile(badgeID);
in-region : Room;
Compiler
generat
es
protected TempStruct getprofile(String arg) {
return (TempStruct)
PubSubMiddleware.sendRequest("getprofile", arg, myDeviceInfo);
}
53

54. Class diagram
Contains interfaces to
implement for device
developer
IBadgeReader
Contains concrete methods
for interacting with other
entities
BadgeReaderFactory
Implements
AndroidBadgeReader
Device-specific implementation
by device developers
54
BadgeReader
Provide interface to obtain an instance of
different platform-specific device driver
implementations without having to
know
what implementation the concrete class
obtains.

55. Implementing
device driver
BadgeReader
generate badgeDetected:badgeDetectedStruct;
Compiler
Device
developer
implements
interfaces
generates
public interface IBadgeReader {
public BadgeDetectedStruct getbadgeDetected();
public void getbadgeDetected(ListenerbadgeDetected handler);
}
55

56. Generated factory class
BadgeReader
generate badgeDetected: badgeDetectedStruct;
Compiler
generat
es
public class BadgeReaderFactory {
public static IBadgeReader getBadgeReader(String
nameBadgeReader) {
if(nameBadgeReader.equals("Android"))
return new AndroidBadgeReader();
if (nameBadgeReader.equals(“J2SE"))
return new J2SEBadgeReader();
}
}
56

57. Iterative development for handing evolution
 Evolution in functionality
 Evolution in deployment
 Evolution in platform
 Evolution in domain
57

58. Iterative development
for change in functionality
1.
2.
3.
4.
Adding a computational service
Removing a computational service
Extending a functionality of a computational service
Changing a functionality of an application.

59. Iterative development
for change in deployment
Change in Deployment Specification
• Adding, removing, or shifting a
device
• Change in a target deployment
59

60. Iterative development
for change in platform
Adding new software features
60

61. Iterative development
for change in domain
1. Adding new resources (i.e., sensor, actuator, storage, user
interface)
2. Removing resources
3. Extending resources
61

62. Existing model-driven approaches for IoT
Heterogeneity
Scale
Multiple
expertise
Life cycle
ATaG
[2011]
Partially
Yes
No
Yes
RuleCast
er [2007]
Partially
Yes
No
Yes
PervML
[2010]
Yes
No
Partially
Partially
(Manual
deployment)
DiaSuite
[2011]
Yes
No
Partially
Partially
(Manual
deployment)
Pantagru
el [2009]
Partially
No
Partially
Partially
(Manual
deployment)
62

63. Srijan
architecture language
Heater
Off()
SetTemp()
hops:0:Room
Room
RegulateTemp
Manager
hops:0:Room
Proximity
63
hops:0:Room
Room
AvgTemp
RoomTempManager
consume roomAvgTempMeasurement
from hops:0:Room;
consume tempPref from hops:0:Room;
command SetTemp(setTemp) to hops:0:Room;
command Off() to hops:0:Room;
in-region:Room;

64. Class diagram
of domain-specific concepts
Vocabulary
1..*
Region
1..*
Structure
1..*
1..*
Resource
Request
*
Sensor
1..*
Sensor
Measurement
64
Actuator
1..*
Action
Storage
User interface
*
Command
*
Action
1..*
Retrieval

65. Class diagram
of functionality-specific concepts
Architecture
*
Structure
1..*
1..*
Input
Consume
65
1..*
Computational
Service
1..*
Region
1..*
Output
Generate
Request
Command

66. Class diagram
of deployment-specific concepts
Deployment
1..*
Device
1..*
Region
66
*
Resource

67. Smart
building application
Monitor
Display()
RoomAvgTemp
hops:0:Building
Building
AvgTemp
FloorAvgTem
p
RoomAvgTemp
RoomAvgTemp
hops:0:Building
Floor
AvgTemp
FloorAvgTem
p
FloorAvgTem
p
Building
AvgTemp
Room
AvgTemp
hops:0:Room
temp
Measurement
Temperature
sensor
Floor
hops:0:Floor
Building 1
67
Building
Monitor
Temperature
Sensor
Room

68. Smart
building application
Heater
Monitor
Display()
User interface
hops:0:Building
Off()
SetTemp()
request,
command
Building
AvgTemp
hops:0:Room
Building
Room
RegulateTemp
Manager
hops:0:Building
hops:0:Room
Floor
AvgTemp
Floor
hops:0:Room
hops:0:Floor
Room
Proximity
hops:0:Room
hops:0:Room
badgeDetected
badgeDisappeared
68
Badge
Reader
Room
AvgTemp
profile
temp
Measurement
ProfileDB
Temperature
Sensor
Room