Enabling High-Level Application Development for the Internet of Things Pankesh Patel PhD defense 25 th November, 2013
Enabling high level application development for internet of things
Jan 27, 2015
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.
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.
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Enabling High-Level Application Development for the Internet of Things
Pankesh Patel
PhD defense 25th November, 2013
Growing number of ``things”
2
Temperature sensors Fire
alarmsSmoke detectors
Lights
Traffic signals
Water leakage detector
Smart phones
Parking space
controller
Air pollution controllers
Structuralhealth
monitors
HVAC system
Smart car
Image credit: http://www.libelium.com/
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
4
Involves a large number of heterogeneous devices, processing elements
Composes multiple activities
Interacts with users whenever necessary
IoT application
5
Illustrative example: building system
Large numbers of heterogeneous devices
Smoke detector
User interfaces(e.g., display, mobile phones)
Firealarm
Badge reader
User withbadge
Data storage
Light
Temperature
sensorHeater
For situation awareness (e.g., avg. temperature of building), devices involved in collaborative activities
An application - compose multiple activities (e.g., detect user’s entry , query, set threshold)
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.
7
Outline Application development challenges Existing approaches Contributions Evaluation Summary and future work
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
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
10
Application development challenges
Heterogeneity Large scale 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
11
Application development challenges
Heterogeneity Large scale Multiple expertise Different life-cycle phases
Development Deployment
Evolution
Tasks has to be decomposed in a large number of devices
Application - designed/implemented into a set of distributed tasks for heterogeneous devices
Changes in application requirementsChanges in deployed devices
Software development life cycle phases -- requirement analysis, design, implementation, testing, evolution and maintenance [Ian Sommerville, Software Engineering (9th edition) , 2010]
12
Outline Application development challenges Existing approaches Contributions Evaluation Summary and future work
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]
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
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]
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]
16
Existing approaches
Node-centric programming
Database approach WSN macroprogramming Model-driven
development ATaG, RuleCaster (sensor
network) DiaSuite, PervML,
Pantagruel (pervasive and ubiquitous computing)
Transformation and code generators
PIM
PSM
E.g., J2SE E.g., .Net
PSM…
C1 C2 Cn…
HorizontalSeparation of
Concerns (SoC)
Verticalseparation of
concerns
our work takes inspiration from ATaG, which is a WSN framework to develop SCC applications
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]
17
Outline Application development challenges Existing approaches Contributions Evaluation Summary and future work
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].
19
Commonality at various levels
Functionality (e.g., home
fire detection
Domain
(e.g., building HVAC)
(e.g., Inria Office)
(e.g., GoogleOffice)
Deployment
Room temperatur
e
(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]
Building fire state
“Reusabilityacross concerns”
20
Domain
Room temperatur
e
(e.g. building automation)
Actuator
Sensor
User interface
Domain
Storage
Concepts that are responsible for interacting with EoI of a domain- Sensor, actuator,
storage, user interface
Building fire state
21
Domain
Room temperatur
e
(e.g. building automation)
Functionality
FunctionalityHome fire detection
Building HVAC
Computationalservice
Actuator
StorageSensor
Computationalservice
response
requestpublish/
subscribeConcepts that are responsible for - processing data and taking decisions
Building fire state
command
User interface
22
Domain
Room temperatur
e
(e.g. building automation)
Deployment
Functionality
Inria office
Googleoffice
Deployment
Device
Device
Device
Device
Device Device
Building fire state
Concepts to describe various
properties of devicesActuato
r
Sensor
User interface
Storage
Computationalservice
Computationalservice
response
requestpublish/
subscribe
Home fire detection
Building HVAC
command
23
Domain
(e.g. building automation)
Modeling languages
Functionality
Inria office
Googleoffice
Deployment
Device
Device
Device
Device
Actuator
Sensor
User interface
Storage
Computationalservice
Computationalservice
Home fire detection
Building HVAC
Srijan* Vocabulary
Language (SVL)
Srijan* Architecture
Language(SAL)
Srijan* Deployment
Language(SDL)
*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
Building 1
RoomAvgTemp
RoomAvgTemp
RoomAvgTemp
FloorAvgTemp
FloorAvgTemp
FloorAvgTemp
BuildingAvgTemp
BuildingAvgTemp
RoomAvgTemp
FloorAvgTemp
Temperaturesensor Monitor
TemperatureSensor
tempMeasurement
Monitor
Display()
25
RegulateTempManager
Heater
Off()SetTemp()
Smart building application
BuildingAvgTemp
RoomAvgTemp
FloorAvgTemp
TemperatureSensor
tempMeasurement
Monitor
Display()
BadgeReader ProfileDB
Proximity
badgeDetectedbadgeDisappeared
profile
User interface
request, command
26
Heater
Off()SetTemp()
ProfileDB
profile
User interface
request, command
Srijan vocabulary language
BadgeReader generate badgeDetected:BadgeDetectedStruct;
TempStruct tempValue: double; unitofMeasurement : String;
ProfileDB generate profile:TempStruct accessed-by badgeID:String;
Heater action Off(); action SetTemp(temp:TempStruct);
User interface request profile(badgeID); command setTemp(temp);
BadgeReader
BadgeDetected
• SVL provides abstractions to specify heterogeneous entities• 1 entity description for many instances and implementations
27
Srijan architecture language
BuildingAvgTemp
RoomAvgTemp
FloorAvgTemp
TemperatureSensor
tempMeasurement
Monitor
Display()
hops:0:Room
hops:0:Floor
hops:0:Building
hops:0:Building
Room
Floor
Building
RoomAvgTemp consume tempMeasurement from hops:0:Room; generate roomAvgTemp:TempStruct; in-region:Room;
Scope of consuming data.Scope 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.
28
BadgeReader ProfileDB
Proximity
badgeDetectedbadgeDisappeared
profile
hops:0:Room
Room
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;
pub./sub. reques
tresponse
To facilitate, SAL provides abstractions to manage heterogeneous interactions
Computational service may compose multiple activities.
29
Domain
Room temperatur
e
(e.g. building automation)
Srijan deployment language
Functionality
Inria office
Googleoffice
Deployment
Device
Device
Device
Device
Device Device
Building fire state
SDL provides abstractions to describes various properties of devices
Actuator
Sensor
User interface
Storage
Computationalservice
Computationalservice
response
requestpublish/
subscribe
Home fire detection
Building HVAC
30
Deployment specification
Device1: region: Building:15 ; Floor:11; Room:1; resources:TemperatureSensor, Heater; type:JavaSE;
Device2: …
Device3:…
Location of device
Type platform a device runs on
31
Summary of modeling languages Srijan vocabulary language
Abstractions for heterogeneous entities of domain 1 entity description for potentially many
implementations and instances Srijan architecture language
Use domain to specify functionality in global manner Abstractions for processing elements &
heterogeneous interactions, scope constructs to enable scalable operations
Srijan deployment language 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].
33
Domain & Functional concern
Domain expert
Vocabulary
spec.
Compilationof
vocabulary
Architecture
spec.
Software designer
Computationalservice
Computationalservice
Software designer – understands software architecture concepts
StorageSensor
retrievalsensor measurement
Actuator
action
User interfacerequest/command/
action
SAL
Domain expert (e.g. biologist, medical system designer) understands domain concepts.SVL
34
Domain expert
Vocabulary
spec.
Compilationof
vocabulary
Architecture
spec.Compilation
of architecture
Application developer
Architecture
framework
Software designer
Functional concern
Application logic
Application developer – skilled in algorithm design & use of programming lang.
Architecture framework (in object-oriented GPL)- Contains abstract classes
- Concrete methods- Abstract methods
35
Proximity generate tempPref:TempStruct; consume badgeDetected from hops:0:Room; consume badgeDisappeared from hops:0:Room; request profile(badgeID); in-region : Room;
Compiler
generates
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);
Implementing application logic
Concrete method
forSubscripti
onrequest Concrete method
forReceivingnotificatio
ns
separation application logic & interaction code, known location for application logic
36
Domain expert
Vocabulary
spec.
Compilationof
vocabulary
Deployment spec.
MapperNetworkmanager
Mapper – decides device where each computational service will be executing
Deployment concern
Mapping
files
Architecture
spec.Compilation
of architecture
Application developer
Application logic
Architecture
framework
Software designer
Understands the specific target areaSDL
37
Domain expert
Vocabulary
spec.
Compilationof
vocabulary
Device develop
er
Device driver
Vocabulary
framework
Deployment spec.
MapperNetworkmanager
Mapping
files
Platformconcern
Architecture
spec.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
38
Domain expert
Vocabulary
spec.
Compilationof
vocabulary
Device develop
er
Device driver
Vocabulary
framework
Architecture
spec.Compilation
of architecture
Deployment spec.
Mapper
Application developer
Application logic
Architecture
framework
Software designer
Networkmanager
Linker
Android devices
PC
PC
Mapping
files
Linking
Combines and packs the code generated by various stages into packages that can be deployed on devices.
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
40
Outline Application development challenges Existing approaches Contributions Evaluation Summary and future work
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
42
Development effortVocabulary spec.
2%
Architecture spec.1% Deployment
spec. 4%
Device driver5%
Application logic6%
Generated code*82%
Code coverage** : 92.22%
*Lines of code using Metrics 1.3.6 Eclipse plugin, **Code coverage using EclEmma Eclipse plug-in.
43
Fire detection application
RoomFireState
Activate( )
Alarm User interface
GetNotification( )
TemperatureSensor
tempMeasurement
Smoke Detector
Smokepresence
RoomAvgTemp
Smoke detector
Temperature sensor Alarm User
interface
FloorFireState
BuildingFireControll
er
Building
RoomFireState
RoomFireState
RoomFireState
FloorFireState
Building FireControlle
r
FloorFireState
FloorFireState
hops:0:Room
hops:0:Room
hops:0:Room
hops:0:Floor
hops:0:Building
hops:0:Building
hops:0:Building
Room
Floor
Building
Room
44
Reusability
Handwritten Lines of code
Domain Applications
Vocab.
spec.
Arch.spec.
Deploy. spec.
Application
logic
Device driver
Development effort
BuildingAutomatio
n
Smart building 55 28 81 131 151 446
Fire detection 21 72 93
45
Outline Application development challenges Existing approaches Contributions Evaluation Summary and future work
46
Summary Application development challenges:
Heterogeneity, large scale, multiple expertise, different life cycle phases
Existing approaches Node-centric programming, database, WSN
macroprogramming, model-driven development Our approach
Separation of concerns, modeling languages, automation, development framework
Evaluation 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 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
Backup slides
49
Development effort
Number of
devices
Vocab Spec.
Arch Spec.
DeploySpec.
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
Development effort remains constant independent of a number of devices
50
Generated code snippet from high-level specifications Generate (or publish) interaction mode Command interaction mode Request interaction mode
Vocabulary framework Class diagram of vocabulary framework Factory class
51
Proximity generate tempPref : UserTempPrefStrut; consume badgeDetected from hops:0:Room; consume badgeDisappeared from hops:0: Room; request profile(badgeID); in-region : Room; Compiler
generates
protected void setTempPref(UserTempPrefStruct newValue) { PubSubMiddleware.publish("tempPref", newValue, myDeviceInfo);}
Generated code for “generate”
52
RegulateTemp command SetTemp(setTemp) to hops:0: Room; command OffLight() to hops:0: Room; in-region : Room;
Compiler
generates
protected void SetTemp(TempStruct arg) { PubSubMiddleware.sendCommand(“SetTemp", arg, myDeviceInfo);}protected void OffLight() { PubSubMiddleware.sendCommand(“OffLight", arg, myDeviceInfo);}
Generated code for “command’’
53
Proximity generate tempPref : UserTempPrefStrut; consume badgeDetected from hops:0:Room; consume badgeDisappeared from hops:0: Room; request profile(badgeID); in-region : Room; Compiler
generates
protected TempStruct getprofile(String arg) { return (TempStruct) PubSubMiddleware.sendRequest("getprofile", arg, myDeviceInfo);}
Generated code for “request”
54
Class diagram
IBadgeReader
AndroidBadgeReader
BadgeReaderFactory BadgeReader
Implements
Device-specific implementation by device developers
Contains concrete methods
for interacting with other entities
Contains interfaces to implement for device
developer
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
public interface IBadgeReader { public BadgeDetectedStruct getbadgeDetected(); public void getbadgeDetected(ListenerbadgeDetected handler);}
Compiler
generatesDevice
developer implemen
ts interfaces
BadgeReader generate badgeDetected:badgeDetectedStruct;
56
Compiler
generates
public class BadgeReaderFactory { public static IBadgeReader getBadgeReader(String nameBadgeReader) {
if(nameBadgeReader.equals("Android")) return new AndroidBadgeReader(); if (nameBadgeReader.equals(“J2SE"))
return new J2SEBadgeReader(); }}
Generated factory class
BadgeReader generate badgeDetected: badgeDetectedStruct;
57
Iterative development for handing evolution Evolution in functionality Evolution in deployment
Evolution in platform Evolution in domain
Iterative development for change in functionality
1. Adding a computational service2. Removing a computational service3. Extending a functionality of a computational service4. 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
60
Iterative development for change in platform
Adding new software features
61
Iterative development for change in domain
1. Adding new resources (i.e., sensor, actuator, storage, user interface)
2. Removing resources 3. Extending resources
62
Existing model-driven approaches for IoT
Heterogeneity
Scale Multiple expertise
Life cycle
ATaG [2011]
Partially Yes No Yes
RuleCaster
[2007]
Partially Yes No Yes
PervML[2010]
Yes No Partially Partially(Manual
deployment)
DiaSuite [2011]
Yes No Partially Partially(Manual
deployment)
Pantagruel
[2009]
Partially No Partially Partially(Manual
deployment)
63
RegulateTempManager
Heater
Off()SetTemp()
hops:0:Room
hops:0:Room
Proximity
Room
hops:0:Room
Srijan architecture language
RoomAvgTemp
RoomTempManagerconsume 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
Region Structure
1..* 1..*Resource1..*
1..*
Sensor Actuator Storage User interface
Request
Command
Action
*
*
*Sensor
Measurement Action Retrieval
1..* 1..* 1..*
65
Architecture
Structure* Computational
Service
1..*1..*
Input Output
Consume Generate Request Command
Region1..*
1..* 1..*
Class diagram of functionality-specific concepts
66
Deployment
Device1..*
Resource*
Region
1..*
Class diagram of deployment-specific concepts
67
Smart building application
Building 1
RoomAvgTemp
RoomAvgTemp
RoomAvgTemp
FloorAvgTemp
FloorAvgTemp
FloorAvgTemp
BuildingAvgTemp
BuildingAvgTemp
RoomAvgTemp
FloorAvgTemp
Temperaturesensor Monitor
TemperatureSensor
tempMeasurement
Monitor
Display()
Room
hops:0:Room
hops:0:Floor
hops:0:Building
hops:0:Building
Floor
Building
68
RegulateTempManager
Heater
Off()SetTemp()
Smart building application
BuildingAvgTemp
RoomAvgTemp
FloorAvgTemp
TemperatureSensor
tempMeasurement
Monitor
Display()
hops:0:Room
hops:0:Floor
hops:0:Building
hops:0:Building
hops:0:Room
hops:0:Room
BadgeReader ProfileDB
Proximity
badgeDetectedbadgeDisappeared
profile
hops:0:Room
User interface
Room
Floor
Building
Room
Room
request, command
hops:0:Room
Related Documents
