Enabling High Level Application Development In The Internet Of Things

890 views
728 views

Published on

The Internet of Things (IoT) combines Wireless Sensor and Actuation Networks (WSANs), Pervasive
computing, and the elements of the \\traditional" Internet such as Web and database servers. This leads to
the dual challenges of scale and heterogeneity in these systems, which comprise a large number of devices of
di erent characteristics. In view of the above, developing IoT applications is challenging because it involves
dealing with a wide range of related issues, such as lack of separation of concerns, need for domain experts to
write low level code, and lack of specialized domain speci c languages (DSLs). Existing software engineering
approaches only cover a limited subset of the above-mentioned challenges.
In this work, we propose an application development process for the IoT that aims to comprehensively
address the above challenges. We rst present the semantic model of the IoT, based on which we identify
the roles of the various stakeholders in the development process, viz., domain expert, software designer,
application developer, device developer, and network manager, along with their skills and responsibilities.
To aid them in their tasks, we propose a model-driven development approach which uses customized lan-
guages for each stage of the development process: Srijan Vocabulary Language (SVL) for specifying the
domain vocabulary, Srijan Architecture Language (SAL) for specifying the architecture of the application,
and Srijan Network Language (SNL) for expressing the properties of the network on which the application
will execute; each customized to the skill level and area of expertise of the relevant stakeholder. For the
application developer specifying the internal details of each software component, we propose the use of a
customized generated framework using a language such as Java. Our DSL-based approach is supported by
code generation and task-mapping techniques in an application development tool developed by us. Our
initial evaluation based on two realistic scenarios shows that the use of our techniques/framework succeeds
in improving productivity while developing IoT applications.

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
890
On SlideShare
0
From Embeds
0
Number of Embeds
11
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Enabling High Level Application Development In The Internet Of Things

  1. 1. Enabling High-level ApplicationDevelopment in the Internet of Things Pankesh Patel ARLES project-team Inria Paris-Rocquencourt
  2. 2. Outline • Introduction to the Internet of Things • Application Development Challenges • Existing Approaches • Our Goal • Contributions • Discussion • Future work 2
  3. 3. Characteristics of ``things’’• May have sensors attached• May have actuators attached• Can communicate with other things• Can be involved in the information exchange between ``physical’’ and ``virtual’’ worlds 3
  4. 4. Internet of things (IoT) ``A network infrastructure that connects physical and virtual things” [CASAGRAS Project][CASAGRAS Project] : http://www.rfidglobal.eu/userfiles/documents/CASAGRAS26022009.pdf 4
  5. 5. Marriage of Sensor Network and PervasiveComputing Sensor Network Pervasive computingLargeScale Heterogeneity Internet of things 5
  6. 6. Multiple Levels [IoT Research Roadmap] Internet of Things Application Domain Building … Automation Healthcare TransportationApplication HVAC Energy ManagementDeployment INRIA Google office Office[IoT Research Roadmap] Internet of things strategic Research Roadmaphttp://www.internet-of-things-research.eu/pdf/IoT_Cluster_Strategic_Research_Agenda_2009.pdf 6
  7. 7. Outline • Introduction to the Internet of Things • Application Development Challenges • Existing Approaches • Our Goal • Contributions • Discussion • Future work 7
  8. 8. 1. No Separation of Concerns • To develop applications, a developer requires multiple skills Distributed system Low-level Domain-specific Knowledge hardware knowledge Expertise (e.g., interaction (e.g., glue code to (e.g., Building modes) interface hardware and automation) software) Requires considerable CS background Conflicts with skill-setHinders rapid applicationdevelopment Programmer/developer 8
  9. 9. 2. “General-Purpose” DSLs “one- size fits all’’ DSL for the entire IoT domain. application Internet of things domain 1 application domain 2 application domain N … Home Transportation automation Healthcare These approaches remains general purpose and thus provide little guidance to the developers 9
  10. 10. 3. Heterogeneity of Target Devices• Different interaction modes• Different implementation of sensor/actuator Spreads in the application code, cluttering with low-level detail. 10
  11. 11. 4. Large Scale • Hundreds to thousands of devices equipped with sensors and actuators Reasoning at large scale is impractical 11
  12. 12. Outline • Introduction to the Internet of Things • Application Development Challenges • Existing Approaches • Our Goal • Contributions • Discussion • Future work 12
  13. 13. Middleware Approach (or node-level programming)• Motivation: • Shields the programmers from complexity by providing abstractions at node- level [Context toolkit, Gaia middleware].• Disadvantages: • No separation of concerns • Missing support for each application development stages • Provided support remain general purpose and thus provide little guidance to developers to program application domain 13
  14. 14. System-level Approach (or macro programming)• Motivation: • Raises the level of abstraction in program specifications (largely in UML/textual language) and transforms into working implementation [PervML, ATaG, DiaSuite] • Separation of concerns • Support for each application development stages• Disadvantages: • Provided support remain general purpose and thus provide little guidance to developers to program application domain 14
  15. 15. Goal of Our Research“Enable high-level application development that allowstakeholders involved in the development of IoTapplications to easily create applications, which involves alarge number of heterogeneous devices’’ 15
  16. 16. Assumptions• Inter-node communication is provided by a suitable middleware.• The creation of IoT applications is a collaborative process between stakeholders with unique skills and responsibilities.• There is a node-level compilation support for high-level object-oriented programming languages. - 16
  17. 17. Contributions1 We identify entities of IoT and relationship among them (model)2 Leveraging model, we identify the precise role of stakeholders3 Resulting from the actions of each stakeholder, we propose multi-stage model driven approach4 Evaluation of approach 17
  18. 18. Our IoT Model (1/2)It encapsulates system’sfunctionalities, providesinterface. Communicates-with Traditional * 1 consumes 1..* 1 SoftwareInternet concepts 1 Information Component 1 generates Extends Extends Extends Extends End-user Storage Computational Driver Application Service service 1 1 Interacts Provides Extends Extends with access to 1 1..* Sensor Actuator User Store Driver Driver ``Things’’- oriented concepts 18
  19. 19. Our IoT Model (2/2) Entity of Consists of Observes Phenomenon Interest affects Actuator Sensor accesses actuates Resource Actuator Sensor Hosts Driver Driver Device generates consumes Runs-on Software Component Command Sensor MeasurementEnd-user Storage Computational DriverApplication Service Service Information User Store 19
  20. 20. Entity at Deployment Level Application Domain Building Automation At deployment-level, two deployment sites have different set of devices. HVAC Energy Application Mgmt Resource Deployment Hosts 1 * Device INRIA Google 1 site site Runs-on 1..* Software Component 20
  21. 21. Entities at Application Level Application Domain Building Automation At application-level, two applications have different set of functionalities. Energy Application HVAC Mgmt Deployment 1 Hosts * Device Communicates-with INRIA Google 1 site site Runs-on 1..* Software Component End-user ComputationalApplication Service 21
  22. 22. Entities at Application Domain Level Entity of Consists of Observes Phenomenon Interest affects Actuator Sensor Affects accesses Entity of Interest actuates Resource Actuator Sensor Hosts Driver ObservesDriver Device Entity of Interest generates consumes Runs-on Software Component Command Sensor MeasurementEnd-user Storage Computational DriverApplication Service Service User Store Stores information about Entity of Interest 22
  23. 23. Contributions1 We identify entities of IoT and relationship among them (model)2 Leveraging model, we identify the precise role of stakeholders3 Resulting from the actions of each stakeholder, we propose multi-stage model driven approach4 Evaluation of approach 23
  24. 24. Roles in IoT application development Role Skills Responsibilities Domain Understanding about application Vocabulary of application domain Expert [1] domain (e.g., building automation) Device Developer Low-level hardware knowledge Writes device specific drivers System Understanding about Designer [1] Defines structure of the application architecture of an application Application Skilled in algorithm and Implements software components Developer [2] programming language Network Understanding of target area Specifies target application scenario Manager where the application is to be and Installs the application on the deployed device at hand[1] Software Architecture: Foundations, Theory, and Practice by R. N. Taylor, N. Medvidovic and E. M. Dashofy[2] D. Cassou, J. Bruneau, C. Consel, and E. Balland. Towards a tool-based development methodology for pervasive computing applications. Software Engineering, IEEETransactions on, (99):1-1, 2011. 24
  25. 25. Roles in IoT application development Role Skills Responsibilities Domain Understanding about application Vocabulary of application domain Expert [1] domain (e.g., building automation) Application Domain Level Device Developer Low-level hardware knowledge Writes device specific drivers System Understanding about Designer [1] Defines structure of the application architecture of an application Application Level Application Skilled in algorithm and Implements software components Developer [2] programming language Network Understanding of target area Specifies target application scenario Manager where the application is to be deployed Deployment Level and Installs the application on the device at hand[1] Software Architecture: Foundations, Theory, and Practice by R. N. Taylor, N. Medvidovic and E. M. Dashofy[2] D. Cassou, J. Bruneau, C. Consel, and E. Balland. Towards a tool-based development methodology for pervasive computing applications. Software Engineering, IEEETransactions on, (99):1-1, 2011. 25
  26. 26. Contributions1 We identify entities of IoT and relationship among them (model)2 Leveraging model, we identify the precise role of stakeholders3 Resulting from the actions of each stakeholder, we propose multi-stage model driven approach4 Evaluation of approach 26
  27. 27. Vocabulary Specification 1 Vocabulary Specification using Srijan Vocabulary Language (SVL) Domain Vocabulary • Sensor Specification Expert • Actuator • Storage Service • Region definitionSpecifyInputReferOutput 27
  28. 28. Architecture Specification 1 2 Domain Vocabulary Expert Specification Architecture System Specification Designer Given vocabulary, he defines architecture of an application using Srijan Architecture Language (SAL).SpecifyInputReferOutput 28
  29. 29. Implementing Software Component 1 2 Domain Vocabulary Expert Specification Architecture System Specification Designer Framework Generator 3 4Application Application ApplicationDeveloper Logic Framework Specify Input Refer It allows application developers to focusOutput on software component logic. 29
  30. 30. Target Network Specification 1 2 Domain Vocabulary Expert Specification Architecture System Specification Designer 5 Framework Generator Network Network 3 description Manager 4Application Application ApplicationDeveloper Logic Framework Specify Given vocabulary, he specifies target Input deployment scenario using Srijan Refer Network Language (SAL).Output 30
  31. 31. Mapping 1 2 Domain Vocabulary Expert Specification Architecture System Specification Designer 5 Framework Generator Network Network 3 description Manager Mapper 4 6Application Application ApplicationDeveloper Logic Framework Mapping files Specify Input It decides the specific device where Refer each software component will beOutput running. 31
  32. 32. Writing Device-Drivers 1 2 Domain Vocabulary Expert Specification Architecture System Specification Designer 5 Given vocabulary, he writes device drivers Framework Generator • sensor driver Network Network • actuator driver description Manager 3 Mapper 4 6Application Application 7 ApplicationDeveloper Logic Framework Mapping files Device Device Developer Specify Drivers Input ReferOutput 32
  33. 33. Linking 1 2 Domain Vocabulary Expert Specification Architecture System Specification Designer 5 Framework Generator Network Network 3 description Manager Mapper 4 6Application Application 7 ApplicationDeveloper Logic Framework Mapping files Device Device Developer Specify Drivers 8 Combines the generated code Input System Linker into the actual code to be Refer deployed on the real devices.Output 33
  34. 34. Domain Specific Languages (DSLs) 34
  35. 35. DSL Actuator Affects Vocabulary Lang. action (Application Domain Level) Phenomenon (e.g., Heater) command Take Decision Controller (e.g., On / Off) Architecture Lang. (Application Level) information Computes Information Computational (e.g., Calculate Avg) Service Sensor information Measurement Observes Phenomenon Vocabulary Lang. Sensor Storage Stores info. about(e.g., Temperature Phenomenon Sensor )(Application Domain Level) User’s Preferences) (e.g., 35
  36. 36. Srijan Vocabulary Language (1/2) As a first step of abstracting heterogeneity, sensing and actuating entities are specified in high-level manner. One entity description for many implementationsTemperatureSensor generate tempMeasurement : TempStruct; One entity description for many instances 36
  37. 37. Srijan Vocabulary Language (2/2) To address scalable operations within IoT system, hierarchical clustering should be specified [SINA]. Building:03 regions: Building : Integer; Floor : Integer; Floor: 10 ... Floor: 15 Room : Integer; Room: 5 Room: 6Use of region construct: • Enables system partition at logical level • Defines scope from which software components will produce/consume data [SINA] Srisathapornphat, C. and Jaikaeo, C. and Shen, C. , Sensor information networking architecture and applications, 2001 37
  38. 38. Srijan Architecture Language avgTemp Room AvgTemp “Vocabulary” specific tempMeasurement Architecture Description Temperature Sensor Scope of consuming data. RoomAvgTemp consume tempMeasurement from hops : 0: Room ; Enables generate avgTemp : TempStruct ; Hierarchical in-region : Room ; Clustering Scope of deployment 38
  39. 39. Srijan Network LanguageTemperature-Sensing-Device : Device Name region : Building : 15 ; Floor : 11; Room : 0; abilities : TemperatureSensor; Attached sensor/ actuator/storage serviceBadge-Scanner : with device region : Building : 15 ; Floor : 11; Room : 0; abilities : BadgeReader ; “Vocabulary” specific Network Description 39
  40. 40. Contributions1 We identify entities of IoT and relationship among them (model)2 Leveraging model, we identify the precise role of stakeholders3 Resulting from the actions of each stakeholder, we propose multi-stage model driven approach4 Evaluation of approach 40
  41. 41. Evaluation of our approach (1/2) Goal of our evaluation: • To demonstrate the advantage of our approach over manual application development approach. Application Sensing Actuating Computational Controller Storage Devices Entity Entity Service Service Smart Office 12 6 13 6 2 8 ApplicationFire Management 8 8 4 3 0 8 Application 41
  42. 42. Evaluation of our approach (2/2) Development efforts: • It is directly proportional to the lines of code. • The more hand-written lines of code there is, the effort required to develop application is longer. Lines of code* Lines of Code Applicatio Applicatio n Logic n Logic 11% 10% Specificat Specificat ion ion Code 8% Code 8% Coverage Coverage** 93% 90% Generate Generate d Code d Code 81% 82% Smart Office Fire Management Application Application*Lines of code using Metrics 1.3.6 Eclipse plugin, ** Code coverage using EclEmma Eclipse plugin. 42
  43. 43. Outline • Introduction to the Internet of Things • Application Development Challenges • Existing Approaches • Our Goal • Contributions • Discussion • Future work 43
  44. 44. Discussion1. Identify the precise role of each stakeholders • Promotes separation of concerns2. Multi-stage model-driven approach • Allows stakeholders to specify their share at proper level of abstractions (aiming large number of heterogeneous devices)3. A generative approach of application development • Provides support to stakeholders to design and develop applications at each stages • ease application development by reducing development efforts 44
  45. 45. Outline • Introduction to the Internet of Things • Application Development Challenges • Existing Approaches • Our Goal • Current Progress to Achieve Goal • Discussion • Future work 45
  46. 46. Future work (1/3)1. Novel mapping algorithms cognizant of heterogeneity To handle the heterogeneity of target devices, we will provide rich abstractions to express the properties of the devices : • Processing and storage capacity • Monetary cost of hosting a software component These will then be used to guide the design of algorithms for efficient mapping of software components on devices. 46
  47. 47. Future work (2/3)2. Complete support for storage services • Our work will provide abstractions to easily specify interaction modes with the rich variety of data sources present in the IoT. Simplistic view of storage interaction, which is inadequate given diverse set of data sources available on the internet.Profile-StorageService generate profile : TempStruct accessed-by badgeID: String ;TempStruct tempValue : double ; unitOfMeasurement : String ; 47
  48. 48. Future work (3/3)3. End-user interaction We will provide better ways for the stakeholders to define these software components at all stages of the application development process. Entity of Interest End-user Application Interacts with User 48
  49. 49. THANKS FOR LISTENING ME 
  50. 50. Our IoT Model (2/2) 1..* Entity of 1 Consists-of 1..* affects Phenomenon Interest 1..* Observes 1 * * Produces 1 1 1 Performs Raw data Sensor Actuator Action 1 1 Accessed-by Extends Extends actuated-by 1 1 Resource Sensor Actuator 1 Hosts driver * driver Device 1 Communicates-with 1 generates 1 consumes 1 1 Runs-on 1..* Software Component Command Sensor extends measurementEnd-user Storage Computational Service DriverApplication Service Extends Extends Information User Store 50
  51. 51. Entities at Application Domain Level 1..* Entity of 1 Consists-of 1..* affects Phenomenon Interest 1..* Observes 1 * * Produces 1 1 1 Performs Raw data Sensor Actuator Action 1 1 Accessed-by Extends Extends actuated-by 1 Observes 1 Entity of Interest Resource Actuator AffectsSensor 1 Hosts Device * driver Entity of Interest driver Communicates-with 1 1 1 generates consumes 1 1 Runs-on 1..* Software Component Command Sensor Extends measurement End-user Storage Computational Driver ExtendsApplication Service Service Extends Information User Store Stores information about Entity of Interest 51
  52. 52. Middleware Approach• Motivation: • Shields the programmers from complexity by providing abstractions at system-level [Context toolkit, Gaia middleware]. Disadvantages: • Programming abstractions for whom ? • Missing support for each application development stages • Provided support remain general purpose and thus provide little guidance to developers to program application domain 52

×