Enabling High Level Application Development In The Internet Of Things
3 likes1,104 views
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.
![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](https://image.slidesharecdn.com/enablinghighlevelapplicationdevelopmentintheinternetofthings-13470071238016-phpapp01-120907034050-phpapp01/85/Enabling-High-Level-Application-Development-In-The-Internet-Of-Things-4-320.jpg)
![Multiple Levels [IoT Research Roadmap]
Internet of
Things
Application
Domain Building
…
Automation Healthcare Transportation
Application HVAC Energy
Management
Deployment
INRIA Google
office Office
[IoT Research Roadmap] Internet of things strategic Research Roadmap
http://www.internet-of-things-research.eu/pdf/IoT_Cluster_Strategic_Research_Agenda_2009.pdf
6](https://image.slidesharecdn.com/enablinghighlevelapplicationdevelopmentintheinternetofthings-13470071238016-phpapp01-120907034050-phpapp01/85/Enabling-High-Level-Application-Development-In-The-Internet-Of-Things-6-320.jpg)
![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](https://image.slidesharecdn.com/enablinghighlevelapplicationdevelopmentintheinternetofthings-13470071238016-phpapp01-120907034050-phpapp01/85/Enabling-High-Level-Application-Development-In-The-Internet-Of-Things-13-320.jpg)
![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](https://image.slidesharecdn.com/enablinghighlevelapplicationdevelopmentintheinternetofthings-13470071238016-phpapp01-120907034050-phpapp01/85/Enabling-High-Level-Application-Development-In-The-Internet-Of-Things-14-320.jpg)
![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, IEEE
Transactions on, (99):1-1, 2011.
24](https://image.slidesharecdn.com/enablinghighlevelapplicationdevelopmentintheinternetofthings-13470071238016-phpapp01-120907034050-phpapp01/85/Enabling-High-Level-Application-Development-In-The-Internet-Of-Things-24-320.jpg)
![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, IEEE
Transactions on, (99):1-1, 2011.
25](https://image.slidesharecdn.com/enablinghighlevelapplicationdevelopmentintheinternetofthings-13470071238016-phpapp01-120907034050-phpapp01/85/Enabling-High-Level-Application-Development-In-The-Internet-Of-Things-25-320.jpg)
![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: 6
Use 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](https://image.slidesharecdn.com/enablinghighlevelapplicationdevelopmentintheinternetofthings-13470071238016-phpapp01-120907034050-phpapp01/85/Enabling-High-Level-Application-Development-In-The-Internet-Of-Things-37-320.jpg)
![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](https://image.slidesharecdn.com/enablinghighlevelapplicationdevelopmentintheinternetofthings-13470071238016-phpapp01-120907034050-phpapp01/85/Enabling-High-Level-Application-Development-In-The-Internet-Of-Things-52-320.jpg)
More Related Content
What's hot (16)
Viewers also liked (14)
Similar to Enabling High Level Application Development In The Internet Of Things (20)
More from Pankesh Patel (16)
Enabling High Level Application Development In The Internet Of Things
- 1. Enabling High-level Application Development in the Internet of Things Pankesh Patel ARLES project-team Inria Paris-Rocquencourt
- 2. Outline • Introduction to the Internet of Things • Application Development Challenges • Existing Approaches • Our Goal • Contributions • Discussion • Future work 2
- 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. 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. Marriage of Sensor Network and Pervasive Computing Sensor Network Pervasive computing Large Scale Heterogeneity Internet of things 5
- 6. Multiple Levels [IoT Research Roadmap] Internet of Things Application Domain Building … Automation Healthcare Transportation Application HVAC Energy Management Deployment INRIA Google office Office [IoT Research Roadmap] Internet of things strategic Research Roadmap http://www.internet-of-things-research.eu/pdf/IoT_Cluster_Strategic_Research_Agenda_2009.pdf 6
- 7. Outline • Introduction to the Internet of Things • Application Development Challenges • Existing Approaches • Our Goal • Contributions • Discussion • Future work 7
- 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-set Hinders rapid application development Programmer/developer 8
- 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. 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. 4. Large Scale • Hundreds to thousands of devices equipped with sensors and actuators Reasoning at large scale is impractical 11
- 12. Outline • Introduction to the Internet of Things • Application Development Challenges • Existing Approaches • Our Goal • Contributions • Discussion • Future work 12
- 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. 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. Goal of Our Research “Enable high-level application development that allow stakeholders involved in the development of IoT applications to easily create applications, which involves a large number of heterogeneous devices’’ 15
- 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. Contributions 1 We identify entities of IoT and relationship among them (model) 2 Leveraging model, we identify the precise role of stakeholders 3 Resulting from the actions of each stakeholder, we propose multi-stage model driven approach 4 Evaluation of approach 17
- 18. Our IoT Model (1/2) It encapsulates system’s functionalities, provides interface. Communicates-with Traditional * 1 consumes 1..* 1 Software Internet 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. 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 Measurement End-user Storage Computational Driver Application Service Service Information User Store 19
- 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. 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 Computational Application Service 21
- 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 Measurement End-user Storage Computational Driver Application Service Service User Store Stores information about Entity of Interest 22
- 23. Contributions 1 We identify entities of IoT and relationship among them (model) 2 Leveraging model, we identify the precise role of stakeholders 3 Resulting from the actions of each stakeholder, we propose multi-stage model driven approach 4 Evaluation of approach 23
- 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, IEEE Transactions on, (99):1-1, 2011. 24
- 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, IEEE Transactions on, (99):1-1, 2011. 25
- 26. Contributions 1 We identify entities of IoT and relationship among them (model) 2 Leveraging model, we identify the precise role of stakeholders 3 Resulting from the actions of each stakeholder, we propose multi-stage model driven approach 4 Evaluation of approach 26
- 27. Vocabulary Specification 1 Vocabulary Specification using Srijan Vocabulary Language (SVL) Domain Vocabulary • Sensor Specification Expert • Actuator • Storage Service • Region definition Specify Input Refer Output 27
- 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). Specify Input Refer Output 28
- 29. Implementing Software Component 1 2 Domain Vocabulary Expert Specification Architecture System Specification Designer Framework Generator 3 4 Application Application Application Developer Logic Framework Specify Input Refer It allows application developers to focus Output on software component logic. 29
- 30. Target Network Specification 1 2 Domain Vocabulary Expert Specification Architecture System Specification Designer 5 Framework Generator Network Network 3 description Manager 4 Application Application Application Developer Logic Framework Specify Given vocabulary, he specifies target Input deployment scenario using Srijan Refer Network Language (SAL). Output 30
- 31. Mapping 1 2 Domain Vocabulary Expert Specification Architecture System Specification Designer 5 Framework Generator Network Network 3 description Manager Mapper 4 6 Application Application Application Developer Logic Framework Mapping files Specify Input It decides the specific device where Refer each software component will be Output running. 31
- 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 6 Application Application 7 Application Developer Logic Framework Mapping files Device Device Developer Specify Drivers Input Refer Output 32
- 33. Linking 1 2 Domain Vocabulary Expert Specification Architecture System Specification Designer 5 Framework Generator Network Network 3 description Manager Mapper 4 6 Application Application 7 Application Developer 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. Domain Specific Languages (DSLs) 34
- 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. 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 implementations TemperatureSensor generate tempMeasurement : TempStruct; One entity description for many instances 36
- 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: 6 Use 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. 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. Srijan Network Language Temperature-Sensing-Device : Device Name region : Building : 15 ; Floor : 11; Room : 0; abilities : TemperatureSensor; Attached sensor/ actuator/storage service Badge-Scanner : with device region : Building : 15 ; Floor : 11; Room : 0; abilities : BadgeReader ; “Vocabulary” specific Network Description 39
- 40. Contributions 1 We identify entities of IoT and relationship among them (model) 2 Leveraging model, we identify the precise role of stakeholders 3 Resulting from the actions of each stakeholder, we propose multi-stage model driven approach 4 Evaluation of approach 40
- 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 Application Fire Management 8 8 4 3 0 8 Application 41
- 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. Outline • Introduction to the Internet of Things • Application Development Challenges • Existing Approaches • Our Goal • Contributions • Discussion • Future work 43
- 44. Discussion 1. Identify the precise role of each stakeholders • Promotes separation of concerns 2. 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. Outline • Introduction to the Internet of Things • Application Development Challenges • Existing Approaches • Our Goal • Current Progress to Achieve Goal • Discussion • Future work 45
- 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. 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. 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. THANKS FOR LISTENING ME
- 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 measurement End-user Storage Computational Service Driver Application Service Extends Extends Information User Store 50
- 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 Extends Application Service Service Extends Information User Store Stores information about Entity of Interest 51
- 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