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

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