Enabling High-Level Application
Development for the Internet of Things
Pankesh Patel

PhD defense
25th November, 2013
Growing number of ``things”
Smoke
detectors

Air pollution
controllers

Temperature
sensors
Lights

HVAC
system

Fire
alar...
Internet of Things (IoT)
“A global networked infrastructure, linking physical and
virtual things through the exploitation ...
IoT application


Involves a large number of heterogeneous devices,
processing elements



Composes multiple activities
...
Illustrative example: building system
Large numbers of heterogeneous devices
An application - compose multiple
activities ...
Goal

“Enable development** of IoT applications
with minimal effort by various stakeholders*
involved in development proce...
Outline
Application development challenges
Existing approaches
Contributions
Evaluation
Summary and future work






...
Application development challenges
Heterogeneity









Types of devices (e.g., sensor,
actuator, storage, processin...
Application development challenges
Heterogeneity
Large scale






Application logic in terms of
a set of distributed t...
Application development challenges




Heterogeneity
Large scale
Multiple expertise


Application domain

Platform-spe...
Application development challenges





Application Heterogeneity
designed/implemented
into a set of distributed tasks...
Outline







Application development challenges
Existing approaches
Contributions
Evaluation
Summary and future wor...
Existing approaches


Node-centric programming




Think in terms of activities of
individual device & encode
interacti...
Existing approaches




Node-centric programming
Database approach






Queries to SN
Collects, aggregates, &
sends...
Existing approaches





Node-centric programming
Database approach
WSN macroprogramming

Abstractions for high-level
c...
Existing approaches






Node-centric programming
Database approach
WSN macroprogramming
Model-driven development

...
Outline







Application development challenges
Existing approaches
Contributions
Evaluation
Summary and future wor...
Contributions


A comprehensive approach that utilizes advantages
of existing MDD and WSN macroprogramming
approaches, wh...
Commonality
at various levels
Building fire
state

Room
temperature

Domain
(e.g. building
automation)

“Entities of Inter...
Domain
Room
temperature

Building fire
state

Actuator

User interface

Domain
(e.g. building
automation)

Concepts that a...
Functionality
Building fire
state

Room
temperature

Actuator

User interface

Domain
(e.g. building
automation)

command
...
Concepts to describe various
properties of devices

Deployment
Building fire
state

Room
temperature

Actuator

User inter...
Modeling
languages

Srijan* interface
User
Vocabulary
Language (SVL)
Actuator

Device

Domain
(e.g. building
automation)

...
Smart
building application

Monitor
Display()

RoomAvgTemp

Building
AvgTemp

FloorAvgTem
p

RoomAvgTemp
RoomAvgTemp

Floo...
Smart
building application
Heater

Monitor
Display()

User interface

Off()
SetTemp()

request,
command
Building
AvgTemp

...
Srijan
vocabulary language
BadgeDetected
BadgeReader

profile

• SVL provides abstractions to specify
heterogeneous entiti...
Srijan
architecture language
To reduce scale, devices can be grouped
based on their spatial relationship
• Cluster head is...
Srijan
architecture language
Proximity
generate tempPref:TempStruct;
consume badgeDetected from hops:0:Room;
consume badge...
Srijan
deployment language
Building fire
state

Room
temperature

SDL provides abstractions to
describes
various propertie...
Deployment specification
Device1:
region:
Building:15 ;
Location of device
Floor:11;
Room:1;
resources:TemperatureSensor, ...
Summary of modeling languages


Srijan vocabulary language





Srijan architecture language






Abstractions for...
Contributions



Set of modeling languages to specify different concerns of
IoT applications



Development framework* t...
Domain &
Functional concern

Domai
n
expert

User
interface
request/command/
action

Domain expert (e.g. biologist,
medica...
Functional
concern

Domai
n
expert

Architecture framework (in object-oriented
GPL)
- Contains abstract classes
- Concrete...
Implementing
application logic

separation application logic &
interaction code, known location for
application logic

Pro...
Deployment
concern
Understands the specific target area
SDL
Mapper – decides device where each
computational service will ...
Platform
concern

Domai
n
expert

Device
develope
r
Device
driver

• Device developer – understands
inputs/outputs, protoc...
Linking

Domai
n
expert

Device
develope
r
Device
driver

Combines and packs the code
generated by various stages
into pac...
Summary of development framework


Promotes suitable division of work among
stakeholders



Separates development in dif...
Outline







Application development challenges
Existing approaches
Contributions
Evaluation
Summary and future wor...
Evaluation


Goal : To describe how well approach addresses our
aim in a quantitative manner.


Development effort : ind...
Development effort
Vocabulary
spec.
2%

Code
coverage** : 92.22%

Architecture
spec.
1%

Deployment
spec.
4%
Device driver...
Fire
detection application

Alarm

User interface

Activate( )

GetNotification( )
hops:0:Building

hops:0:Building
Buildi...
Reusability
Handwritten Lines of code
Domain

Building
Automation

Applications

Smart
building
Fire
detection

44

Voca
b...
Outline







Application development challenges
Existing approaches
Contributions
Evaluation
Summary and future wor...
Summary


Application development challenges:




Existing approaches




Separation of concerns, modeling
languages,...
Future work


Supporting testing phase of application development






Emulates execution before deployment,
Identif...
Backup slides
Development effort remains
constant
independent of a number of
devices

Development
effort
Number of
devices

Vocab
Spec.
...
Generated code snippet from high-level
specifications





Generate (or publish) interaction mode
Command interaction m...
Generated code for “generate”
Proximity
generate tempPref : UserTempPrefStrut;
consume badgeDetected from hops:0:Room;
con...
Generated code for “command’’
RegulateTemp
command SetTemp(setTemp) to hops:0: Room;
command OffLight() to hops:0: Room;
i...
Generated code for “request”
Proximity
generate tempPref : UserTempPrefStrut;
consume badgeDetected from hops:0:Room;
cons...
Class diagram
Contains interfaces to
implement for device
developer
IBadgeReader

Contains concrete methods
for interactin...
Implementing
device driver
BadgeReader
generate badgeDetected:badgeDetectedStruct;

Compiler

Device
developer
implements
...
Generated factory class
BadgeReader
generate badgeDetected: badgeDetectedStruct;

Compiler
generat
es
public class BadgeRe...
Iterative development for handing evolution
 Evolution in functionality
 Evolution in deployment
 Evolution in platform...
Iterative development
for change in functionality
1.
2.
3.
4.

Adding a computational service
Removing a computational ser...
Iterative development
for change in deployment
Change in Deployment Specification
• Adding, removing, or shifting a
device...
Iterative development
for change in platform
Adding new software features

60
Iterative development
for change in domain
1. Adding new resources (i.e., sensor, actuator, storage, user
interface)
2. Re...
Existing model-driven approaches for IoT
Heterogeneity

Scale

Multiple
expertise

Life cycle

ATaG
[2011]

Partially

Yes...
Srijan
architecture language
Heater
Off()
SetTemp()
hops:0:Room
Room

RegulateTemp
Manager

hops:0:Room

Proximity

63

ho...
Class diagram
of domain-specific concepts
Vocabulary

1..*
Region

1..*
Structure

1..*

1..*
Resource

Request
*

Sensor
...
Class diagram
of functionality-specific concepts
Architecture

*
Structure

1..*

1..*
Input

Consume

65

1..*
Computatio...
Class diagram
of deployment-specific concepts
Deployment

1..*
Device

1..*
Region

66

*

Resource
Smart
building application

Monitor
Display()

RoomAvgTemp

hops:0:Building

Building
AvgTemp

FloorAvgTem
p

RoomAvgTemp
...
Smart
building application
Heater

Monitor
Display()

User interface
hops:0:Building

Off()
SetTemp()

request,
command
Bu...
Upcoming SlideShare
Loading in …5
×

Enabling high level application development for internet of things

1,172 views

Published on

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.

Published in: Education, Technology, Business
1 Comment
3 Likes
Statistics
Notes
No Downloads
Views
Total views
1,172
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
73
Comments
1
Likes
3
Embeds 0
No embeds

No notes for slide

Enabling high level application development for internet of things

  1. 1. Enabling High-Level Application Development for the Internet of Things Pankesh Patel PhD defense 25th November, 2013
  2. 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. 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. 4. IoT application  Involves a large number of heterogeneous devices, processing elements  Composes multiple activities  Interacts with users whenever necessary 4
  5. 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. 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. 7. Outline Application development challenges Existing approaches Contributions Evaluation Summary and future work      7
  8. 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. 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. 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. 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. 12. Outline      Application development challenges Existing approaches Contributions Evaluation Summary and future work 12
  13. 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. 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. 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. 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. 17. Outline      Application development challenges Existing approaches Contributions Evaluation Summary and future work 17
  18. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 40. Outline      Application development challenges Existing approaches Contributions Evaluation Summary and future work 40
  41. 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. 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. 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. 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. 45. Outline      Application development challenges Existing approaches Contributions Evaluation Summary and future work 45
  46. 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. 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. 48. Backup slides
  49. 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. 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. 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. 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. 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. 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. 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. 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. 57. Iterative development for handing evolution  Evolution in functionality  Evolution in deployment  Evolution in platform  Evolution in domain 57
  58. 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. 59. Iterative development for change in deployment Change in Deployment Specification • Adding, removing, or shifting a device • Change in a target deployment 59
  60. 60. Iterative development for change in platform Adding new software features 60
  61. 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. 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. 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. 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. 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. 66. Class diagram of deployment-specific concepts Deployment 1..* Device 1..* Region 66 * Resource
  67. 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. 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

×