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.
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
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
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
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”
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.
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
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
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
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
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.
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
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